Você pediu para uma IA montar um app, ele funcionou, ficou bonito e roda perfeitamente naquela janelinha de preview da ferramenta. Aí veio a pergunta simples: como coloco isso no ar para meus clientes usarem? E a resposta parou de ser simples. A URL é aquele endereço estranho com o nome da plataforma, os dados de teste somem de vez em quando, e ninguém explica onde exatamente esse app está rodando.
Essa é a etapa que quase nenhum tutorial de vibe coding cobre, porque ela não tem nada de mágica: é infraestrutura. Neste guia você vai ver, em ordem, como fazer deploy de app criado com IA saindo do preview para um domínio seu, com banco de dados de produção, HTTPS e backup funcionando. Sem promessas de "em cinco minutos", e com os pontos onde as coisas normalmente quebram.
O que "estar no ar" realmente significa
No preview da ferramenta, seu app roda dentro de um ambiente emprestado. A URL é temporária, o banco de dados costuma ser de teste (às vezes some quando o projeto fica parado), e o acesso muitas vezes depende da sua conta na plataforma. Isso é ótimo para mostrar a ideia e péssimo para operar um negócio.
Colocar de verdade no ar significa quatro coisas separadas, e é justamente por serem separadas que a etapa confunde tanto:
- Hospedagem: um servidor que executa seu app 24 horas por dia. Deploy é o nome do processo de mandar seu código do computador (ou do preview) para esse servidor.
- Domínio: o endereço que as pessoas digitam. Sem ele, você divulga um link com nome da ferramenta e cara de rascunho.
- Banco de dados de produção: onde ficam os dados reais dos seus clientes, separado do banco em que você testou.
- Backup: cópia periódica desse banco, guardada fora do servidor.
Se faltar qualquer um dos quatro, você não tem um app no ar; tem um protótipo hospedado.
Passo 1: separe o que é frontend e o que é backend
Antes de contratar qualquer coisa, descubra o que seu app é. Isso muda tudo no deploy.
Frontend é a parte visual, que roda no navegador do usuário. Backend é a parte que roda no servidor: login, regras de negócio, integrações e acesso ao banco. Muita gente gera um app com IA sem saber qual dos dois recebeu.
| Se o app... | Provavelmente é | Deploy típico |
|---|
| Só mostra páginas e formulários, sem login nem dados salvos | Site estático / frontend puro | Hospedagem simples ou plataforma de sites estáticos |
| Tem cadastro, login, painel, dados que persistem | App com backend + banco | Plataforma de aplicação + banco gerenciado |
| Salva dados mas você nunca configurou banco nenhum | Usa o banco embutido da ferramenta | Exige migração antes de ir ao ar |
Esse terceiro caso é o mais comum e o mais perigoso. Ferramentas de vibe coding frequentemente entregam persistência "mágica" ligada à conta delas. Funciona no preview, some no dia em que você quiser sair da plataforma.
Passo 2: tire o código de dentro da ferramenta
Regra prática: se você não consegue baixar o código, você não é dono do app. Antes de qualquer deploy, procure a opção de exportar ou conectar ao GitHub.
GitHub é um serviço onde o código do projeto fica guardado com histórico de versões. Além de backup, ele é o ponto de partida da maioria das plataformas de hospedagem modernas: você conecta o repositório e cada atualização vira um deploy novo automaticamente.
Ao exportar, confira se veio junto:
- O arquivo de dependências (lista das bibliotecas que o app usa).
- Instruções de como rodar localmente.
- O modelo do banco (as tabelas e campos), se houver.
- As variáveis de ambiente — os valores sensíveis como senha do banco e chaves de API, que ficam fora do código.
Se algo disso não veio, o app depende de uma peça que só existe dentro da plataforma. Descobrir isso agora custa uma tarde; descobrir depois de divulgar custa o projeto.
Passo 3: escolha a hospedagem certa (e sem drama)
Não existe "melhor hospedagem". Existe a que combina com o tipo do seu app e com quanto você quer mexer em servidor.
- Plataformas de deploy automático (as que conectam no GitHub e sobem sozinhas): melhor caminho para quem não é dev. Você quase não toca em configuração. Costumam ter plano gratuito para testes e planos pagos que, no Brasil, normalmente ficam na faixa de algumas dezenas de reais por mês para projetos pequenos — mas o valor varia muito com tráfego e uso.
- Hospedagem compartilhada tradicional: barata e familiar para quem já teve site, boa para apps PHP simples. Ruim para apps que exigem processos rodando continuamente.
- Servidor próprio (VPS): controle total, custo previsível, e responsabilidade total. Se ninguém na sua equipe atualiza servidor, evite.
Um alerta honesto: plano gratuito de plataforma costuma "dormir" quando ninguém acessa. O primeiro visitante depois de horas parado espera dezenas de segundos para a tela abrir. Para um portfólio, tudo bem. Para um cliente pagante, não.
Passo 4: banco de dados de verdade e migração dos dados
Essa é a etapa que mais trava gente com app pronto. O banco do preview quase nunca é o banco que você vai usar em produção.
O caminho seguro tem três movimentos:
- Contrate um banco gerenciado. "Gerenciado" quer dizer que o fornecedor cuida de atualização, disponibilidade e backup automático. Vale muito mais a pena do que instalar banco na mão.
- Recrie a estrutura, não copie improviso. Peça à IA para gerar o script de criação das tabelas a partir do modelo atual e revise campo por campo. É comum aparecer coisa como valores monetários salvos como texto ou datas sem fuso horário — problemas que só doem meses depois.
- Migre os dados uma única vez, com o app fora do ar por alguns minutos, e confira contagens: número de registros de cada tabela antes e depois.
Aproveite para separar ambientes: um banco de teste, onde você pode quebrar tudo, e um de produção, que ninguém toca sem motivo. Misturar os dois é a origem clássica do "sumiu o cadastro dos clientes".
Passo 5: domínio, HTTPS e e-mail
Com o app rodando, aponte seu domínio. Na prática você entra no painel onde registrou o domínio e cria os registros de DNS que a hospedagem indica — o DNS é a lista que traduz o nome do site para o endereço do servidor. A propagação normalmente leva de alguns minutos a algumas horas.
Três detalhes que costumam ser esquecidos:
- HTTPS (o cadeado). Praticamente todas as plataformas emitem o certificado de graça, mas você precisa ativar e forçar o redirecionamento de http para https.
- E-mails transacionais: recuperação de senha, confirmação de cadastro. Enviar direto do servidor do app faz a mensagem cair em spam. Use um serviço de envio e configure a autenticação do domínio.
- Www ou sem www: escolha um e redirecione o outro. Manter os dois ativos separadamente atrapalha SEO e confunde login.
Passo 6: backup, monitoramento e o dia em que der errado
Backup automático do fornecedor é bom, mas não é seu. Se sua conta for suspensa, ele vai junto. O mínimo aceitável:
- Cópia do banco em rotina diária, guardada em um lugar diferente do servidor.
- Teste de restauração pelo menos uma vez. Backup nunca testado é fé, não é backup.
- Código no GitHub, com o histórico preservado.
Além disso, ligue um monitor de disponibilidade — um serviço que acessa seu app de tempos em tempos e avisa quando ele cai. Sem isso, quem descobre a queda é o cliente.
E antes de abrir para o público, faça uma revisão de segurança do que a IA gerou. Os problemas recorrentes em código de vibe coding são bem específicos: chaves de API deixadas dentro do código do frontend, telas de administração sem verificação real de permissão, e consultas ao banco montadas com texto do usuário. Nenhum desses aparece no preview, porque no preview só você usa o sistema.
Um checklist para o dia do deploy
- Código exportado e no GitHub
- Variáveis sensíveis fora do código, cadastradas na hospedagem
- Banco de produção criado e separado do de teste
- Dados migrados e conferidos por contagem
- Domínio apontado, HTTPS ativo, redirecionamento definido
- Envio de e-mail testado com uma conta real
- Backup diário configurado e uma restauração testada
- Monitor de disponibilidade ativo
- Revisão de permissões e chaves expostas
Se um item ficar em aberto, ele não some: só vira problema mais caro depois. Deploy não é o fim do projeto — é o começo da manutenção.
Travou entre o preview e o app no ar? A WEEBs faz essa ponte: exportar o projeto, subir em hospedagem própria, migrar para um banco de verdade e deixar backup rodando. Se você já tem o app pronto e só falta publicar com segurança, dá para nos chamar no WhatsApp e explicar seu caso.