Alojar uma aplicação criada com IA: do Lovable ou do Bolt ao seu servidor

Onde corre hoje a sua aplicação

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

O v0 publica num projeto Vercel e gera uma aplicação Next.js (React, TypeScript, Tailwind CSS); o código exporta-se, ou sincroniza-se com o GitHub nos dois sentidos. O Cursor é um editor e um agente de programação instalado no seu computador: o código já lá está, e o alojamento fica inteiramente à sua escolha.

Estes alojamentos integrados foram pensados para publicar depressa. Tanto no Lovable como no Replit, a versão online é um instantâneo, renovado a cada publicação, e o custo acompanha a utilização 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 ao fim de 30 dias e volta a publicar-se). Passa-se para um servidor próprio para ter um domínio e dados sob o seu controlo, recursos reservados, tarefas permanentes em segundo plano ou requisitos de conformidade.

Recuperar o código e os dados

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

1. Lovable: ligue o projeto ao GitHub, GitLab ou Bitbucket, ou descarregue o arquivo .zip do código (subscrição paga).
2. Bolt: ligue o GitHub, ou clique no título do projeto, em cima à esquerda, e depois em «Download».
3. Replit: menu de três pontos no topo da árvore de ficheiros e, depois, «Download as zip»; ou a ferramenta Git, ligada à sua conta GitHub, com a sincronização automática.
4. v0: ligue o GitHub a partir do menu do projeto («Settings» e depois «GitHub»), ou exporte o código.

O código não contém o conteúdo da base de dados nem os ficheiros enviados pelos seus utilizadores. No Lovable, a base de dados exporta-se a partir do projeto num ficheiro .backup, a restaurar com pg_restore, e os ficheiros do armazenamento descarregam-se à parte. No Bolt, a base de dados pode ser associada à sua própria conta Supabase (planos Pro e Teams).

De que é feita a sua aplicação

Abra o ficheiro package.json: diz em que assenta a aplicação e, portanto, o que o seu servidor tem de correr.

Com o Vite, qualquer variável cujo nome comece por VITE_ é integrada no código enviado ao navegador, no momento da compilação: qualquer visitante a pode ler, e mudar o seu valor exige uma nova compilação. É o previsto para a chave pública do Supabase (sb_publishable_…, ou a antiga anon), feita para o navegador e enquadrada pelas regras de segurança ao nível das linhas (RLS). A chave secreta (sb_secret_…, ou a antiga service_role) ignora essas regras: 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 colocar a aplicação online: são as suas regras que protegem os seus dados enquanto a chave pública circula no navegador.

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

Num VPS com Linux, a colocação online segue sempre a mesma ordem. O Lovable recomenda o Node.js 22 para construir e correr as suas aplicações.

1. A compilação: clone o repositório no servidor e execute npm install e npm run build. Uma aplicação Vite gera ficheiros estáticos em dist/; uma aplicação TanStack Start constrói-se com NITRO_PRESET=node-server npm run build e arranca com node .output/server/index.mjs, na porta 3000; uma aplicação Next.js arranca com npm run start.
2. O processo: para uma aplicação com servidor, um serviço systemd arranca-a com a máquina e relança-a se parar.
3. O servidor web: o Nginx ou o Caddy recebe os visitantes. Para uma aplicação Vite, devolve index.html em qualquer endereço desconhecido; caso contrário, uma página atualizada responde 404. Para uma aplicação com servidor, transmite os pedidos ao processo Node.js.
4. O nome de domínio: um registo DNS A (e AAAA para o IPv6) aponta para o servidor.
5. O HTTPS: um certificado Let's Encrypt, gratuito. O Caddy obtém-no e renova-o sozinho; com o Nginx, é o Certbot que trata disso.
6. Os segredos: num ficheiro de ambiente legível apenas pelo utilizador da aplicação, fora do repositório Git.
7. A base de dados: mantenha o back-end no respetivo fornecedor, ou instale-o no seu servidor. Uma aplicação Supabase precisa, além da sua base PostgreSQL, da autenticação, do armazenamento, do tempo real e das funções: o Supabase autoalojado reúne-os.
8. Os endereços de redirecionamento: acrescente o seu domínio aos URL autorizados da autenticação, e no Google ou no GitHub se o back-end mudar de endereço.
9. As cópias de segurança: a base de dados e os ficheiros todas as noites, copiados para fora do servidor, e um restauro 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 se aguente

Uma aplicação online está viva: as suas dependências recebem correções, a sua base de dados cresce, o seu tráfego muda. O que a mantém rápida e segura cabe numa rotina:

Esta rotina é o ofício de um administrador de sistemas, e pode ser confiada. Com um VPS gerido, o fornecedor de alojamento mantém o servidor atualizado, supervisiona-o dia e noite e intervém sem esperar pela sua chamada. Acompanha também a sua aplicação de forma proativa (erros, lentidão, consultas pesadas, espaço em disco) e recomenda-lhe a correção: aplica-a com o seu próprio assistente de IA, tal como construiu a aplicação, e mantém o controlo do seu código.