Como dividir site, API e automações entre serviços de hospedagem

Fala aí, beleza? Se o teu projeto tem site institucional, API e automações rodando por trás, não precisa colocar tudo no mesmo serviço

Cada parte tem requisitos diferentes: runtime, se precisa ficar ligada o tempo todo, quanto tempo uma requisição demora, se usa WebSocket, em qual domínio vive e onde guarda os dados. Quem decide onde cada uma vai é uma matriz de requisitos, não o hábito de jogar tudo num VPS e pronto 😀

Neste guia tu monta essa matriz e encaixa cada componente na hospedagem web/Cloud com Node.js ou no VPS da Hostinger (link de afiliado da Hostinger), sempre seguindo os limites que estão na documentação oficial

A ideia é usar o serviço gerenciado onde ele dá conta e deixar o VPS só pro que realmente precisa dele

O que você precisa definir antes de dividir o projeto

Antes de abrir qualquer painel, tu precisa de um inventário honesto do sistema

Sem isso a escolha vira chute, e chute em hospedagem costuma aparecer só quando o worker para de rodar no meio da madrugada haha

Responda estas perguntas para cada componente:

• O que é? Site institucional, API, worker, bot, automação agendada e por aí vai
• Qual runtime? Se for Node.js, confira se a versão está entre as suportadas na hospedagem de aplicações da Hostinger: 18.x, 20.x, 22.x e 24.x
• Precisa rodar continuamente? Fila consumindo jobs, bot conectado o dia todo, timer infinito
• A API aceita WebSocket de entrada? Um servidor Socket.IO, por exemplo
• Qual a tarefa mais longa? Quanto tempo leva a requisição mais pesada (gerar relatório, importar planilha e etc)
• Que banco usa? A hospedagem web/Cloud com Node.js oferece MySQL gerenciado
• Qual endereço? Domínio principal e os subdomínios planejados, tipo api.seudominio.com ou bot.seudominio.com

Se alguma resposta for "não sei", descobre antes

É exatamente essa resposta que vai eliminar ou liberar um serviço lá na frente

Passo a passo para montar a matriz de requisitos e escolher o serviço de cada parte

O caminho é: listar, classificar pelos critérios eliminatórios e só então distribuir

Bora ver na prática?

1. Liste os componentes e a responsabilidade de cada um

Escreva uma linha por componente com o que ele faz e quem consome ele

Exemplo: o site institucional mostra páginas para visitantes, a API atende o front e um app, a automação gera relatórios e manda por email

O erro comum deste passo é tratar "o backend" como uma coisa só, quando dentro dele tem uma API que responde rápido e um worker que precisa ficar vivo o tempo todo. São requisitos diferentes, então são linhas diferentes na matriz

2. Classifique cada componente pelos critérios eliminatórios

Aqui tá o coração do guia

Na hospedagem web e Cloud da Hostinger existem limites oficiais que eliminam alguns tipos de carga (limites de Node.js nos planos web e Cloud):

• Uma requisição a um site Node.js é interrompida após 120 segundos
• WebSockets de entrada não são suportados: o app pode abrir conexão WebSocket de saída, mas não aceitar conexões entrantes como um servidor Socket.IO
• Workers sempre ativos não são suportados: fila, bot e timer infinito param quando o app é implantado ou reiniciado. A orientação oficial é usar cron jobs
• Cada site Node.js roda como um processo, e todos os sites do plano compartilham o mesmo limite de processos (NPROC) e a mesma memória

E a quantidade de apps Node.js muda por plano:

Plano	Sites Node.js	NPROC
Business	5	120
Cloud Startup	10	200
Cloud Professional	10	400
Cloud Enterprise	10	600
Cloud Enterprise Plus	10	800

Com isso em mãos, monta a matriz. Um modelo simples:

