O que todo vibe coder descobre tarde demais ao subir pra produção

De onde eu falo

Você conhece o meme: a pessoa passa o software pro outro testar e o link é localhost:3000. É sobre isso. Por que só funciona na sua máquina, e o que você precisa saber pra funcionar fora dela.

Vou dar minha carteirada antes. Eu sou CEO de uma empresa de tecnologia de verdade e engenheiro de infraestrutura. Cuido de servidor no Brasil e fora do Brasil, data center mesmo, pra valer, com a nossa própria engenharia de rede, entregando tráfego pra milhões de usuários todos os dias. Tenho empresa desde os 18 anos e estou na trincheira há muito tempo.

Eu ponho a mão na massa. Então a visão que eu trago não é só a do CTO nem só a do dev, cada um na sua bolha. É a de quem paga a conta. Pode não ser a realidade da sua empresa. É a que eu vivi.

A sua máquina é um ambiente perfeito

Na minha máquina funciona. Claro que funciona. A sua máquina é o ambiente ideal:

• tem um usuário, que é você;
• não tem problema de IO, que é o uso do disco, a leitura e a escrita;
• não tem latência;
• a CPU está com consumo baixíssimo;
• o storage é um só: o seu disco local. No Windows é o drive C, no Linux é a sua pasta home.

É tudo ali, é perfeito. (E se você é vibe coder e ainda está no Windows, tá na hora de migrar pro Linux, pra trabalhar um pouquinho mais dentro das ferramentas.)

Aí você faz o software rodando local, posta no LinkedIn, faz vídeo, e quer mandar pro cliente, pro colaborador, pro tio, pra empresa de um amigo testar. Como você sobe isso?

A nuvenzinha da ferramenta e a VPS do youtuber

Hoje você tem as opções das próprias ferramentas de IA. O Manus, o Claude, a galera toda está colocando uma nuvenzinha ali pra você publicar com o subdomínio deles e ficar dependente. Pra depois cobrar, obviamente. Tem hora que a gente tem que fazer a conta de até que ponto vale a pena usar a nuvem. Eu fiz a minha, e conto em migrei da nuvem pro on-premise.

A outra opção é a que você viu na propaganda do youtuber: subir numa VPS do fulano de tal. Uma primeira versão, com um usuário, dois, sem concorrência e sem latência, dá pra subir numa VPS? Dá.

Mas aí você já tem que pensar em como vai funcionar o seu storage, o seu backup e a sua auditoria. E é aqui que começa o checklist.

Quem fez o quê, onde e quando

Pausa e anota. Quem fez o quê, onde e quando. Isso é regra essencial pra colocar qualquer coisa em produção. Cria um checklist e prega na parede.

Por quê? Porque quando alguém está te pagando e dá um pau, você precisa ter como comprovar o que aconteceu. Pra você mesmo e pro seu cliente. Foi erro do sistema ou foi erro de usuário?

Porque o usuário é maravilhoso. Os caras têm cada jeito de usar o sistema que não foi previsto, que é um espetáculo. E é muito bom que seja assim. Só que sem auditoria você não tem como cobrar das pessoas nem como se defender.

Log já foi briga aqui na empresa. Briga, que você não acredita, pra meter log no sistema. Eu conto o que acontece quando o log existe, e quando ele vira 30 GB pra ler, em observabilidade: os 30 GB de log que eu tive que ler.

Backup que nunca foi restaurado não é backup

Você vai rodar um banco de dados ali e botar um cliente pra testar. Você precisa de log desse negócio, backup desse negócio, monitoramento desse negócio. E rollback.

Erro absurdo que eu já vi: a pessoa faz o backup do banco de dados e nunca testou restaurar. Vai ver, o backup está corrompido. Vai ver, ela não sabe restaurar.

