Como usar uma VPS para hospedar seus projetos de vibe coding (do localhost ao domínio)

Aquele app que a IA te ajudou a montar roda liso na sua máquina, e só na sua máquina

Enquanto ele vive no localhost:3000, ninguém além de você consegue abrir. E o clássico "na minha máquina funciona" não paga boleto nem impressiona ninguém

Uma VPS é o passo que tira o projeto do seu PC e coloca no ar, com domínio próprio e cadeado de HTTPS. Aqui eu te mostro o caminho completo pra hospedar projetos de vibe coding em VPS, do deploy até o https:// funcionando. Bora?

O que você precisa antes de começar

Antes de sair rodando comando, junta o kit básico. Sem isso, você trava no meio

• App funcionando localmente: se não sobe no seu PC, não vai subir na VPS mágicamente
• Código em um repositório (Git): a maioria dos painéis puxa o deploy direto do repo
• Uma VPS contratada: a faixa de entrada roda por volta de US$5/mês, o suficiente pra um projeto pequeno
• Um domínio registrado: é ele que vai virar o endereço público do seu app
• Atenção ao banco de dados: esse é o ponto que mais pega vibe coder desprevenido

Hospedagem recomendada

Hospedagem que aguenta seu projeto crescer

Hospedagem rápida, painel simples, backups automáticos e suporte 24/7 em português.

Ver oferta

Se liga nesse último. Muita ferramenta de IA gera o projeto usando SQLite por padrão, porque é simples e não pede configuração

O problema é que SQLite é um arquivo em disco. Ele exige armazenamento persistente, ou seja, um lugar que não some quando o processo reinicia (uma VPS com volume montado resolve isso)

Se você preferir trocar por PostgreSQL, o caminho comum é ajustar a connection string no seu ORM, como o Prisma

Antes de contratar, vale entender como escolher uma VPS com segurança, porque servidor exposto na internet é um bicho diferente do seu localhost

Como funciona o caminho de uma requisição até o seu app na VPS

Antes de mandar comando, entende o mapa. A arquitetura típica de deploy em VPS encadeia estas peças:

Domínio → Cloudflare (CDN + SSL) → Nginx (reverse proxy) → Node.js → SQLite/PostgreSQL → PM2 → systemd

Repara que a coisa tem dois blocos. Do domínio até o banco é o caminho que a requisição percorre de verdade: alguém digita seu endereço e o pedido vai passando de peça em peça até chegar nos dados

Já o PM2 e o systemd ficam de fora desse trânsito. Eles não recebem nem encaminham requisição, são a camada que mantém o app vivo por baixo

Traduzindo cada peça, porque cada uma resolve um problema:

• Domínio: o nome bonito que as pessoas digitam
• Cloudflare: fica na frente como CDN e camada de SSL, distribuindo e protegendo
• Nginx: o reverse proxy, recebe a requisição e roteia pra porta local onde seu app roda
• Node.js: seu app de fato
• SQLite ou PostgreSQL: onde os dados vivem
• PM2: o gerenciador de processo, mantém o app de pé (fora do caminho da requisição)
• systemd: garante que tudo suba de novo se a VPS reiniciar (também fora do caminho da requisição)

"Reverse proxy?" Pensa nele como o porteiro do prédio. A pessoa chega na porta (domínio na porta 80/443), e o porteiro sabe pra qual apartamento (porta local do app) levar. Seu Node pode estar rodando na 3000, mas ninguém precisa saber disso de fora

Esse é o modelo mental. Agora dá pra entender o PORQUÊ de cada passo a seguir, e não só copiar comando no escuro

Passo a passo: do localhost ao domínio no ar

Com o mapa na cabeça, bora pra prática. A sequência é sempre a mesma: domínio, app, banco, HTTPS

1. Apontar o domínio pra VPS. No painel do seu registrador de domínio, você adiciona um registro DNS do tipo A apontando @ para o IP da sua VPS. É isso que faz seudominio.com cair no seu servidor em vez de cair no vazio

O erro comum deste passo: propagação de DNS não é instantânea. Você aponta e às vezes demora pra valer em todo lugar. Não sai reconfigurando achando que errou, às vezes é só esperar

