Seu site funciona perfeitamente no computador, mas só você o vê. Para que outras pessoas acessem, o projeto precisa ser publicado em um servidor conectado à internet. Esse processo se chama deploy. Antigamente exigia comprar hospedagem, enviar arquivos por FTP e configurar tudo à mão. Hoje, plataformas como Vercel, Netlify e outras reduziram isso a poucos cliques.
Para entender onde isso se encaixa no todo, vale conhecer o básico de domínio, hospedagem e DNS.
O que acontece num deploy moderno
O fluxo típico é bem parecido nas diferentes plataformas:
- Você guarda o código num repositório (GitHub, GitLab ou similar). Se Git ainda é novidade, veja Git e GitHub para iniciantes.
- Conecta o repositório à plataforma autorizando o acesso.
- Informa como construir o projeto: o comando de build e a pasta com o resultado final. Para frameworks conhecidos, a plataforma costuma detectar sozinha.
- Cadastra as variáveis de ambiente (chaves e senhas), no painel e não no código.
- A plataforma faz o build em servidores dela, publica os arquivos e entrega um endereço de teste.
- A cada novo push no repositório, ela repete o processo e publica a nova versão.
Essa automação é chamada de deploy contínuo. Você só escreve código e envia; o resto é com a plataforma.
Vantagens desse modelo
- HTTPS automático. O certificado de segurança é emitido e renovado sozinho (veja o que é certificado SSL).
- Rede de distribuição de conteúdo. Os arquivos são servidos de vários pontos do mundo, o que acelera o carregamento.
- Versões de pré-visualização. Em muitas plataformas, cada branch ou proposta de mudança ganha um endereço próprio para testar antes de publicar.
- Reversão rápida. Se uma versão der problema, dá para voltar à anterior.
- Pouca manutenção de servidor. Você não precisa atualizar sistema operacional nem cuidar de segurança do servidor.
Diferenças entre os tipos de projeto
O que você pode publicar depende da natureza do projeto:
- Site estático: HTML, CSS e JavaScript prontos, sem código rodando no servidor. É o caso mais simples e mais barato de hospedar.
- Site com renderização no servidor ou funções: frameworks como o Next.js (veja React e Next.js) executam código no servidor. As plataformas costumam oferecer isso em formato de funções sob demanda, em que o código roda quando alguém acessa e não fica ligado o tempo todo.
- Aplicação com servidor permanente: sistemas que precisam ficar rodando continuamente, com conexões abertas ou tarefas em segundo plano. Algumas plataformas de nuvem atendem esse caso, mas pode ser melhor usar um servidor próprio (VPS).
- Banco de dados: quase sempre fica em um serviço separado, ao qual o projeto se conecta pelas variáveis de ambiente.
Vercel, Netlify e outras: como escolher
Os serviços mudam planos e recursos com frequência, então decida pelos critérios, não por listas fixas:
- Tipo de projeto: o framework que você usa é bem suportado? Algumas plataformas têm integração especialmente boa com certos frameworks.
- Limites do plano gratuito: transferência de dados, tempo de execução das funções, número de builds e uso comercial permitido.
- Recursos extras: formulários, autenticação, armazenamento, agendamento de tarefas.
- Onde fica o banco de dados e como se conectar a ele.
- Preço quando o projeto crescer. Veja a política de cobrança por uso para não ter surpresa.
- Facilidade de sair: se o projeto é um repositório com configuração simples, trocar de plataforma depois é possível.
Outros serviços de nuvem, como Cloudflare Pages, Render ou Railway, seguem lógica parecida, cada um com seus pontos fortes.
O que preparar antes do primeiro deploy
- Rode o build localmente e confirme que funciona. Se falha no seu computador, falhará na plataforma.
- Revise o .gitignore para que .env e arquivos de segredo não subam.
- Liste as variáveis de ambiente necessárias e prepare os valores (veja variáveis de ambiente e arquivo .env).
- Confira a versão do Node ou do Python que seu projeto usa, e configure a mesma na plataforma.
- Teste o site publicado no celular e em outros navegadores.
Deploy contínuo e o cuidado com o que vai ao ar
A publicação automática é cômoda, mas tem uma consequência: tudo o que chega na branch principal pode ir direto para o site real. Para não publicar algo quebrado sem querer:
- trabalhe em branches e só junte à principal depois de testar;
- use as versões de pré-visualização que a plataforma gera para cada proposta de mudança;
- rode os testes automáticos antes da publicação, quando houver;
- saiba como voltar para a versão anterior no painel;
- evite publicar mudanças grandes em horários de pico de acesso.
Esse cuidado parece exagero em projetos pequenos, mas vira hábito rapidamente e evita sustos quando o site passa a ter visitantes reais.
Problemas comuns no primeiro deploy
- Build quebra só na plataforma: versão diferente de Node, variável de ambiente ausente ou dependência que só existe na sua máquina. O log do build mostra a causa; aprenda a ler com como ler mensagens de erro.
- Página abre, mas dados não carregam: a variável de conexão com o banco ou a API não foi cadastrada.
- Erro 404 ao atualizar uma página interna: em sites de página única, falta configurar o redirecionamento para o arquivo principal.
- Endereço estranho: a plataforma entrega um endereço próprio. Para usar o seu, veja domínio próprio em projeto publicado.
Escolha uma plataforma, publique um projeto pequeno e teste o fluxo de atualização. Entender o ciclo de código, build e publicação com um exemplo simples é o que deixa os próximos deploys sem susto.