Francesco Oghabi

Podman vs Docker nel 2026: Quando Ha Senso Cambiare

Podman vs Docker: differenze reali, non marketing. Quando Podman conviene, quando Docker resta la scelta giusta, e come migrare.

Docker ha praticamente inventato i container come li conosciamo. Per anni "container" e "Docker" erano sinonimi. Poi sono arrivate le alternative, e Podman e quella che ha preso piu piede, specialmente in ambito enterprise e Red Hat.

La domanda che mi fanno spesso: "Dovrei passare a Podman?" La risposta, come sempre, e "dipende". Vediamo da cosa.

Le Differenze Che Contano

Ci sono differenze architetturali reali tra Docker e Podman. Non sono solo marketing.

Daemon vs Daemonless

Docker ha un daemon centrale (dockerd) che gira come root e gestisce tutti i container. Ogni comando docker parla con questo daemon.

Podman non ha daemon. Ogni container e un processo figlio diretto del comando che lo ha lanciato. Niente processo centrale sempre in esecuzione.

Implicazioni pratiche:

  • Podman: Se il processo padre muore, puoi configurare cosa succede ai container (continuano o muoiono con lui)
  • Docker: Se il daemon crasha, potenzialmente tutti i container hanno problemi
  • Podman: Meno overhead quando non stai usando container — niente daemon in background
  • Docker: Il daemon gestisce meglio cose come restart automatici e dipendenze tra container

Root vs Rootless

Docker tradizionalmente richiede privilegi root. Puoi configurarlo rootless, ma non e il default e richiede setup aggiuntivo.

Podman e rootless by design. L'utente normale puo creare e gestire container senza privilegi elevati. Il container gira con UID mappati nel namespace utente.

Implicazioni pratiche:

  • Sicurezza: Un container compromesso in Podman rootless non ha accesso root all'host
  • Multi-tenancy: Piu utenti possono usare container sullo stesso sistema senza interferire
  • Complicazioni: Alcune cose (bind mount su directory root, porte sotto 1024) richiedono workaround in modalita rootless

OCI vs Proprietario

Docker usa un formato di immagini che e diventato standard OCI, ma il daemon ha molte estensioni proprietarie.

Podman segue rigorosamente gli standard OCI. Le immagini e i container sono completamente compatibili con qualsiasi runtime OCI.

In pratica, la compatibilita immagini e quasi totale. Quello che cambia sono le API e i socket — un docker-compose o un tool che parla con il socket Docker potrebbe non funzionare direttamente con Podman (anche se ci sono workaround).

Compatibilita con Docker

Podman e progettato per essere un drop-in replacement. Il comando podman accetta la stessa sintassi di docker:

# Docker
docker run -d -p 8080:80 nginx

# Podman - identico
podman run -d -p 8080:80 nginx

Puoi anche creare un alias:

alias docker=podman

E la maggior parte degli script continuera a funzionare.

Cosa Funziona Uguale

  • Build di immagini (Dockerfile identici)
  • Run di container
  • Gestione volumi
  • Networking base
  • Registry pull/push

Cosa E Diverso

  • Docker Compose: Podman ha podman-compose o usa podman pod con file Kubernetes YAML. Docker Compose nativo non funziona senza hack
  • Docker socket: Podman puo emulare il socket Docker, ma richiede configurazione
  • Docker Swarm: Non esiste equivalente Podman. Per orchestration, Podman punta su Kubernetes
  • Build avanzate: BuildKit (il nuovo builder di Docker) ha feature che Podman non ha ancora

Podman Compose vs Docker Compose

Questo e il pain point principale per chi migra.

Opzione 1: podman-compose

pip install podman-compose
podman-compose up -d

Funziona per compose file semplici. Per file complessi con network avanzati, dipendenze, o feature moderne di compose, puo avere problemi.

Opzione 2: docker-compose con socket Podman

# Avvia il socket Podman
systemctl --user start podman.socket

# Configura Docker Compose per usarlo
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock

# Usa docker-compose normalmente
docker-compose up -d

Questa opzione ha compatibilita migliore, ma introduce complessita.

Opzione 3: Converti a Kubernetes YAML

Podman puo generare manifest Kubernetes dai container:

podman generate kube my-container > my-container.yaml

E poi deployare con:

podman play kube my-container.yaml

Se stai gia usando Kubernetes o pianifichi di farlo, questo approccio ha senso. Altrimenti e overhead.

Pods in Podman

Podman supporta nativamente il concetto di Pod (da cui il nome). Un pod e un gruppo di container che condividono network namespace.

# Crea un pod
podman pod create --name my-pod -p 8080:80