2. Subir o app na VPS. Aqui você tem dois caminhos

O caminho fácil é usar um PaaS self-hosted com painel web, tipo o Dokploy. Você contrata a VPS barata, roda o script de instalação do painel e gerencia o deploy pela interface, em poucos minutos, sem configurar servidor na unha. É o "next, next, finish" do deploy

O caminho manual é configurar o Nginx como reverse proxy você mesmo, roteando por domínio ou path pra porta local onde seu app Node está rodando. Mais trabalho, mais controle

O erro comum deste passo: esquecer que o app precisa estar de pé pra sempre. Se você só roda node app.js no terminal e fecha a conexão SSH, o app morre junto. É pra isso que existe o PM2 e o systemd no fluxo, pra manter o processo vivo e ressuscitar no boot

3. Resolver o banco de dados. Se seu projeto usa PostgreSQL, aponta a connection string pro banco na VPS e segue. Se usa SQLite, garanta que o arquivo está num storage persistente, num volume montado que não é apagado a cada deploy

O erro comum deste passo: subir com SQLite numa configuração onde o disco é efêmero e ver os dados sumirem do nada depois de um restart. Banco que evapora é o pesadelo clássico de quem não olhou o storage

4. Ligar o HTTPS de graça. Ninguém confia num site sem o cadeado. A boa notícia é que dá pra ter certificado sem pagar nada: você emite um certificado Let’s Encrypt usando o Certbot, e o https:// passa a funcionar

O erro comum deste passo: tentar emitir o certificado antes do domínio estar apontando de verdade pra VPS. O Certbot precisa provar que aquele domínio é seu, e ele faz isso batendo no servidor. Se o DNS do passo 1 ainda não propagou, a emissão falha

Coolify ou Dokploy: qual PaaS self-hosted usar

Se você não quer mexer no Nginx e no systemd na mão, um painel PaaS self-hosted resolve. Duas opções open source dominam a conversa hoje: Coolify e Dokploy

Olhando os fatos: o Coolify é o mais rodado, com versão estável fechada e licença Apache 2.0 bem permissiva

O Dokploy é mais novo, nasceu em abril de 2024, e ainda não cravou a versão 1.0. A licença dele é source-available, com restrição de revenda, então lê a licença com atenção se seu uso for comercial pesado

Pra colocar um projeto pessoal no ar, os dois dão conta. A escolha aqui é mais sobre maturidade e licença do que sobre "qual é melhor"

Quando faz sentido usar uma VPS (e quando não)

VPS não é bala de prata. Ela brilha em uns cenários e é overkill em outros

Faz sentido quando:

• Seu app usa SQLite e precisa de disco persistente: a VPS te dá o volume montado que o arquivo do banco precisa pra não sumir
• O projeto passou do localhost e você quer domínio próprio: chegou a hora de ter um seudominio.com de verdade, com HTTPS
• Você quer controle total do custo: uma VPS de entrada por volta de US$5/mês é previsível, você sabe exatamente o que paga

Pensa duas vezes quando o projeto é um protótipo de fim de semana que ninguém além de você vai abrir. Nesse caso, montar domínio, DNS e certificado pode ser esforço demais pro tamanho da brincadeira

Pra quem vai contratar aqui no Brasil, vale saber que a Hostinger tem datacenter em São Paulo e suporte em português, com planos VPS KVM partindo de cerca de R$ 27,99/mês (no KVM 1, plano longo com cupom). Se quiser comparar as opções, dá uma olhada em qual plano VPS da Hostinger escolher

Próximo passo para tirar seu projeto do localhost

Recapitulando a rota, pra fechar a ideia: você aponta o domínio com um registro A, sobe o app por um painel (Coolify ou Dokploy) ou configurando o Nginx na mão, resolve o banco (Postgres ou storage persistente pro SQLite) e liga o HTTPS de graça com o Certbot

É menos assustador do que parece quando você entende o caminho da requisição

O próximo passo concreto é simples: contrata uma VPS de entrada, escolhe entre Coolify e Dokploy pra não brigar com o servidor na unha, e faz o primeiro deploy

Depois que você ver seu projeto de vibe coding respondendo num domínio de verdade, com o cadeado verde, o localhost nunca mais vai parecer suficiente…