Uma aplicação pode funcionar perfeitamente no notebook e ainda falhar no primeiro acesso em produção. Porta exposta de forma incorreta, variável de ambiente ausente, banco de dados sem persistência e falta de HTTPS são erros comuns. Saber como publicar aplicação com Docker significa transformar um container local em um serviço disponível, seguro e operável para usuários reais.
Docker reduz diferenças entre desenvolvimento, homologação e produção porque empacota código, dependências e configurações em imagens reproduzíveis. Mas o container, sozinho, não entrega disponibilidade. A publicação exige uma infraestrutura dimensionada, rede bem definida, dados persistentes, controle de acesso e monitoramento contínuo.
O que precisa estar pronto antes do deploy
O primeiro passo é separar o que pertence à imagem do que pertence ao ambiente. A imagem deve conter a aplicação e suas dependências. Senhas, chaves de API, URLs externas e parâmetros específicos de produção devem entrar por variáveis de ambiente ou arquivos de configuração protegidos.
Também valide se a aplicação atende ao básico de operação. Ela precisa registrar logs em stdout e stderr, responder a uma rota de saúde, encerrar processos corretamente e não depender de arquivos locais que desaparecerão quando o container for recriado. Se houver upload de clientes, relatórios ou documentos, esses dados devem ficar em um volume persistente ou em armazenamento externo.
Em aplicações web, prefira que o processo interno escute em uma porta privada, como 3000, 8080 ou 8000. A porta pública 80 ou 443 deve ficar sob responsabilidade de um proxy reverso. Isso facilita a emissão de certificados, a renovação de HTTPS, regras de redirecionamento e a exposição de múltiplos serviços no mesmo servidor.
Antes de avançar, confirme quatro pontos: a imagem é reproduzível, o banco possui backup, os dados persistem fora do container e o domínio aponta para o IP correto do ambiente. Esses detalhes evitam que uma atualização simples vire uma indisponibilidade prolongada.
Como publicar aplicação com Docker em uma VPS
Para projetos pequenos e médios, uma VPS Linux é uma opção direta. Ela oferece acesso root, previsibilidade de recursos e autonomia para configurar a pilha de publicação. Para aplicações com público brasileiro, hospedar em um datacenter no Brasil também reduz a latência percebida pelos usuários e simplifica a operação local.
Após provisionar o servidor, atualize o sistema operacional, crie um usuário administrativo sem usar root no dia a dia e instale Docker Engine com Docker Compose. Em seguida, libere apenas as portas necessárias no firewall: normalmente SSH em uma porta restrita, HTTP na 80 e HTTPS na 443. A porta da aplicação não deve ficar aberta publicamente se houver proxy reverso.
Um arquivo `compose.yaml` organiza serviços, redes, volumes e variáveis. Um cenário comum reúne aplicação, banco de dados e proxy reverso. Exemplo simplificado:
“`yaml services: app: image: registro.exemplo.com/minha-app:1.4.0 env_file:
- .env.production
restart: unless-stopped expose:
- “3000”
depends_on: db: condition: service_healthy
db: image: postgres:16 environment: POSTGRES_DB: app POSTGRES_USER: app POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck: test: [“CMD-SHELL”, “pg_isready -U app -d app”] interval: 10s timeout: 5s retries: 5
volumes: postgres_data: “`
O exemplo mantém os dados do PostgreSQL no volume `postgres_data`, mesmo se o container for recriado. Ainda assim, volume não é backup. Ele protege contra a remoção do container, não contra falha de disco, erro humano, corrupção ou ataque. A rotina de backup precisa gerar cópias externas, com retenção e testes periódicos de restauração.
Para iniciar a stack, use `docker compose up -d`. Depois, acompanhe os logs com `docker compose logs -f app` e confirme se o processo responde localmente. Só então configure o proxy reverso para encaminhar o domínio ao serviço interno.
HTTPS, domínio e proxy reverso
Publicar uma aplicação por IP até pode servir para teste, mas não é uma configuração adequada para produção. O domínio permite usar HTTPS, definir políticas de segurança e manter uma identidade estável para APIs, painéis administrativos e clientes.
O proxy reverso pode ser configurado com Nginx, Traefik ou Caddy. A escolha depende da operação. Nginx oferece controle detalhado e é comum em ambientes tradicionais. Traefik se integra bem a labels do Docker e facilita cenários com vários containers. Caddy simplifica a configuração de certificados em projetos com menor complexidade.
Independentemente da ferramenta, o fluxo é o mesmo: o DNS do domínio aponta para o IP público, o proxy recebe conexões nas portas 80 e 443, emite ou utiliza um certificado válido e encaminha a requisição para a rede interna do Docker. Redirecione HTTP para HTTPS e evite expor endpoints administrativos sem autenticação adicional.
Se a aplicação recebe arquivos grandes, ajusta cache ou atende uma API de alto volume, revise limites de upload, timeout e cabeçalhos encaminhados pelo proxy. Muitos erros atribuídos ao Docker, na prática, são configurações ausentes nessa camada.
Segurança que não pode ficar fora do container
Containers isolam processos, mas não substituem controles de infraestrutura. Uma aplicação publicada com Docker deve operar com o menor privilégio possível. Evite executar o processo como root dentro da imagem e não monte o socket do Docker em containers que não precisam administrá-lo.
As imagens também precisam ser tratadas como artefatos de produção. Use versões fixas em vez de tags genéricas como `latest`, atualize dependências de forma controlada e faça varreduras de vulnerabilidades no pipeline. Uma tag imutável, como `1.4.0` ou um identificador de commit, permite saber exatamente o que está em execução e voltar rapidamente em caso de falha.
Segredos merecem atenção especial. Nunca envie arquivos `.env` com credenciais para repositórios de código ou incorpore chaves na imagem. Restrinja permissões dos arquivos no servidor, faça rotação de senhas e separe credenciais por ambiente. Produção não deve reutilizar o mesmo banco, token ou chave de desenvolvimento.
No nível da rede, mantenha banco de dados, cache e filas em redes privadas. Se o PostgreSQL atende apenas à aplicação, não há motivo para abrir sua porta na internet. Para serviços críticos, um firewall virtual, regras de origem restritas e proteção contra ataques de rede reduzem a superfície exposta.
Atualizações sem perder o controle
O comando de deploy não deve ser apenas um `docker compose pull` seguido de reinício. Antes de atualizar, valide a nova imagem em homologação, registre a versão atual e confirme se a alteração exige migração de banco. Migrações incompatíveis são uma das principais razões para rollback falhar.
Um fluxo seguro baixa a imagem versionada, executa migrações compatíveis, recria somente o serviço necessário e verifica a rota de saúde. Se a nova versão apresentar erro, volte para a imagem anterior e mantenha logs suficientes para investigar a causa. Em aplicações sem múltiplas réplicas, haverá uma pequena janela de reinício. Para reduzir ou eliminar essa janela, é necessário usar balanceamento de carga, réplicas e uma estratégia de rollout.
Docker Compose é eficiente para uma VPS e para operações controladas. Quando a aplicação cresce, exige múltiplos nós, escalonamento automático, alta disponibilidade ou atualizações graduais, Kubernetes passa a ser uma alternativa mais adequada. Não é uma obrigação para todo projeto: introduzir Kubernetes cedo demais aumenta a carga operacional. A decisão depende do volume, da criticidade e da maturidade do time.
Observabilidade e capacidade para manter o serviço online
Publicar é apenas o início da operação. Acompanhe uso de CPU, memória, disco, tráfego de rede, status dos containers e tempo de resposta da aplicação. Logs centralizados ajudam a identificar erros recorrentes, enquanto alertas informam quando um serviço cai, um disco se aproxima do limite ou a latência aumenta antes de afetar clientes.
Defina limites de recursos para impedir que um processo consuma toda a memória do servidor. Ao mesmo tempo, não reduza esses limites por tentativa: meça o comportamento sob carga. Uma API leve pode operar bem em uma VPS de entrada; uma loja virtual com picos, filas, busca e banco ativo pode exigir mais vCPUs, SSD NVMe, memória e uma arquitetura separada para dados.
A infraestrutura também precisa acompanhar o nível de criticidade. Em serviços corporativos, considere redundância de conectividade, backups gerenciados, monitoramento 24/7 e suporte técnico disponível quando a falha acontece fora do horário comercial. A Locacloud atende esse cenário com infraestrutura nacional, recursos escaláveis e opções para evoluir de uma VPS a ambientes dedicados ou Kubernetes.
Uma publicação bem executada deixa de depender de comandos manuais e conhecimento de uma única pessoa. Quando imagem, configuração, dados, segurança e monitoramento estão documentados, a aplicação ganha condições reais de crescer sem transformar cada atualização em risco operacional.