Why I Replaced Docker with Podman for Croatian Dev Environments

I remember the exact moment I switched. I was rebuilding a local Laravel environment on my development machine in Zagreb, and Docker Desktop decided it needed yet another system update. After the restart, my containers refused to start because of some lingering permission issue with the socket. I spent two hours debugging, while my colleague in Split—using Podman on his Fedora workstation—was already deploying to staging. That afternoon, I wiped Docker from my system and never looked back.

The Real Problem with Docker in Croatia

Why Docker Desktop Feels Like Overkill

Let’s be honest: most of us in Croatian dev shops aren’t running massive Kubernetes clusters on our laptops. We’re running a LAMP stack for a client portal, a Node.js backend for a startup’s MVP, or maybe a Python microservice for a fintech firm. Docker Desktop, with its virtual machine layer and its constant daemon overhead, feels like driving a truck to pick up a loaf of bread.

On my ThinkPad with 16GB of RAM, Docker Desktop regularly consumed over 2GB just sitting idle. That’s memory I need for IntelliJ, a couple of browser tabs, and Slack. In a country where hardware often comes with a premium price tag, every megabyte counts. Podman, by contrast, is daemonless. It runs containers directly under your user namespace, so there’s no central process eating resources in the background.

The Licensing Elephant in the Room

If you’re working for a Croatian company that values compliance, you already know the story. Docker Desktop’s licensing change in 2021 caught many teams off guard. For large enterprises, the per-seat subscription cost adds up fast. While many of us in smaller studios or as freelancers might still squeak by under the “small business” exception, the uncertainty is annoying.

Podman is fully open source under the Apache 2.0 license. There is no license manager, no nag screen, no “you have exceeded the limit” warning. When I invoice clients in euros, the last thing I want is a surprise licensing audit. Podman removes that anxiety entirely.

How Podman Works (and Why It Feels Familiar)

The Command-Line Mirror

Here’s the part that surprises most developers I talk to in Croatian tech meetups: Podman’s CLI is intentionally compatible with Docker. If you know docker run, you already know podman run. The same goes for build, pull, ps, logs, and exec. I literally aliased docker to podman on my machine and forgot about it for weeks.

The only difference that tripped me up initially was the socket path. Docker uses /var/run/docker.sock, while Podman defaults to a user-specific socket under $XDG_RUNTIME_DIR. But tools like docker-compose work seamlessly through Podman’s compatibility layer, and Podman even ships its own podman-compose for those who want a native experience.

Rootless by Default

This was the biggest “aha” moment for me. In Docker, running a container means your process effectively runs as root on the host unless you explicitly map users. With Podman, every container runs under your user ID by default. That means a compromised container can’t easily escalate to full system access.

For a Croatian agency handling sensitive client data—say, an e-commerce platform for a local retailer—this is a massive security win. I no longer worry about a rogue npm install script writing to /etc/passwd. Podman uses user namespaces to remap UIDs, so inside the container you appear as root, but outside you’re just a regular user with limited permissions.

Pods Instead of Compose Files

One feature I initially dismissed but now rely on daily is Podman’s native support for pods. Inspired by Kubernetes, a pod is a group of containers that share the same network namespace. When I’m developing a microservice that needs a database, a cache, and a message queue, I create a single pod. All three containers can talk to each other via localhost, and I can start or stop the entire group with one command.

Compare that to Docker Compose, where you define services in a YAML file and rely on a separate tool to orchestrate them. Podman’s approach feels more cohesive. I’ve even started using podman play kube to deploy my local pods directly from Kubernetes YAML manifests, which makes the transition from local dev to production on a K8s cluster almost trivial.

Setting Up Podman on Croatian Soil

Installation on Ubuntu and Fedora

Most Croatian developers I know use Ubuntu or Fedora. On Ubuntu, installing Podman is straightforward:

sudo apt update
sudo apt install podman

On Fedora, it comes pre-installed. If you’re on a fresh install, just run sudo dnf install podman. I recommend also installing podman-docker to get the Docker compatibility layer and podman-compose for legacy compose files.

One small gotcha: on Ubuntu, the default Podman version in the repositories can be a bit old. If you want the latest features—like native support for podman machine on macOS or Windows—add the Kubic repository:

sudo sh -c "echo 'deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_$(lsb_release -rs)/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
wget -q https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_$(lsb_release -rs)/Release.key -O- | sudo apt-key add -
sudo apt update
sudo apt install podman

Configuring Registries for Croatian Developers

By default, Podman pulls images from Docker Hub. But if you’re working with a local registry—maybe your team runs a private Harbor instance in a data center in Zagreb—you need to configure registries.conf. The file lives at /etc/containers/registries.conf or ~/.config/containers/registries.conf for user-specific overrides.

I added an entry for docker.io as a fallback and then pointed to my team’s internal registry. The syntax is simple:

[registries.search]
registries = ['docker.io', 'registry.team.local:5000']

[registries.insecure]
registries = ['registry.team.local:5000']

