Durante anos, o processo de onboarding de um dev novo no projeto era assim: passa a tarde instalando dependências, configura o PHP na versão certa, instala as extensões que faltam, tenta conectar no banco local, descobre que a versão do PostgreSQL é diferente, mexe no php.ini, testa no browser, algo não funciona, começa a tentar entender por que o ambiente da máquina dele é diferente do seu.
Isso não é exagero. Já passei exatamente por esse ciclo mais vezes do que consigo contar. E não era por falta de cuidado da equipe.
O problema é estrutural: cada máquina de desenvolvimento é um ambiente diferente. PHP numa versão, extensões numa versão, nginx configurado de um jeito, libs do sistema em outra versão. Funciona na sua máquina, quebra na dele, não existe em staging. “Funciona na minha máquina” não é piada de programador. É uma frustração genuína que consome horas reais toda semana.
O que o Docker realmente resolve
Docker não é sobre containers serem tecnologicamente interessantes. Para quem desenvolve PHP no dia a dia, a vantagem concreta é uma: o ambiente vira código.
Em vez de um documento de onboarding com dez passos que ficam desatualizados em dois meses, você tem um arquivo que descreve o ambiente inteiro. PHP 8.3 com essas extensões, Nginx com essa configuração, PostgreSQL nessa versão, Redis para fila. Qualquer pessoa com Docker instalado sobe isso com um comando. O ambiente é idêntico para todo mundo na equipe, é idêntico ao que vai rodar em produção.
Esse alinhamento entre desenvolvimento e produção é onde a coisa começa a mudar de patamar. Quantidade de bugs que aparecem só em produção porque o ambiente local tinha uma versão diferente de alguma coisa, ou porque o comportamento do PHP mudou entre versões menores, cai bastante. Não some. Mas cai.
Aliás, a parte que mais impressiona quem começa a usar é o onboarding. Novo desenvolvedor, mudança de máquina, troca de sistema operacional. O tempo para estar com o ambiente rodando passa de horas ou dias para minutos. Já vi equipe pequena ganhar dois dias de produtividade só resolvendo o problema de “preciso configurar o ambiente de desenvolvimento do zero de novo”.
Onde o Docker complica a vida
Olha, não vou fingir que é tudo simples.
Performance no macOS é um problema real. Docker no Mac roda os containers em Linux virtualizado, e o compartilhamento de arquivos entre o sistema do Mac e o filesystem do container tem um overhead que, na prática, se sente. Em projetos com muitos arquivos, muitas dependências no vendor, muitos assets sendo processados, você vai notar que o servidor responde mais devagar do que rodando tudo nativo.
Há formas de mitigar. Algumas funcionam melhor que outras dependendo da configuração específica do projeto. Mas o problema existe e vai aparecer. Não é incomigo da ferramenta, é limitação da arquitetura no macOS. Quem desenvolve em Linux não sente isso da mesma forma.
A curva de aprendizado para fazer certo também é real. Não o básico. O básico você aprende em uma tarde. Quando você precisa configurar permissões de arquivo que funcionam igual em Linux e Mac, quando precisa entender por que o Xdebug não está conectando, quando quer rodar os testes dentro do container mas integrado com o IDE, aí começa a surgir complexidade que não está nos tutoriais de introdução.
E tem o caso onde Docker é tiro grosso para um problema pequeno. Projeto pessoal simples, você sozinho, ambiente controlado. PHP nativo, Laragon no Windows ou Herd no Mac, funciona, é rápido, não tem atrito. Usar Docker num projeto assim porque “é o certo a fazer” é burocracia sem benefício real.
A ferramenta certa depende do contexto. Sempre foi assim.
O que muda com Compose
O Docker sozinho já ajuda. O Docker Compose muda o jogo.
Projetos PHP reais têm mais de um serviço. Tem o PHP, tem o banco de dados, tem o Redis para sessão e fila, tem o Nginx na frente. Antes do Compose, coordenar isso manualmente era tedioso e propenso a erro. Com Compose, você descreve todos esses serviços juntos, como eles se conectam, em que ordem sobem.
O que isso muda na prática: você para de ter um banco de dados rodando no sistema hospedeiro, numa versão que você instalou há dois anos e não lembra exatamente como configurou. O banco passa a ser parte do projeto. Cada projeto tem o seu, na versão que precisa, com as configurações que precisa. Projetos diferentes podem rodar PostgreSQL em versões diferentes sem conflito nenhum.
Mais que isso, o Compose facilita simular cenários que antes exigiam configuração especial. Quer testar como o sistema se comporta quando o Redis está fora do ar? Derruba o serviço do Redis no Compose. Quer validar o comportamento com um banco read replica? Você configura isso localmente e testa antes de ver em produção.
Desenvolvimento e produção não são a mesma coisa
Aqui tem um ponto que a maioria dos tutoriais passa rápido.
O container de desenvolvimento e o container de produção não são a mesma coisa. No desenvolvimento, você quer volume montado para o código do projeto, quer Xdebug, quer ferramentas de debug. Em produção, nada disso deve existir. O container é menor, sem extensões de debug que adicionam overhead, sem ferramentas que só fazem sentido numa máquina de desenvolvedor.
Usar a mesma imagem para os dois ambientes não é economizar trabalho. É misturar responsabilidades que têm requisitos diferentes. Já vi projeto com Xdebug habilitado em produção porque o setup foi copiado do desenvolvimento sem pensar. O PHP funcionava, mas com uma degradação de performance que levou tempo para alguém associar a causa ao efeito.
Imagem de produção precisa ser enxuta. Só o que a aplicação precisa para rodar. Essa distinção vale o trabalho.
O que ficou
Sinceramente, chegou um ponto onde não consigo mais imaginar começar um projeto novo sem Docker. Não porque é tendência, não porque é o certo teoricamente. Porque os problemas que ele resolve, eu já vivi o suficiente sem ele para saber exatamente quanto tempo custam.
O arquivo de configuração do ambiente junto com o código significa que daqui a dois anos, quando alguém precisar rodar esse projeto de novo, o ambiente funciona. Não depende de quem está na equipe lembrar de como foi configurado. Não depende de um documento de setup que ficou desatualizado na segunda semana.
Pois é. É sobre tempo. Sobre não gastar energia com um problema que tem solução conhecida.
Gabriel Schunck está disponível para consultorias em arquitetura e desenvolvimento PHP. Se a equipe ainda perde horas com setup de ambiente e onboarding, isso tem solução. Entra em contato pelo gabriels.dev.br.