Stack na sua mão: DNS, Caddy, Docker e banco sem virar programador

Você aprova decisões sobre a sua infraestrutura toda semana. Contrata hospedagem, autoriza uma migração, paga uma conta de servidor, ouve seu técnico dizer "precisamos subir o banco pra outro lugar". E na maioria das vezes você aprova no escuro, porque ninguém te explicou o que cada peça faz em linguagem que você entenda.

Esse artigo conserta isso. Não vou te ensinar a programar nem a configurar servidor. Vou te dar o mapa: o que é cada peça da sua stack, o que ela faz, e por que ela importa. Depois disso, você conversa com qualquer técnico sem fingir que entende.

A analogia que uso o tempo todo: você é dono de restaurante. Não precisa saber cozinhar, mas precisa saber o que acontece na cozinha pra contratar o chef certo, cobrar o prato certo e decidir quando trocar o fogão. Sua stack é a cozinha da sua operação digital.

O caminho de uma requisição

Tudo fica mais claro quando você acompanha o que acontece quando alguém abre o seu site. Vou usar o exemplo real: alguém digita teamstudio.com.br no navegador. Nos próximos 200 milissegundos, isso acontece:

1. O navegador pergunta "onde fica teamstudio.com.br?" para o DNS, que responde com um endereço numérico (o IP do servidor).
2. O navegador bate nesse endereço, onde mora um servidor. Na porta de entrada tem um porteiro chamado Caddy, que recebe a visita.
3. O Caddy olha o que foi pedido e direciona para a aplicação certa, que roda dentro de um container (uma caixa isolada, gerenciada pelo Docker).
4. A aplicação precisa de dados (seu nome, seu pedido, seu histórico) e pergunta para o banco de dados.
5. O banco responde, a aplicação monta a página, o Caddy devolve para o navegador, e você vê o site.

Cinco peças: DNS, servidor, Caddy, container/Docker e banco. Vamos por cada uma.

DNS: a agenda de contatos da internet

Computadores não se acham por nome, se acham por número (o IP, tipo 76.13.235.206). Mas ninguém decora número. O DNS é a agenda que traduz o nome (teamstudio.com.br) no número do servidor.

Quando você compra um domínio (no registro.br, GoDaddy, Cloudflare), você está alugando um nome e dizendo para o mundo "esse nome aponta para esse servidor". Essa configuração é o DNS.

O que um dono precisa saber sobre DNS:

• Mudança de DNS demora pra valer (de minutos a algumas horas). Por isso migração de site não é instantânea. Quem te promete "troco agora e já está no ar" não está contando a verdade sobre propagação.
• Quem controla o DNS controla seu site. Se você perde acesso ao painel do domínio, alguém pode redirecionar seu site inteiro. Por isso o registrador de domínio é uma das contas mais críticas pra proteger com senha forte e segundo fator.
• Email também depende de DNS. Registros chamados MX, SPF e DKIM dizem quem pode mandar email em nome do seu domínio. Mexer no DNS errado derruba seu email junto com o site. Já vi acontecer.

A pergunta que você passa a fazer: "essa mudança mexe no DNS? Se mexe, qual o tempo de propagação e o email continua funcionando?"

O servidor e o Caddy: o porteiro que recebe e direciona

Servidor é só um computador que fica ligado 24 horas rodando o seu site. Você não compra esse computador, você aluga (é isso que hospedagem significa). Pode ser um servidor inteiro pra você (VPS, na Hostinger por exemplo) ou um pedaço de uma estrutura gigante (AWS, Vercel).

Dentro do servidor, a primeira coisa que recebe qualquer visita é um programa chamado reverse proxy. No nosso caso é o Caddy (outros comuns são o Nginx e o Traefik). Pensa nele como o porteiro de um prédio com vários apartamentos.

O que o porteiro faz:

• Recebe todas as visitas que chegam no servidor e decide para qual aplicação mandar. Um único servidor pode hospedar dezenas de sites; o Caddy é quem sabe que teamstudio.com.br vai pra um lugar e o site de outro cliente vai pra outro.
• Cuida do cadeado (HTTPS). Aquele cadeado verde no navegador é um certificado de segurança. O Caddy pega e renova esses certificados automaticamente. Quando você vê "site não seguro", muitas vezes é o porteiro com problema no certificado.
• Protege e organiza. Bloqueia, redireciona, comprime. É a camada onde várias regras de tráfego vivem.

Por que isso importa pra você: quando um técnico diz "o site caiu mas o servidor está de pé", muitas vezes o problema está no porteiro (configuração do Caddy), não na aplicação em si. Saber que existe essa camada já te ajuda a fazer a pergunta certa.

Docker e containers: caixas que empacotam sua aplicação

Esse é o conceito que mais assusta dono de negócio pelo nome, e é o mais simples de entender pela ideia.

