Medo de subir em produção: como eu perdi o meu (e o método que funcionou)

Este texto é pra quem é do bem: gente que está desenvolvendo, que quer o melhor pra si e pra família, mas trava na hora de colocar um IP público no ar e dizer "agora é minha vez de vender". Um aluno da imersão de sites escreveu isso no chat — tem boas ideias, faz as coisas, mas tem medo de subir em produção. Este artigo é pra ele também.

O método, em cinco pontos:

• Enfrente: bota no ar e deixa quebrar — mas com a obrigação de aprender com cada queda.
• Observe: log em tudo, do usuário e do próprio sistema. Quem fez o quê, onde, quando.
• Tenha rollback: plano de volta pronto antes de precisar dele.
• Não volte no desespero: investigue com o log na mão, depois restaure.
• Comece de graça: beta gratuito e avisado, com limite de uso, até o medo passar.

Este artigo é a versão escrita do vídeo publicado no canal em 3 de setembro de 2026 — sem corte, gravado por quem cuida de datacenter e paga a conta quando o trem cai. Assista e leia junto:

O medo é legítimo — e eu também tive

Antes de qualquer dica, o principal: ter medo não é sinal de que você é ruim. É sinal de que você entendeu o tamanho da coisa. Você sabe a dor que é o negócio cair, ser invadido, e sabe quem depende daquilo funcionar.

Eu sou dono de empresa e virei hands-on de novo justamente por medo — pra entender como funcionava e não ficar refém de ninguém. Já fiquei. Já quase quebrei a empresa por confiar em quem era tecnicamente capacitado mas não queria fazer, e em quem queria muito mas não tinha capacidade técnica. Isso não é sobre ser júnior ou sênior; é sobre segurança — a sua e a de quem depende de você.

A lista dos meus medos é longa e específica:

Some a isso o cenário de hoje: na era da IA, qualquer concorrente que não vai com a sua cara consegue direcionar um ataque com muito mais facilidade. Derrubar uma máquina virtual mal configurada é trivial pra quem entende. Pra quem não entende, é desespero puro — e é aí que o medo trava tudo.

A primeira lição não veio de um servidor. Veio do Paraguai.

Eu tinha uns 20 e poucos anos e uma loja de informática. Comprava da Zona Franca de Manaus, até me falarem que no Paraguai era bem mais barato. Fui. E fui morrendo de medo: coloquei dinheiro na cueca e dentro dos dois tênis, porque pensei "não é possível que, se me assaltarem, levem tudo de uma vez". Pelo menos o dinheiro de voltar pra casa eu tinha que garantir.

A travessia era a Ponte da Amizade, na aduana antiga, sem segurança nenhuma — gente correndo, pegando coisa e fugindo. Eu passei com frio na barriga, entrei nas lojas com medo, e voltei. Na segunda vez foi menos. Na terceira eu já ia tranquilo. Eu sabia como funcionava, sabia as peças que comprava, sabia onde ia e a que horas voltar.

É exatamente a mesma mecânica de um deploy. O que mudou entre a primeira e a terceira viagem não foi coragem: foi informação coletada em campo.

Queimei a placa-mãe do primeiro servidor que desmontei

Anos depois, antes de ter o meu próprio CDN, eu alugava servidor em datacenter dos outros. Comprei uns servidores IBM usados — isso há uns 8 anos, na sede antiga — só pra testar aqui dentro se o que eu tinha aprendido valia também pra esse mundo, porque eu já pretendia ter o meu datacenter.

Eram máquinas de peso: placa-mãe com dois processadores físicos, 16 núcleos cada — 32 núcleos — e 256 GB de memória RAM. Coisa cara. E eu queimei o primeiro. Fiz na placa-mãe algo que não podia e estourei. Ele ainda ligava, mas a performance ficou péssima; tentei reconfigurar, regravar tudo, não teve jeito. E não existia IA pra me ajudar: era documentação e mão.