"Ah, mas hoje a IA me dá o comandinho pra restaurar." Com 1 GB de banco, 2 GB, é facinho. Vai restaurar 200 GB. Vai restaurar 6 TB, que aí já é um Elastic, outro tipo de banco, não relacional. A restauração depende bastante de cada banco. MySQL e MariaDB, que estão em tudo quanto é cursinho, são uma coisa. O Postgres, que é um banco super resiliente e que a IA popularizou de vez (ela anda recomendando Postgres pra tudo), é outra.

Então, pelo amor de Deus: fez o backup da VPS que você está usando pra testar? Mata a VPS, faz o restore e vê se deu certo.

Porque mais cedo ou mais tarde vão te invadir. Se você é vibe coder, você vai ser invadido. Eu vi um monte de canal de gente famosa no YouTube com aplicação invadida, derrubada. Então tenha o snapshot certinho e programe os horários. Dependendo da criticidade do cliente, pode ser de hora em hora. O que te impede é grana, ou o lugar onde você contrata só permitir de 24 em 24 horas. Dá pra fazer na mão também, com o dump do banco da aplicação.

Eu levo isso a sério a ponto de derrubar a minha produção de propósito. Está em eu testo restore e derrubo a produção.

Agora tem camada no meio: proxy, SSL e limite de upload

Você sobe pra VPS, instala tudo igual está na sua máquina, deixa rodando. Aí precisa de um proxy na frente. Em geral é sempre um proxy: nginx, HAProxy ou Traefik são os três mais comuns.

Aí precisa do SSL. Vai usar o da Cloudflare, que é o mais popular entre os que te entregam de graça? Então responde: você vai mexer com upload de vídeo grande, de áudio, de arquivo de gráfica? Qual é o limite que a Cloudflare aceita você mandar? E o seu proxy, está configurado pra esse limite?

Olha os problemas que você não tinha no localhost. Agora tem camada no meio.

Fui conferir os dois números na documentação. No nginx, o tamanho máximo do corpo de uma requisição vem em 1 MB por padrão (client_max_body_size 1m). Passou disso, o cliente recebe erro 413. Na Cloudflare, o limite de upload depende do plano: 100 MB no Free e no Pro, 200 MB no Business, e o erro também é o 413. São dois limites diferentes, em duas camadas diferentes, e o upload do seu cliente tem que passar pelos dois.

Pra mim, usar o SSL da Cloudflare não faz o menor sentido. Aplicaram um rate limit numa das contas que a gente tem lá, uma vez, porque ficou ativado por umas seis horas com um tráfego gigantesco. Foi erro de configuração nosso. Mas você entende: a análise de usar ou não é sua, e depende do que você trafega. A história inteira está em os limites da Cloudflare que ninguém te conta.

Como eu escalei por DNS, 15 anos atrás

Lá no nosso comecinho a gente escalou baseado em DNS. Pro cliente um eu passava um endereço da plataforma. Pro cliente dois, outro. Pro cliente três, cliente03.plataforma.com. Cada um com um login separado.

Estou falando de 15 anos atrás, não me julguem. Era o jeito que eu tinha. Eu estava vendendo muito, a aplicação não estava pronta pra escalar horizontal e a equipe nova ainda estava construindo isso.

Na prática era uma aplicação por VPS e um DNS apontando pra ela. Aquele banco de dados, aquele backup, aquele snapshot eram só daquele cliente.

É porco, eu sei. Mas foi o que pagou a minha conta lá atrás. E nada impede você de fazer igual no começo.

Enquanto eu tinha 40, 50 clientes, eu controlava isso na mão. Com 100 era apertado, mas a equipe controlava. Chegou num ponto em que ficou totalmente descontrolado. Aí eu precisei clusterizar o banco de dados.

Cluster de banco: o ID pula e o insert tem lugar certo

Aqui começa a complicar. Imagina que a sua aplicação faz o insert, depois faz o get e fica esperando o mesmo ID, em sequência. Quando você clusteriza um MariaDB, o ID passa a pular: de quatro em quatro, de cinco em cinco, de sete em sete, de acordo com a quantidade de nós.

