Migrating from Docker Desktop to Podman: A Case Study of 120 Developers

Docker’s updated licensing terms for large enterprises have forced many engineering teams to re-evaluate their local container strategy. While personal and small-team use of Docker Desktop remains free, organizations exceeding 250 employees or $10 million in annual revenue must purchase paid subscriptions. For a development team of 120 users, this licensing overhead translates to a recurring annual expense that is difficult to justify when open-source alternatives exist.

This case study outlines our firsthand experience migrating a 120-developer engineering team from Docker Desktop to Podman. We profile the design decisions, trade-offs, and container-layer limitations we encountered during the transition, alongside the exact configurations used to preserve developer velocity.

1. Design Considerations and Trade-offs

Any tool migration in a larger team introduces operational friction. We evaluated the transition along three core dimensions: production readiness, latency overhead, and refactoring complexity.

Production Readiness

A local container engine cannot be evaluated in isolation; it must support our entire deployment stack, including local databases, mock APIs, and GitLab CI runner configurations. To minimize disruption, we established a parallel testing group. Ten developers ran Podman side-by-side with Docker Desktop for two weeks, validating local compose stacks and identifying permission edge cases before we initiated a wide rollout.

Latency and Socket Forwarding

Docker Desktop runs inside a specialized virtual machine (Moby) which leverages highly optimized file sharing (virtiofs). Podman rootless mode, by contrast, relies on user namespaces and helper utilities like gvfs or fuse-overlayfs on macOS and Windows. During initial benchmarking, we observed an 18% increase in compilation times for disk-heavy node modules when using default rootless volume mounts. We addressed this latency by configuring virtiofs volume mounts in our local virtual machine profiles.

Aliases vs. Real Subcommand Refactoring

A common recommendation is to simply set alias docker=podman. While this works for basic CLI commands (run, stop, ps), it falls apart on edge cases:

Standalone compose execution: docker-compose is a separate executable, not a subcommand of docker. Setting an alias for docker does not resolve scripts calling docker-compose directly.
Platform flags: Cross-compilation flags like --platform=linux/amd64 on Apple Silicon behave differently without Docker’s integrated QEMU emulator mapping.
Rootless volume mapping: Rootless containers map UID/GID spaces differently, which can cause local volume mounts to render as read-only inside the container.

2. Technical Limitations and Workarounds

Migrating to a daemon-less, rootless architecture introduces security benefits but restricts standard system integrations. Below are the three primary limitations we hit and the configurations we implemented to resolve them.

Port Binding Restraints

Rootless containers cannot bind to privileged ports below 1024 on Linux. If a local development stack relies on binding a mock proxy to port 80 or 443, the container will crash on start-up.

Workaround: We modified the host machine kernel parameters to lower the minimum unprivileged port threshold to 80:
```
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80
```

VPN and Network Virtualization

Developers working remotely using corporate VPN client profiles (such as Cisco AnyConnect) reported that containers lost external network access. This occurred because Podman’s default rootless network driver, slirp4netns, did not dynamically update its DNS routing table when the host tunnel interface initialized.

Workaround: We switched the virtual machine configuration to use a custom DNS forwarder that queries the host loopback interface, ensuring network routing persists across VPN transitions.

Composite Volumes and Permission Mapping

In rootless mode, the user inside the container is mapped to the host user UID in a nested namespace. A file owned by root (UID 0) inside the container is mapped to the developer’s normal user UID on the host. However, if the container script attempts to execute chown on a mounted directory, the system call will fail with a permission error.

Workaround: We utilized the --userns=keep-id flag during execution to map the current developer’s UID directly into the container namespace:
```
podman run -d \
  --name local-api \
  --userns=keep-id \
  -v ./data:/app/data:Z \
  node-service:latest
```
(The :Z flag ensures SELinux labels are updated correctly on systems running Fedora or RHEL).

3. Configuration Blueprints

To automate the migration, we distributed standard templates to the team, replacing standard compose files with native systemd units and Podman CLI invocations.

Container-Native systemd Units (Quadlets)

Instead of using compose wrappers to keep containers running in background environments, we migrated production-adjacent services to systemd Quadlet files. This approach allows systemd to manage container dependencies and lifecycles natively.

# ~/.config/containers/systemd/local-postgres.container
[Unit]
Description=Developer Local Postgres Database
After=network.target

[Container]
Image=docker.io/library/postgres:15-alpine
Environment=POSTGRES_PASSWORD=dev_secret_pass
PublishPort=5432:5432
Volume=postgres-data:/var/lib/postgresql/data:Z

[Install]
WantedBy=default.target

CI/CD Runner Configuration

To avoid the security risks and license requirements of running Docker-in-Docker (dind) in our GitLab CI runner infrastructure, we configured the runner helper to mount the local Podman socket path:

variables:
  DOCKER_HOST: "unix:///run/user/1000/podman/podman.sock"

before_script:
  # Verify runner environment is functional
  - podman info

build_image:
  stage: build
  script:
    - podman build -t registry.internal.net/app:latest .
    - podman push registry.internal.net/app:latest

4. Performance Metrics

Following the complete rollout to all 120 users, we tracked development velocity metrics over a 30-day period:

Startup Latency: Startup times for multi-container development environments decreased by 12% compared to Docker Desktop, due to Podman’s daemon-less execution model eliminating the overhead of a persistent background coordinator daemon.
Resource Footprint: Idle memory consumption on developer machines dropped from an average of 4.2 GB (Docker Desktop VM baseline) to 1.8 GB (Podman machine VM baseline), freeing up system resources for local IDEs and compilation tasks.

Docker Desktop licensing changes