This saved me from typing the full registry URL every time I pulled an image. It’s a small quality-of-life improvement, but it adds up over a week of development.

Handling Docker Compose Workflows

If your project still uses docker-compose.yml, you have two options. First, you can install podman-compose from PyPI:

pip3 install podman-compose

Then run podman-compose up instead of docker-compose up. It works for most cases, though I’ve encountered edge cases with volume mounts and network aliases. My second, preferred approach is to migrate to podman play kube. I generate a Kubernetes YAML from my compose file using podman generate kube and then deploy that with podman play kube. It’s a bit more manual upfront, but the result is a portable definition that works identically in production.

Real-World Performance Gains

Memory and CPU Footprint

I benchmarked my typical stack—Nginx, PHP-FPM, MariaDB, and Redis—on both Docker Desktop and Podman. With Docker, the idle memory usage hovered around 1.6GB for the VM plus the containers. With Podman, the same stack consumed 800MB total. The CPU overhead was negligible for both, but the memory savings meant I could keep my browser open with 20 tabs without hitting swap.

On a 2020 laptop with 8GB of RAM, this is the difference between a smooth development experience and constant stuttering. For junior developers at Croatian IT academies who are learning on older hardware, Podman makes containerization accessible without demanding a hardware upgrade.

Faster Container Start Times

Podman’s daemonless architecture means there is no central process to negotiate with. When I run podman run -d nginx, the container starts almost instantly. Docker Desktop, on the other hand, must communicate with its background daemon via a socket, which adds a few hundred milliseconds per command. That doesn’t sound like much, but when you’re iterating rapidly—building an image, running a container, testing, stopping, rebuilding—those milliseconds turn into minutes over a day.

I also noticed that Podman handles SIGTERM more gracefully. When I stop a container with podman stop, it respects the timeout and cleans up immediately. Docker sometimes leaves orphaned processes in its VM, which I would have to clean manually with docker system prune.

One Concrete Anecdote: The Agency Migration

Last summer, I helped a small digital agency in Rijeka migrate their CI/CD pipeline from Docker to Podman. They had a Jenkins server running on an old Dell PowerEdge with 32GB of RAM. Docker Desktop was consuming 6GB just for the daemon, leaving barely enough room for their builds. The team was constantly fighting OOM errors.

We switched to Podman on the same hardware. The first build after the migration completed in 18 minutes—down from 35. The memory usage dropped by half. The lead developer told me later that they hadn’t realized how much overhead Docker was introducing. They now run Podman across all their staging environments and are planning to use Podman’s built-in systemd integration to manage containers as services on their production VPS.

That agency’s story is not unique. I’ve heard similar reports from freelancers in Osijek and startups in Varazdin. The pattern is always the same: Docker works, but Podman works better for the scale and constraints most of us operate in.

The Learning Curve Is a Myth

What You Need to Unlearn

Very little, honestly. The main conceptual shift is understanding that Podman doesn’t have a daemon. When you run podman ps, it queries the container store directly. That means you can run Podman commands in a script without worrying about whether the daemon is running. It also means you can run multiple instances of Podman on the same machine as different users, each with their own container store.

I had to unlearn one habit: using docker exec -it to attach to a running container. Podman uses the same syntax, but because containers are rootless, you might need to specify the user inside the container explicitly. It’s a minor tweak that becomes second nature after the first day.

Tools That Work Out of the Box

If you rely on Docker Compose, VS Code’s Remote – Containers extension, or Portainer, you’ll be happy to know they all work with Podman. For VS Code, you just need to point the extension to Podman’s socket. On Linux, that’s ~/.local/share/containers/podman/machine/podman.sock. On macOS or Windows, you’ll use podman machine start first, then connect to the socket exposed by the VM.

Portainer can also connect to a Podman socket. I’ve run it for a few months to manage containers visually, and it works flawlessly. The only thing I lost was Docker’s native integration with some third-party monitoring tools, but those were overkill for my needs anyway.

When You Might Still Want Docker

I’m not here to tell you Docker is useless. It still has advantages in certain scenarios. If your team is deeply invested in Docker Swarm, or if you’re using a SaaS platform that only supports Docker sockets, you might need to stick with the original. Also, if you’re developing on macOS or Windows and need a seamless GUI experience, Docker Desktop is more polished than Podman’s current machine integration.

But for the vast majority of Croatian developers—working on Linux, running standard stacks, and valuing resource efficiency—Podman is the better choice. It respects your system resources, your privacy, and your workflow.

A Practical Takeaway for Your Next Project

Start small. Install Podman on your development machine today, but keep Docker installed. Use Podman for a single project that doesn’t have complex networking requirements. Once you’re comfortable, migrate your compose files to pods. After a week, you’ll likely find yourself reaching for Podman by default.

I predict that within the next two years, most Croatian dev shops will have made the switch. The combination of rootless security, lower overhead, and licensing peace of mind is too compelling to ignore. The container ecosystem is maturing, and Podman is leading the charge toward a more developer-friendly future. Your machine—and your wallet—will thank you.