O que é deploy? Como seu código vira um SaaS no ar

O que é deploy? É levar o seu produto do seu próprio computador, onde só você consegue vê-lo, para um servidor na nuvem onde qualquer pessoa com a URL pode usá-lo. Enquanto você constrói, seu app vive num endereço local que só a sua máquina alcança. O deploy empacota o app, envia para um provedor de hospedagem e dá a ele um endereço público. Com as ferramentas modernas, todo esse caminho — de salvar o código até um site atualizado no ar — leva cerca de 2 minutos.

Se você é um fundador não técnico construindo com IA, o deploy é o momento em que o seu projeto deixa de ser um arquivo num notebook e passa a ser um negócio. Aqui está o quadro completo, com o jargão traduzido.

Local vs. produção: cozinhar em casa vs. tocar um restaurante

Todo app vive em dois mundos. O desenvolvimento local é o seu computador: só você vê o app, as mudanças aparecem na hora e as mensagens de erro mostram tudo, porque a única pessoa que vai lê-las é você. É onde você constrói, testa e experimenta à vontade.

A produção é a versão no ar que os usuários reais tocam. O código é otimizado para velocidade, as mensagens de erro são vagas de propósito (erros detalhados vazam informações que atacantes podem usar) e o app roda numa infraestrutura que escala automaticamente quando o tráfego cresce.

A analogia que fixa a ideia: o local é cozinhar em casa — só você e sua família comem. A produção é um restaurante — o público pode pedir. O deploy é abrir as portas.

O que é deploy: o que acontece quando você faz deploy

O deploy esconde duas etapas. Primeiro vem o build. Seu código de desenvolvimento está espalhado em muitos arquivos legíveis, escritos para humanos. A etapa de build junta tudo em poucos arquivos compactos, remove o que não é usado e encolhe o que sobra para as páginas carregarem rápido. Pense nisso como embalar o seu app a vácuo para envio — o mesmo produto, numa fração do tamanho.

Depois vem o upload. Os arquivos gerados vão para os servidores de um provedor de hospedagem. Dá para fazer isso manualmente, mas ninguém faz mais. O jeito moderno é a integração com git: você conecta o seu repositório de código à hospedagem uma vez e, a partir daí, cada vez que você envia código, a hospedagem puxa automaticamente a versão mais recente, faz o build e atualiza o site no ar. Código salvo → site no ar, em cerca de 2 minutos, sem nenhuma etapa manual. Essa automação se chama deploy contínuo, e é o motivo pelo qual fundadores solo conseguem lançar todo dia. (Por que você deveria lançar com essa frequência é outra história.)

Onde o seu SaaS realmente mora: hospedagem

Hospedagem é alugar espaço em servidor para o seu produto rodar na infraestrutura de outra empresa — junto com o básico nada glamouroso: certificados de segurança para o cadeado na barra do navegador, uma rede global de entrega para o seu app ser rápido em qualquer lugar e proteção contra ataques. Os três grandes nomes para fundadores solo:

Os três são excelentes; eu recomendo o Cloudflare Pages pela banda gratuita ilimitada. Mas a hospedagem só cobre o seu frontend — a parte que os usuários veem. O seu backend — banco de dados, contas de usuário, armazenamento de arquivos — fica separado, normalmente no Supabase. O plano gratuito dele (um banco de 500MB, 1GB de armazenamento de arquivos, 50.000 usuários ativos por mês) cobre um MVP com folga; o plano Pro de US$ 25/mês acrescenta backups diários e mais espaço quando você crescer. Dois serviços, e o seu produto inteiro está no ar. É uma grande parte do motivo pelo qual o custo total de construir um SaaS despencou.

O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →

Um código, configurações diferentes: variáveis de ambiente

Seu app local deve conversar com um banco de dados de teste; seu app no ar precisa conversar com o banco real. Mas é o mesmo código. A resposta são as variáveis de ambiente — configurações que ficam fora do código e mudam conforme o ambiente. Localmente, elas apontam para serviços de teste com chaves de teste. Em produção, o provedor de hospedagem injeta os valores reais durante o build.

Isso importa tanto para a segurança quanto para a conveniência: as chaves secretas nunca são escritas no código, então nunca acabam visíveis publicamente no seu repositório. Mesmo código, valores diferentes, segredos fora de vista.

Deploys de pré-visualização: teste a mudança antes de ir ao ar

Aqui está um recurso que parece mágica na primeira vez. Quando você prepara uma mudança num branch separado do seu código, a hospedagem faz deploy automático dessa versão numa URL privada própria. Você pode navegar pela nova funcionalidade num ambiente parecido com o de produção, compartilhar o link para receber feedback e só juntar ao site no ar quando estiver certo. Se estiver errado, você descarta — a produção nem fica sabendo.

Quando um deploy dá errado: o rollback de 30 segundos

Em algum momento você vai lançar um bug. O velho instinto — achar, corrigir sob pressão, fazer deploy de novo, rezar — é o movimento errado. Todo deploy que você já fez fica guardado, e a plataforma permite fazer rollback: clique na última versão que funcionava, confirme, e o site no ar volta atrás. Tempo de recuperação: cerca de 30 segundos. Depois você corrige o bug com calma, testa e faz deploy de novo quando estiver pronto.

Essa rede de proteção muda mais a sua psicologia do que o seu processo. O deploy deixa de ser um evento de alto risco e vira rotina — que é exatamente como você deveria tratá-lo.

12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →

Perguntas frequentes

O que significa fazer deploy de um app?

Fazer deploy significa pegar o app que roda só no seu computador, empacotá-lo num pacote otimizado e enviá-lo a um provedor de hospedagem para que fique no ar na internet com uma URL pública. As plataformas modernas automatizam tudo: envie o seu código e o site no ar se atualiza sozinho em cerca de 2 minutos.

Qual é a diferença entre local e produção?

O local é a sua oficina particular — só você vê o app, e ele está configurado para experimentação rápida, com erros detalhados. A produção é a versão pública — otimizada para velocidade, conectada ao banco de dados real, com mensagens de erro vagas por segurança. O mesmo produto, dois ambientes, configurações diferentes por meio de variáveis de ambiente.

Quanto tempo leva um deploy?

A primeira configuração — conectar o repositório, adicionar as variáveis de ambiente, apontar o domínio — leva uma tarde, e um build roda em 2–5 minutos. Depois disso, todo deploy é automático: envie o código, espere uns 2 minutos, e o site no ar está atualizado. Domínios próprios exigem uma mudança única de DNS que pode levar até 24 horas para se propagar.

O que acontece se eu fizer deploy de um bug?

Você faz rollback. As plataformas de hospedagem guardam todos os deploys anteriores, então voltar para a última versão que funcionava leva cerca de 30 segundos pelo painel. Corrija o bug localmente sem pressão e faça deploy de novo. Os deploys de pré-visualização pegam a maioria dos bugs antes mesmo de eles chegarem à produção.