# Aggiungi container al pod
podman run -d --pod my-pod nginx
podman run -d --pod my-pod php-fpm

I container nel pod si vedono su localhost, come in Kubernetes. E un modo per testare architetture multi-container senza compose.

Quando Scegliere Podman

Scenari dove Podman ha senso:

Ambiente Red Hat/Fedora/CentOS. Podman e il default. Docker richiede installazione extra e configurazione. E come nuotare controcorrente.

Sicurezza e priorita. Rootless by default significa superficie d'attacco ridotta. Per ambienti regolamentati o security-conscious, e un vantaggio reale.

Sviluppatori senza root. Se lavori su un sistema dove non hai sudo e non puoi installare Docker, Podman rootless ti permette comunque di usare container.

Server minimali. Niente daemon sempre in esecuzione. Se fai girare container occasionalmente, non hai overhead quando non servono.

Compatibilita Kubernetes. Podman pensa in termini di pod, genera YAML Kubernetes, si integra naturalmente con l'ecosistema.

Quando Restare su Docker

Scenari dove Docker resta preferibile:

Team gia su Docker. La curva di migrazione non e zero. Se il team e produttivo con Docker e non ci sono problemi, cambiare ha costi senza benefici chiari.

Docker Compose complesso. Se hai compose file sofisticati con molte dipendenze, la migrazione puo essere dolorosa.

Tooling che assume Docker. IDE, CI/CD pipeline, tool vari. Molti assumono Docker socket. Farli funzionare con Podman e possibile ma richiede lavoro.

Docker Desktop. Per sviluppo su Mac/Windows, Docker Desktop e ancora l'esperienza piu liscia. Podman ha Podman Desktop, ma e meno maturo.

BuildKit. Se usi feature avanzate di BuildKit (cache mounting, secrets in build, etc.), non tutte sono disponibili in Podman.

Migrazione Pratica

Se decidi di migrare, ecco un approccio graduale.

Step 1: Installa e Testa

# Fedora/RHEL
sudo dnf install podman

# Ubuntu/Debian
sudo apt install podman

# macOS
brew install podman
podman machine init
podman machine start

Prova i tuoi container piu semplici:

podman run hello-world
podman build -t myapp .
podman run -p 8080:80 myapp

Step 2: Alias per Testing

alias docker=podman

Lancia i tuoi script esistenti. Vedi cosa si rompe.

Step 3: Risolvi i Problemi

I problemi tipici:

  • Socket Docker non trovato → Abilita socket Podman
  • Permessi su mount → Aggiungi :Z per SELinux o usa --userns=keep-id
  • Porte basse → Usa porte alte o configura sysctl net.ipv4.ip_unprivileged_port_start

Step 4: Migra Compose

Se usi compose, decidi l'approccio (podman-compose, socket emulation, o Kubernetes YAML) e migra gradualmente.

Step 5: CI/CD

Aggiorna le pipeline. La maggior parte dei CI supporta Podman direttamente o via socket emulation.

Performance

Nei miei test, le performance sono comparabili. Podman e leggermente piu veloce nello startup di container (niente comunicazione col daemon), Docker e leggermente piu veloce in operazioni che beneficiano del caching del daemon.

In pratica, la differenza e misurabile ma raramente significativa per workload reali. Non scegliere basandoti sulla performance a meno che tu non abbia requisiti estremi.

Il Mio Setup

Per contestualizzare, ecco cosa uso io:

Su Fedora (workstation principale): Podman. E il default, funziona bene, non ho ragioni per installare Docker.

Su server Ubuntu: Docker per progetti legacy, Podman per nuovi progetti. Convivono senza problemi.

Per CI/CD: Dipende dal progetto. GitHub Actions ha buon supporto per entrambi.

Per sviluppo locale con compose complessi: Docker, perche la compatibilita e migliore e non voglio perdere tempo in debug.

Non sono religioso. Uso quello che funziona meglio per il caso specifico.

Conclusione

Podman non e "meglio" di Docker in assoluto. E diverso, con tradeoff diversi.

Se sei su ecosistema Red Hat, se la sicurezza e critica, se vuoi container rootless senza fatica, Podman e la scelta naturale.

Se hai un setup Docker funzionante, team abituato a Docker, tooling che assume Docker, migrare per il gusto di migrare non ha senso.

La cosa positiva e che la compatibilita e alta. Puoi provarli entrambi, vedere cosa funziona meglio per te, e decidere senza commitment definitivi. Le immagini sono le stesse, i comandi sono quasi identici. Il cambio, se decidi di farlo, non e drammatico.

La scelta dello strumento giusto dipende dal contesto, non dal hype.