O que eu fiz com medo? Fui de novo. Comprei outro servidor, deixei os dois lado a lado, estudei o que tinha feito de errado, desmontei, montei e acertei. E o meu "desmontar" não é trocar processador e memória — é entender cada peça: chassi com seis portas SATA e espaço físico pra quatro, placa de rede 10 GB nativa, GBIC de fibra, controle de ventoinha, IPMI pra ligar e desligar o servidor pela internet.

Cada medo enfrentado me devolveu uma lição concreta. No Paraguai, aprendi o caminho. No servidor queimado, aprendi o que não repetir — e na segunda vez não aconteceu.

A dica fundamental: observabilidade

Aqui está o pulo do gato, e ele explica por que "enfrentar o medo" sozinho não basta: como você vai perder o medo se você não sabe o que aconteceu?

Quando fui ao Paraguai, eu observei — as lojas, o trajeto, o horário de ir e de voltar, onde dava pra passar e onde não dava. Anotei e aprendi. Quando queimei o servidor, observei o erro e corrigi. Queda sem observação não ensina nada: você cai dez vezes e aprende o mesmo que caindo uma.

É a briga que eu compro com o time até hoje. Aconteceu um problema, eu pergunto: o log fala o quê? E vem a resposta que me tira do sério: "não botei log". De estagiário eu ainda engulo. De alguém com dois, três, quatro anos de estrada, não dá.

O plano pra subir sem quebrar o seu negócio

Se você tem medo e quer colocar o sistema online, não suba já vendendo. Suba gratuito, com o aviso na cara: versão beta, de graça, pode quebrar. Deixa rodar, deixa o povo usar dentro de um limite aceitável e vai aprendendo com o que aparece. Assim você perde o medo com o custo baixo — e não com o cliente pagante no meio.

Junto com isso, duas coisas que precisam estar prontas antes:

Essa mesma disciplina é o que sustenta um pipeline sério quando existe usuário do outro lado — assunto que eu detalhei no artigo sobre a migração de mais de 3 TB de e-mail: staging, QA, pré-produção e liberação parcial existem justamente pra que o "deixa quebrar" aconteça longe de quem paga.

Você não precisa entender tudo de uma vez

Rede, infraestrutura, proxy, DNS, SSL, Docker, banco de dados, cluster, banco em memória: você não precisa ser o cara que entende tudo isso pra começar. Se você tem medo, é porque ainda não entende — e está tudo bem, é assim mesmo.

O domínio chega por camada, conforme a necessidade bate na porta: quando precisar escalar o banco, quando precisar de job assíncrono, de mensageria, de banco em memória, de storage distribuído, de entender o custo desse storage, de decidir se vai ter teste grátis, de escolher gateway de pagamento — e aí pode compensar pagar 0,1% a mais numa API por causa da política de chargeback — e até de fazer SEO do software, que é mais importante do que parece.

Isso leva tempo. Virar sênior significa que você passou muita raiva ao longo dos anos e absorveu a informação. A diferença de hoje é que a IA acelera isso de forma absurda: nesses últimos dois anos e meio, três, eu aprendi coisa que levaria dez — porque ela testa, prototipa e reproduz a falha comigo. Mas tem um porém que não dá pra pular: você precisa entender o que ela está fazendo. Entender o log, entender o que aconteceu, reproduzir a queda. Aí o aprendizado é infalível.

E tem uma parte do medo que não passa com estudo — passa com decisão de arquitetura: por que eu não uso GitHub, Supabase ou Firebase em produção é a outra metade dessa conversa, a que trata do tamanho do alvo que você oferece quando entrega a sua produção pra um ambiente compartilhado.

Vale lembrar também que o medo às vezes não é técnico: é de quem depende de você. Esse é o mesmo pano de fundo que eu tratei em acabou pro dev chinelinho — o mercado não está atrás de quem sabe tudo, está atrás de quem resolve e assume.

Perguntas frequentes