Componente	Runtime	Roda sempre?	Requisição acima de 120 s?	WebSocket de entrada?	Endereço	Dados
Site institucional	Node.js (Next.js)	Não	Não	Não	seudominio.com	Nenhum ou MySQL
API REST	Node.js (Express.js)	Não	Não	Não	api.seudominio.com	MySQL
Relatório diário	Node.js	Não, agendado	Sim, se rodasse na requisição	Não	Sem endereço público	MySQL
Bot ou consumidor de fila	Node.js	Sim	Não se aplica	Depende	bot.seudominio.com	A definir

Qualquer "Sim" nas colunas "Roda sempre?" ou "WebSocket de entrada?" tira o componente da hospedagem web/Cloud

O erro comum deste passo é esquecer que o NPROC e a memória são do plano inteiro, não de cada site. Se tu coloca vários apps Node.js no mesmo plano, todos disputam o mesmo limite

3. Publique o site institucional e a API simples na hospedagem web/Cloud

Componente sem processo infinito, sem WebSocket de entrada e com requisições abaixo de 120 s é candidato natural para os planos Business ou Cloud, que são os planos onde a Hostinger roda aplicações web em Node.js

Tu pode publicar o app por repositório GitHub, upload de .zip, template pronto ou conectando a IDE pelo Hostinger Connector, e tem build automático para frameworks como React, Vue.js, Angular, Next.js e Express.js (como publicar um site Node.js)

A versão do Node.js é escolhida pelo painel, então confere se ela bate com a que tu usa no desenvolvimento

O erro comum aqui é rodar localmente numa versão e publicar em outra sem perceber. Fixe a versão na matriz e use a mesma no painel

4. Transforme automações agendadas em cron job

Relatório diário, limpeza de dados, sincronização de hora em hora: nada disso precisa ficar ligado o tempo todo

A própria documentação manda tirar tarefas longas (acima do timeout) da requisição e levar para um cron job do site Node.js

Para criar: no painel, vai em Websites > Dashboard > Cron Jobs na barra lateral, escolhe o tipo PHP (para arquivo .php) ou Custom (para outros comandos e extensões), define o comando e o agendamento e salva (como criar cron job na Hostinger)

A saída da execução aparece na lista de cron jobs, que é onde tu confere se rodou

Tome cuidado! O agendamento usa UTC+0

O erro mais comum é configurar o horário no fuso local. Se tu quer que o relatório saia às 9h de Brasília (UTC-3), o agendamento precisa ser 12h em UTC

5. Leve para o VPS o que precisa ficar sempre ativo ou aceitar WebSocket de entrada

Se a matriz marcou "Roda sempre?" ou "WebSocket de entrada?" como Sim, esse componente não cabe na hospedagem web/Cloud, e não adianta procurar um plano "sempre ativo" lá dentro

Aí entra o VPS

O VPS te dá um ambiente isolado com sistema operacional, RAM e CPU próprios, diferente da hospedagem compartilhada. Porém todos os planos VPS da Hostinger são autogerenciados, com acesso root: instalar software, configurar o servidor e cuidar da segurança passa a ser responsabilidade tua (o que é VPS autogerenciado)

É como sair do apartamento com síndico e ir para uma casa: mais liberdade, mas o telhado agora é problema seu xD

Os planos usam virtualização KVM e se chamam KVM 1, KVM 2, KVM 4 e KVM 8

Para não montar tudo na mão, tem o Docker Manager na seção do VPS no hPanel, que deixa implantar e gerenciar contêineres sem linha de comando, com o Docker pré-instalado na compra ou instalado depois (Docker Manager). Também existe um template de VPS com Ubuntu, Docker e Docker Compose pré-instalados

O erro comum deste passo é mandar o projeto inteiro para o VPS só porque um componente precisava dele. O site e a API que cabiam no web/Cloud continuam podendo ficar lá, e tu só administra o servidor do que realmente exige

6. Configure os domínios e subdomínios

Com cada parte no seu lugar, cada uma ganha um endereço

Para subdomínio na hospedagem web/Cloud: Websites > Dashboard do site do domínio principal > Domains > Subdomains, informa o nome, mantém o diretório padrão (recomendado) e cria (como criar subdomínios no hPanel)