Toda aplicação precisa de um monte de coisas pra rodar: uma versão específica de uma linguagem, certas bibliotecas, configurações. Antigamente, instalar isso direto no servidor era uma dor: funcionava na máquina do programador e quebrava no servidor, porque as versões eram diferentes. O famoso "na minha máquina funciona".

Container resolve isso. É uma caixa que empacota a aplicação com tudo que ela precisa, isolada do resto. Se roda na caixa, roda igual em qualquer lugar: no laptop do programador, no seu servidor, na nuvem. Docker é a ferramenta mais comum pra criar e rodar essas caixas.

O que um dono ganha entendendo isso:

• Isolamento. Cada aplicação na sua própria caixa significa que uma quebrando não derruba as outras. Na nossa operação, o sistema de WhatsApp, a automação e o painel rodam em caixas separadas de propósito.
• Previsibilidade. Trocar de servidor vira mais simples: você leva as caixas. Reduz o risco de "mudamos de hospedagem e tudo quebrou".
• É padrão de mercado. Quando você for vender para uma empresa com TI, eles vão perguntar "vocês rodam em container?". A resposta "sim, em Docker" é o esperado. Dizer que roda direto no servidor, sem isolamento, é sinal amador.

Você vai ouvir também a palavra Kubernetes (ou k8s). É um orquestrador de muitos containers, para operações grandes. Para a maioria das PMEs, é exagero. Vale saber que existe e que, na sua escala, provavelmente você não precisa. Tem um capítulo inteiro sobre isso na trilha de fundamentos técnicos.

O banco de dados: a peça mais crítica

Se o site é a vitrine, o banco de dados é o estoque, o caixa e o arquivo de clientes, tudo junto. É onde mora todo dado que importa: cadastros, pedidos, mensagens, histórico, valores.

Dois grandes tipos, em linguagem de dono:

• Banco relacional (SQL): organiza dados em tabelas com colunas fixas, tipo planilhas conectadas entre si. É o padrão pra quase tudo (Postgres, MySQL). Quando precisa de consistência (dinheiro, estoque, cadastro), é ele.
• Banco NoSQL: mais flexível com o formato do dado, usado em casos específicos de escala ou flexibilidade (MongoDB, Redis). Útil quando faz sentido, modinha quando aplicado sem motivo.

Na nossa operação usamos Postgres (via Supabase, um serviço que cuida do banco pra gente) e um Postgres dedicado para as mensagens de WhatsApp.

O que você precisa gravar sobre o banco, porque é a parte que mais dói quando dá errado:

• Se o banco cai ou corrompe, sua aplicação fica de pé mas vazia. Na prática, é estar fora do ar, só que pior, porque pode estar servindo dado errado.
• Backup do banco é a coisa mais importante da sua operação. Não o backup configurado, o backup testado. Isso é tão importante que tem artigo dedicado (o próximo, sobre operação).
• O banco não deveria estar aberto pra internet. Ele deveria aceitar conexão só de dentro do próprio servidor. Banco exposto pra internet é uma das falhas de segurança mais comuns e mais graves, e é exatamente o tipo de coisa que a auditoria de segurança (o primeiro artigo desta trilha) procura.

A pergunta de dono: "onde nosso banco roda, quem tem acesso a ele, e quando foi a última vez que testamos restaurar um backup?"

Onde isso tudo te expõe a risco

Agora que você tem o mapa, dá pra apontar onde mora o perigo. Três pontos clássicos, todos detalhados na trilha de segurança:

1. Banco exposto. Aberto pra internet em vez de aceitar conexão só interna. É como deixar o estoque com a porta dos fundos destrancada.
2. Secrets em texto puro. As senhas do banco e os tokens de integração às vezes ficam escritos dentro do código ou em arquivos de configuração sem proteção. Se vaza um, vaza tudo. O artigo sobre senhas trata disso.
3. Portas abertas sem necessidade. Cada porta aberta no servidor é uma porta que alguém pode tentar arrombar. O mínimo necessário aberto é o ideal.

Você não precisa consertar isso sozinho. Precisa saber que existe pra cobrar de quem cuida da sua infra, ou pra pedir uma auditoria sabendo o que está sendo auditado.

O que você consegue fazer com isso

Esse era o objetivo: sair do "aprovo no escuro" pro "entendo o que estou aprovando". Com o mapa das cinco peças, você agora consegue:

• Acompanhar uma conversa sobre migração de servidor sem se perder
• Entender por que o site demora pra mudar depois de uma alteração de DNS
• Perguntar onde o banco roda e quando o backup foi testado pela última vez
• Reconhecer os três pontos de risco mais comuns na sua própria operação
• Diferenciar fornecedor que explica do fornecedor que enrola

Você não virou programador. Virou um dono que entende a própria cozinha. É exatamente isso que separa quem aprova no escuro de quem aprova com clareza.

No próximo passo da jornada, a gente sai da estrutura e entra na operação: como monitorar para descobrir problema antes do cliente, como ter backup que funciona de verdade, e o que fazer quando algo cai.