Podman: perché il demone era il problema

C'è una cosa che mi ha fatto cambiare idea su Docker: non è che Docker sia cattivo. È che il demone, quello che gira in background con i privilegi di root e tiene in vita tutto, è un'architettura che ha senso nel 2014 e meno nel 2026.

Podman è nato per eliminare proprio quel demone. E la differenza non è cosmetica.

Come funziona davvero (senza il demone)

In Docker, quando fate docker run nginx, il client parla con un socket, il demone dockerd riceve la richiesta, e poi è lui a creare il container. Tutto passa da quel processo centrale.

In Podman non esiste quel passaggio. podman run nginx crea un processo che è figlio diretto della vostra shell. Se lo killate, muore. Se il vostro utente viene disconnesso, muore. Non c'è un layer intermedio che "tiene in vita" il container indipendentemente da chi lo ha lanciato.

La conseguenza pratica è che su un server con 15-20 servizi containerizzati non avete più un processo root che sta lì 24/7 a occupare 140-180 MB di RAM "a vuoto". E se un container si impalla, lo killate e finite. Non state a pregare che il demone recuperi.

Sicurezza: non è un'opzione, è il default

Docker gira come root. Il demone ha accesso a tutto il filesystem, a tutte le interfacce di rete, a tutto il kernel. Se c'è un container escape (e sono successe), chi ci finisce dentro è root. Punto.

Podman inverte il modello: i container girano con l'UID dell'utente che li lancia. Se un container scappa, atterra in un account utente senza privilegi. Il danno è contenuto.

In un host multi-utente, chi ha accesso al socket di Docker ha in pratica i privilegi di root. Non è una vulnerabilità, è il design. Con Podman non esiste quel socket. Ogni utente ha i suoi processi, i suoi namespace, i suoi cgroup. Il sysadmin non deve più "fidarsi" che il dev non faccia docker run --privileged -v /:/host.

Il concetto di pod, e perché esiste

Podman ha il concetto di "pod" nativo: un gruppo di container che condividono namespace di rete e PID. In pratica, quando fate un'app con un web server e un database, quei due container dovrebbero condividere la rete locale — non è un capriccio, è come funzionano i servizi in un host.

Docker non ha un equivalente nativo: si fa con --network container:, che funziona ma è un workaround. Podman lo ha nel modello, e basta. podman pod create, poi podman run --pod mio-pod nginx, e il secondo container entra nella rete del primo. Niente rete separata da gestire, niente IP da tenere a mente.

Su un server con una decina di servizi, il pod vi fa risparmiare un'intera classe di problemi di networking locale, e il tutto senza che debba esistere un demone che tiene in vita quel gruppo.

Quadlet: i container come servizi systemd

Con Quadlet (da Podman 4.4, migliorato a ogni release), scrivi un file .container in ~/.config/containers/systemd/ e systemd se ne occupa: avvio al boot, restart se il processo cade, log in journal, dipendenze tra servizi.

Non serve un wrapper. Non serve uno script di colla. Il container è un servizio del sistema, trattato come lo è sshd o nginx.

Sui server che gestisco, questo ha eliminato un'intera categoria di problemi: prima avevamo un cron job che faceva docker start a ogni boot, e se il cron non partiva per tempo i servizi non erano up. Ora è systemd che gestisce l'ordinamento, e basta.

La migrazione, in pratica

Il 95% dei comandi è identico. podman run, podman build, podman push, podman exec, podman logs... se sapete usare Docker, sapete già usarlo. I Dockerfile funzionano come stanno (Buildah li gestisce in modo daemonless).

Per i file Compose, in Podman 5.x basta abilitare il socket API compatibile Docker (systemctl --user enable --now podman.socket) e il vostro docker compose di prima funziona uguale, solo che dietro c'è Podman. Niente fork, niente fork di fork.

L'unica cosa che non c'è è Swarm. Ma onestamente, chi lo usa ancora in produzione nel 2026?

I costi

Docker Desktop è gratis fino a 250 dipendenti, poi si paga. Podman è Apache 2.0, e Podman Desktop è gratis e open source. Su questo non c'è molto da dire.

In più, Podman è incluso di default nelle principali distro RHEL-based (Fedora, RHEL, CentOS Stream, AlmaLinux, Rocky). Non lo installate, c'è già. Se la vostra flotta gira su una di queste, è il tool "di sistema", non un'aggiunta.

Quando Docker ha ancora senso

Per essere onesti: se fate sviluppo locale su Mac e il vostro team è già dentro l'ecosistema Docker, la curva di adozione non è zero. L'ecosistema è più maturo, i tutorial sono ovunque, e alcune toolchain (certi plugin di IDE, alcune CI) danno ancora per scontato che ci sia un socket Docker.

Ma per tutto quello che gira su Linux in produzione, su server condivisi, in pipeline CI/CD multi-utente: Podman non è più l'alternativa. È la scelta più solida, e il fatto che sia il default nelle principali distro RHEL-based non è un caso.