Fui ver como a documentação descreve isso. No MariaDB Galera Cluster existe a variável wsrep_auto_increment_control, ligada por padrão. Ela ajusta sozinha o incremento e o deslocamento do auto-incremento conforme o tamanho do cluster, e reajusta quando o tamanho muda, pra evitar conflito de replicação. É por isso que o ID pula.

A sua aplicação está pronta pra isso?

E tem o insert. Quando você clusteriza, você tem que dar insert por um lugar só. Se a aplicação sair fazendo insert em dois, três pontos do cluster, vai dar split brain, vai dar pau no sistema. Você está checando isso direitinho? Como você vai resolver? Mais um item pro checklist.

Às vezes a saída é mais um proxy, agora na frente do banco. Então repara no desenho: banco, proxy na frente do banco, aplicação, proxy na frente da aplicação. No localhost não tinha nenhum dos dois.

Mais de uma réplica: a sessão de login mora onde?

Agora você precisa escalar. A aplicação funciona com um proxy na frente distribuindo pra várias réplicas?

O furado que eu vejo cursinho raso ensinando por aí: no Docker Swarm você vai lá e bota dez réplicas; no Kubernetes você ativa o autoscale. É a escala baseada em cartão de crédito. Mas a aplicação está pronta pra isso?

E autoscale não é automático. Ele é baseado em métricas que você define pra decidir se escala ou não. Não é "sobe agora". Precisa de previsibilidade e de monitoramento. A documentação do Kubernetes diz exatamente isso: o autoscaler horizontal ajusta a escala pra casar com métricas observadas, como uso médio de CPU, de memória ou uma métrica customizada sua. Na AWS é igual: o grupo escala dentro do mínimo e do máximo, seguindo as políticas e os critérios que você especifica. Eu abro esse assunto inteiro em autoscale não salva aplicação mal feita.

Com dois, três, quatro contêineres, a pergunta que derruba é a da sessão logada. O usuário fez login num contêiner. O proxy manda a próxima requisição pra outro. E a sessão? Você vai guardar em memória? Num Redis? Onde? O usuário vai logar e ser deslogado, ou você vai travar o login num lugar só?

E toda vez que a gente escala, volta a mesma regra: tem que estar claro quem fez o quê, onde e quando.

Erro, timeout e retry: o que o localhost esconde

No localhost é só uma rotinha rodando. Quando você escala e põe um proxy na frente, precisa tratar os erros que voltam. Erro tem que tratar de qualquer jeito, mas tem uma tratativa que quase nunca existe em aplicação de quem não sabe escalar: o retry de timeout e de erro de conexão.

A conexão demorou demais e ninguém tratou o timeout. O que a aplicação faz? Isso vale pra API externa e vale pra sua própria API.

É básico. Um curso decente te manda tratar todos os erros, todos os 500, todos os 400, e dizer o que fazer em cada cenário. Agora pergunta se o vibe coder vai tratar.

"Vou pedir pra IA fazer isso pra mim." Cuidado. Você tem que saber de arquitetura pra não matar formiga com bala de canhão. Senão a IA vai mandar você matar com bala de canhão, e você vai gastar uma baba de dinheiro fazendo um tanto de coisa que às vezes não precisa. Tem que entender a regra de negócio do seu negócio.

Performance e observabilidade

Um dos objetivos de ter um sistema em produção é melhorar a experiência do usuário. No meu caso, player lento mata o meu negócio. Player tem que ser rápido. No seu caso, o que é que precisa ser rápido pra não dar experiência ruim pro cliente?

Você descobre observando. As ferramentas mais usadas são o Loki, o Prometheus e o Grafana. Você põe ali os logs completos e os números da sua própria VPS: uso de memória RAM, de disco, se o disco é NVMe ou um mais lento. Tudo isso numa dashboardzinha, com as métricas que importam pra você decidir.