Para apontar um subdomínio para o VPS, com o domínio registrado na Hostinger: Domains > Domain Portfolio > Manage > DNS/Nameservers > DNS records, e ajusta o registro A (e CNAME, se usar) para o IP do VPS (como apontar domínio para VPS)

O erro comum aqui é planejar endereço como loja.shop.seudominio.com. Subdomínio de segundo nível não é suportado nas hospedagens web e Cloud, então mantém um nível só, tipo loja.seudominio.com

Exemplos de divisão por tipo de projeto

Três cenários que saem direto da matriz, cada um com a decisão e o limite que pesou

Em todos eles, pensa o custo por serviço: cada parte que vai para um serviço diferente é uma linha separada no orçamento, e tu consegue ver quanto cada componente custa de verdade

Site, API REST e relatórios agendados: tudo no web/Cloud

Site em Next.js, API em Express.js e um relatório que roda uma vez por dia

Nenhum componente roda sempre, ninguém aceita WebSocket de entrada, e o relatório pesado sai da requisição e vira cron job

Tudo cabe num plano Business ou Cloud com MySQL gerenciado. O limite a vigiar é a soma: os apps dividem processos e memória do plano, e o Business comporta 5 sites Node.js

Site no web/Cloud e bot ou fila no VPS

O site e a API ficam no web/Cloud, e um bot ou consumidor de fila que precisa ficar conectado o tempo todo vai para o VPS, em bot.seudominio.com apontado por registro A

O motivo é direto: worker persistente para quando o app é reiniciado no web/Cloud

Se liga num detalhe: pra não depender de acesso remoto ao MySQL da hospedagem web a partir do VPS, desenha o worker para conversar com a tua API por HTTP, ou mantém os dados dele no próprio VPS

Esse mesmo raciocínio vale para fluxos tipo uma integração do n8n com ERP: primeiro tu classifica se a automação roda agendada ou precisa ficar sempre ativa, e só depois decide onde ela mora

API com Socket.IO no VPS e site institucional na hospedagem web

Um app de chat ou painel em tempo real precisa de um servidor Socket.IO aceitando conexões, ou seja, WebSocket de entrada

Isso elimina o web/Cloud para a API, que vai para o VPS (com Docker Manager facilita bastante). O site institucional, que é só conteúdo, continua na hospedagem web, sem tu precisar administrar servidor para ele

Nesse cenário a combinação de hospedagem gerenciada e VPS na Hostinger resolve as duas pontas, com domínio e DNS no mesmo painel, mas lembra: a parte do VPS é autogerenciada

E se o teu projeto é justamente site institucional para cliente, no canal tem um vídeo sobre ganhar dinheiro com criação de sites e se WordPress vale a pena para freelance, que complementa bem a parte "site" da matriz 🙂

Como validar a divisão e manter o projeto organizado

Com tudo publicado, volta na matriz e faz um checklist rápido:

• Nenhum componente no web/Cloud depende de requisição acima de 120 s, WebSocket de entrada ou processo infinito?
• O cron job aparece na lista com saída de execução, no horário certo convertido para UTC+0?
• O subdomínio apontado para o VPS abre o serviço certo?

Se os três passaram, a divisão está de pé

A matriz não é documento de uma vez só. Toda vez que surgir uma automação nova, ela ganha uma linha e passa pelos mesmos critérios antes de ir para qualquer servidor

E se quiser se aprofundar em cada modalidade separadamente, aqui no blog tem os guias de VPS versus hospedagem compartilhada e de planos VPS da Hostinger, que entram no detalhe de cada uma

Até o próximo post! 😀

Perguntas frequentes

Preciso trocar do plano Business para um plano Cloud se passar de 5 apps Node.js?

Sim, o Business suporta até 5 sites Node.js enquanto os planos Cloud Startup, Professional, Enterprise e Enterprise Plus suportam até 10. Se o projeto crescer além desse limite, o próximo passo é migrar para um plano Cloud

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.