Em 2013, quando Docker foi lançado, o conceito de "empacotar uma aplicação com tudo o que ela precisa para rodar" era revolucionário. Antes disso, a frase "funciona na minha máquina" era um problema real e frequente. O Docker tornou o ambiente reproduzível — e isso mudou a indústria.
Mais de uma década depois, o ecossistema cresceu. Docker já não está sozinho. Existem alternativas que resolvem problemas específicos com abordagens diferentes. Este post compara o Docker com as principais ferramentas disponíveis hoje.
O que é Docker, afinal
Docker é um conjunto de ferramentas para criar, distribuir e executar containers. Ele engloba:
- Docker Engine — o daemon que roda containers no host.
- Docker CLI — a interface de linha de comando (
docker build,docker run, etc.). - Docker Hub — o registro público de imagens.
- Docker Compose — orquestração local com múltiplos containers.
- Dockerfile — o formato de definição de imagem.
Essa combinação é poderosa e foi o padrão de facto por muitos anos. O problema é que "Docker" virou sinônimo de container, mesmo quando as pessoas estão falando de tecnologias distintas por baixo.
Podman: a alternativa sem daemon
Podman é a alternativa mais próxima do Docker em termos de interface.
Os comandos são praticamente idênticos — a ponto de muita gente usar
um alias alias docker=podman e não perceber diferença no dia a dia.
A diferença fundamental é arquitetural. Docker depende de um daemon central rodando como root. Podman não tem daemon — cada container é um processo filho direto do usuário que o iniciou.
Isso tem consequências práticas. Sem daemon root, a superfície de ataque é menor. Containers podem rodar sem privilégios elevados (rootless containers), o que é mais seguro em ambientes corporativos. Por outro lado, algumas integrações mais antigas assumem a presença do daemon Docker e não funcionam com Podman sem ajustes.
containerd e runc: a camada de baixo
Enquanto Docker e Podman são ferramentas voltadas para o desenvolvedor, containerd e runc existem na camada de baixo — são eles que realmente executam os containers.
O próprio Docker usa containerd internamente desde a versão 1.11. O Kubernetes também usa containerd diretamente como runtime padrão desde que removeu o suporte ao dockershim em 2022.
runc é ainda mais baixo nível — é a implementação de referência da especificação OCI (Open Container Initiative). Na prática, ninguém interage com runc diretamente em produção; ele é invocado pelo containerd ou por outros runtimes.
Buildah: só para construir imagens
Buildah é uma ferramenta focada exclusivamente na construção de imagens OCI. Ele não executa containers — só cria imagens.
Essa especialização permite construir imagens sem precisar de um daemon rodando, e com controle mais granular sobre cada camada. Buildah é frequentemente usado em pipelines de CI onde segurança e isolamento são prioridade, e combina bem com Podman para execução.
Comparação direta
| Ferramenta | Função principal | Daemon | Rootless | Melhor para |
|---|---|---|---|---|
| Docker | Build + Run + Registry | Sim | Parcial | Desenvolvimento local, adoção inicial |
| Podman | Build + Run | Não | Sim | Ambientes seguros, substituto do Docker |
| containerd | Runtime de containers | Sim | Sim | Kubernetes, infraestrutura de produção |
| Buildah | Construção de imagens | Não | Sim | CI/CD, pipelines sem daemon |
| runc | Execução de containers (OCI) | Não | Sim | Referência OCI, uso indireto via outros runtimes |
Então devo parar de usar Docker?
Não necessariamente. Docker ainda é a melhor escolha para quem está começando, para equipes que valorizam a simplicidade e para a maioria dos fluxos de desenvolvimento local. O ecossistema ao redor — Docker Compose, extensões, integrações com IDEs — é maduro e bem documentado.
A mudança faz sentido quando você tem requisitos específicos: segurança mais rígida (Podman), pipelines de CI sem daemon (Buildah), ou quando você está construindo infraestrutura que roda containers em escala (containerd).
O importante é entender que container não é sinônimo de Docker. Todas essas ferramentas falam a mesma língua — a especificação OCI — e uma imagem construída com qualquer uma delas pode ser executada pelas outras. A interoperabilidade é o que torna esse ecossistema saudável.
Conclusão
Docker abriu a porta. O ecossistema que surgiu depois amadureceu o suficiente para que hoje a escolha da ferramenta dependa do contexto, não de uma lealdade de marca. Para desenvolvimento local, Docker funciona muito bem. Para ambientes com restrições de segurança ou pipelines automatizados, Podman e Buildah merecem consideração séria. Para infraestrutura de produção em escala, containerd provavelmente já está rodando por baixo, mesmo que você não saiba.