O deploy: eu também meti em produção primeiro

Vou dar um exemplo meu. Eu fiz uma ferramenta de transcrição ao vivo. Ainda não botei no mercado pra valer, pra vender, mas já rodou em evento.

O que eu fiz? Primeiro subi em produção. Quebrei o pau, escalei, testei como ela se comportava com escala. Fiz a produção funcionar. E só com a produção funcionando eu fui aplicar os patches de segurança, essa coisa errada toda, em produção.

É o que o vibe coder vai fazer: meter em produção primeiro, porque quer ver o trem funcionando, e se preocupar depois com tudo isso que eu falei. E é normal. Pra mim sempre foi assim. Eu fiz teste de throughput, teste de carga e teste de performance em produção.

Lógico que tem forma de fazer. Você testa com 10% da audiência. Testa em horário de menos pico. E, dependendo da criticidade (rota de roteador pra operadora, anúncio de prefixo, mudança drástica de rota), tem que fazer uma análise antes.

Só que depois chega a hora de ajeitar o negócio.

Git e staging com URL separada: o mínimo pra dar update

Aplicou a segurança? Agora você precisa de um Git. Não necessariamente GitHub ou GitLab. Git é um troço que você pode ter num pen drive e fazer o mesmo versionamento. A magia dele é essa: você tem as versões e roda o rollback na hora que quiser.

Versionamento é obrigatório pra subir pra produção. E, junto com ele, pelo menos um ambiente separado pra você desenvolver, com URL separada. Uma VPS de staging, com banco de dados próprio. Porque não dá pra fazer update em produção sem testar. Ainda mais hoje, que a IA abre um Playwright e faz o teste de ponta a ponta pra você. É facinho de fazer. Mas você precisa ter duas versões do seu sistema.

Numa empresa maior, com ambiente grande e burocrático pelo tamanho, a gente tem mais degraus:

1. a máquina do dev, o "no meu local funciona";
2. sandbox, onde o dev testa já integrando com as outras aplicações;
3. staging, onde o QA faz o teste;
4. pré-produção, onde eu subo a feature e testo com dados de produção, pra alguns clientes específicos;
5. produção.

No seu caso, vibe coder, basta um: sandbox ou staging, chame como quiser. Sobe ali, com tudo separado, faz os testes. Deu certo, faz o merge e põe em produção.

E atenção ao downtime. "Meu contêiner gasta dois, três minutos pra subir." Cuidado pra não gerar experiência ruim em momento de pico.

Rollback é de tudo. Com o Git ligado em staging e produção, você volta a versão antiga rapidinho, no GitLab ou no GitHub. Na AWS, no Kubernetes e no Docker Swarm também dá. Dá até pra colocar hooks pra testar antes, mas aí já é um troço mais avançado.

O checklist, pra pregar na parede

Eu nem entrei em todos os pontos. Tem pontos maiores, principalmente de segurança, que eu deixei de fora de propósito. Estou sendo superficial aqui, e o sênior já está careca de saber tudo isso. O ponto é você entender a arquitetura.

Nota de cronologia. Quando eu gravei, em junho de 2026, eu ainda devia o vídeo sobre os cuidados com VPS e estava montando um grupo no WhatsApp pra fazer aula ao vivo. De lá pra cá eu escrevi VPS ou Vercel: a conta por requisição que eu não pago, e o que existe hoje de aula está na página das imersões. A de SaaS em Produção é a que trata deste assunto.

Fecho com a frase que eu deixei anotada pra terminar a gravação: o sistema não precisa aguentar milhões, mas precisa aguentar o cliente real usando do jeito errado, na hora errada. Segue o checklist pra sua aplicação não funcionar só na sua máquina. Pra ela funcionar, e você poder vender e fazer dinheiro com ela.

Perguntas frequentes