Hospedar uma aplicação criada com IA: do Lovable ou Bolt para seu servidor

Onde sua aplicação roda hoje

Lovable, Bolt e Replit publicam a aplicação na própria infraestrutura, com um clique. Veja o que diz a documentação de cada um, consultada em outubro de 2026:

O v0 publica em um projeto Vercel e gera uma aplicação Next.js (React, TypeScript, Tailwind CSS); o código pode ser exportado ou sincronizado com o GitHub nos dois sentidos. O Cursor é um editor e um agente de programação instalado em seu computador: o código já está lá, e a escolha da hospedagem é inteiramente sua.

Essas hospedagens integradas foram pensadas para publicar rápido. No Lovable, como no Replit, a versão no ar é um snapshot, renovado a cada publicação, e o custo acompanha o uso da plataforma (no Lovable, créditos cobrem a atividade do back-end e a IA; no Replit, o plano Starter inclui uma aplicação publicada, que expira depois de 30 dias e precisa ser republicada). A mudança para um servidor próprio vem com a busca por um domínio e dados sob seu controle, recursos reservados, tarefas em segundo plano permanentes ou exigências de conformidade.

Recuperar o código e os dados

O mais seguro é conectar o projeto a um repositório no GitHub: cada modificação chega lá como commit, com todo o histórico. No Lovable, a sincronização funciona nos dois sentidos: você continua construindo no Lovable enquanto seu servidor serve a aplicação.

1. Lovable: conecte o projeto ao GitHub, GitLab ou Bitbucket, ou baixe o arquivo .zip do código (assinatura paga).
2. Bolt: conecte o GitHub, ou clique no título do projeto, no alto à esquerda, e depois em “Download”.
3. Replit: menu de três pontos no alto da árvore de arquivos, depois “Download as zip”; ou a ferramenta Git, conectada a sua conta do GitHub, com a sincronização automática.
4. v0: conecte o GitHub pelo menu do projeto (“Settings”, depois “GitHub”), ou exporte o código.

O código não contém o conteúdo do banco de dados nem os arquivos enviados por seus usuários. No Lovable, o banco é exportado a partir do projeto em um arquivo .backup, a ser restaurado com pg_restore, e os arquivos do armazenamento são baixados à parte. No Bolt, o banco de dados pode ser vinculado a sua própria conta do Supabase (planos Pro e Teams).

Do que sua aplicação é feita

Abra o arquivo package.json: ele diz em que a aplicação se baseia e, portanto, o que seu servidor precisa rodar.

Com o Vite, toda variável cujo nome começa com VITE_ é incorporada ao código enviado ao navegador, no momento do build: qualquer visitante pode lê-la, e mudar o valor dela exige um novo build. Isso é intencional para a chave pública do Supabase (sb_publishable_…, ou a antiga anon), feita para o navegador e protegida pelas regras de segurança em nível de linha (RLS). A chave secreta (sb_secret_…, ou a antiga service_role) ignora essas regras: ela fica no servidor, sem o prefixo VITE_.

VITE_SUPABASE_URL=https://xxxx.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_xxxx
VITE_SUPABASE_PROJECT_ID=xxxx

Ative o RLS em cada tabela antes de publicar: são as regras dele que protegem seus dados enquanto a chave pública circula no navegador.

Colocá-la em seu próprio servidor, passo a passo

Em um VPS com Linux, a publicação segue sempre a mesma ordem. O Lovable recomenda o Node.js 22 para fazer o build e rodar as aplicações criadas nele.

1. O build: clone o repositório no servidor e execute npm install e npm run build. Uma aplicação Vite gera arquivos estáticos em dist/; uma aplicação TanStack Start é construída com NITRO_PRESET=node-server npm run build e inicia com node .output/server/index.mjs, na porta 3000; uma aplicação Next.js inicia com npm run start.
2. O processo: para uma aplicação com servidor, um serviço systemd a inicia junto com a máquina e a reinicia se ela parar.
3. O servidor web: Nginx ou Caddy recebe os visitantes. Para uma aplicação Vite, ele devolve index.html em qualquer endereço desconhecido, senão uma página atualizada responde 404; para uma aplicação com servidor, ele repassa as requisições ao processo Node.js.
4. O nome de domínio: um registro DNS A (e AAAA para o IPv6) aponta para o servidor.
5. O HTTPS: um certificado Let's Encrypt, gratuito. O Caddy o obtém e o renova sozinho; com o Nginx, o Certbot cuida disso.
6. Os segredos: em um arquivo de ambiente que só o usuário da aplicação pode ler, fora do repositório Git.
7. O banco de dados: mantenha o back-end no fornecedor dele ou instale-o em seu servidor. Uma aplicação Supabase precisa, além do banco PostgreSQL, da autenticação, do armazenamento, do tempo real e das funções: o Supabase self-hosted reúne tudo isso.
8. Os endereços de redirecionamento: adicione seu domínio às URLs autorizadas da autenticação, e no Google ou no GitHub se o back-end mudar de endereço.
9. Os backups: o banco de dados e os arquivos todas as noites, copiados para fora do servidor, e uma restauração de teste de vez em quando.

app.votre-domaine.com {
	reverse_proxy 127.0.0.1:3000
}

server {
    server_name app.votre-domaine.com;
    root /var/www/app/dist;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

O que é preciso para que ela se sustente

Uma aplicação no ar está viva: as dependências recebem correções, o banco de dados cresce, o tráfego muda. O que a mantém rápida e segura cabe em uma rotina:

Essa rotina é o ofício de um administrador de sistemas, e ela pode ser delegada. Com um VPS gerenciado, o provedor mantém o servidor atualizado, monitora-o dia e noite e intervém sem esperar sua ligação. Ele também acompanha sua aplicação de forma proativa (erros, lentidões, consultas custosas, espaço em disco) e recomenda a correção: você a aplica com seu próprio assistente de IA, do mesmo jeito que construiu a aplicação, e mantém o controle de seu código.