Hosting Node.js i Next.js. Wypychasz kod, strona działa.

1. O Node.js precisa de algo entre PaaS e um servidor bare metal

Nas aplicações Node.js, a primeira escolha natural é muitas vezes o modelo habitual das plataformas PaaS (Platform as a Service): fazes git push e a aplicação funciona, sem gerir um servidor. O problema surge na fatura: a maioria destas plataformas cobra em dólares, com preços que sobem rapidamente com o tráfego real em produção, enquanto a infraestrutura está fisicamente fora da Polónia.

Na Saplo, disponibilizamos a aplicação Node.js como um starter (Express) pronto a utilizar, com a versão do Node à tua escolha (18, 20 ou 22, 20 por predefinição). Podes substituir o código pelo teu próprio através de git deploy: o push para o repositório atualiza automaticamente a aplicação em execução, sem teres de iniciar sessão manualmente no servidor após cada alteração.

O manifesto da aplicação indica um mínimo de 512 MB de RAM e 3 GB de espaço em disco, o que significa que até o Box S (1 GB de RAM) consegue tecnicamente alojar uma aplicação Node simples. Para mais do que um protótipo, porém, vale a pena considerar o Box M com acesso SSH completo.

2. Git deploy em vez de upload manual

Git deploy significa que o repositório de código é a única fonte de verdade sobre o que está a ser executado em produção: o push para o ramo definido desencadeia a atualização da aplicação no Box, sem teres de enviar manualmente ficheiros por FTP ou copiá-los por SSH após cada alteração no código.

Para uma equipa com várias pessoas a trabalhar na mesma aplicação Node.js, a diferença é real: cada commit que entra no ramo correto vai diretamente para o servidor, o que facilita iterações rápidas sem passos adicionais de implantação para além do próprio git push.

A partir do Box M, o acesso SSH com sudo permite ainda gerir manualmente o processo Node, por exemplo reiniciá-lo depois de alterar variáveis de ambiente ou instalar pacotes de sistema adicionais exigidos por algumas dependências npm, algo que nem sempre é possível fazer apenas com git deploy.

3. Porque não um VPS clássico?

Num VPS sem nada instalado da Concorrente A (1 vCPU, 2 GB RAM, 20 GB de disco por 50 zł/mês sem IVA, listas de preços públicas à data de 2026-10-10), colocar uma aplicação Node.js em funcionamento exige instalar manualmente o Node, um gestor de processos, como o PM2, um reverse proxy e um certificado SSL antes de a aplicação estar publicamente acessível num domínio com https.

Na Saplo, estes elementos (reverse proxy nginx, SSL e gestor de processos no contentor) são configurados automaticamente durante a instalação a partir do catálogo. Assim, desde a escolha da versão do Node até ter a aplicação operacional e publicamente disponível no teu próprio domínio, passam apenas minutos, em vez de horas dedicate à configuração manual do servidor.

O custo é comparável ao de um VPS com recursos semelhantes, mas sem a necessidade de administrares o sistema operativo e sem o risco de uma falha na configuração do firewall ou numa atualização do sistema deixar a aplicação indisponível por causa de algo sem relação com o código Node.js.

4. Várias aplicações Node.js no mesmo Box

Sem limite para o número de aplicações no Box, podes executar vários projetos Node.js independentes (por exemplo, uma API, um painel de administração ou um microsserviço separado) ao mesmo tempo, cada um no seu próprio contentor LXC e com o seu domínio ou subd respetivo, sem conflitos de portas entre projetos.

Para aplicações que utilizem uma base de dados, estão disponíveis módulos de base de dados separados (Postgres, MySQL, Redis), implementados como contentores no teu próprio Compose e não como extras pagos. Para uma stack típica Node.js + base de dados, esta é uma combinação natural, sem custos adicionais pela própria base de dados. Adicionar uma base de dados como outra aplicação no mesmo Box demora tanto como instalá-la a partir do catálogo, sem precisar de um contrato separado com um fornecedor externo de bases de dados alojadas na cloud.

5. Para quem é indicado

Se estás a desenvolver um backend API simples ou um microsserviço, o Box M, com acesso SSH completo e deployment por Git, dá-te um ambiente de produção rápido sem teres de configurar um servidor desde zero.

Para uma startup a desenvolver vários serviços Node.js ao mesmo tempo (API, painel, worker), o Box L permite alojá-los todos numa única conta, em contentores separados, sem uma conta separada para cada microsserviço em diferentes fornecedores de PaaS.

Para quem migra de uma plataforma PaaS estrangeira cobrada em dólares, a Saplo oferece uma experiência de deployment semelhante (git push), mas com cobrança em zlotys e infraestrutura num centro de dados europeu.

6. Primeiro deployment de uma aplicação Node.js na Saplo

Depois de instalares o starter Express com a versão de Node escolhida (18, 20 ou 22), liga o repositório Git ao painel, para que as alterações seguintes no código sejam enviadas automaticamente para o servidor a cada push para o ramo definido.

Substitui o código do starter pela tua aplicação, mantendo a estrutura da porta e das variáveis de ambiente exigidas pelo motor da Saplo, para que o reverse proxy continue a encaminhar corretamente o tráfego para a tua aplicação no domínio associado.

Defines as variáveis de ambiente, como chaves de API e cadeias de ligação à base de dados, no painel da aplicação, sem guardar os valores diretamente no repositório de código. Esta é uma boa prática de segurança, independentemente de onde a aplicação está alojada.

Se a aplicação utilizar uma base de dados, adiciona um módulo separado (Postgres, MySQL ou Redis) no mesmo Box e liga-te a ele através do endereço interno, sem expor a base de dados publicamente na Internet.

Monitoriza os logs da aplicação por SSH (disponível a partir do Box M), para detetares rapidamente erros após cada deployment, antes que se tornem visíveis aos utilizadores da aplicação em produção.

7. Node.js numa arquitetura de microsserviços no mesmo Box

Podes implementar vários serviços Node.js independentes (API, worker que processa uma fila, painel de administração) como aplicações separadas no mesmo Box, cada um no seu próprio contentor e a comunicar pela rede interna ou por APIs públicas.

Esta divisão facilita o deployment independente de cada serviço (um git push para um serviço não exige um novo deployment dos outros), o que, à medida que o projeto cresce, é mais conveniente do que um único processo Node.js grande e monolítico que trate de tudo ao mesmo tempo.

O Redis, como módulo de base de dados separado no mesmo Box, serve frequentemente como fila de tarefas ou cache entre microsserviços, sem necessidade de utilizar um serviço Redis externo e pago fora da infraestrutura da Saplo.

Numa arquitetura de microsserviços, vale a pena considerar o Box L ou superior, porque vários processos Node.js independentes, uma base de dados e o Redis juntos consomem mais memória do que uma aplicação simples.

8. Monitorização e logs de uma aplicação Node.js em produção

Uma aplicação Node.js em produção acaba inevitavelmente por encontrar um erro que não apareceu nos testes locais. Por isso, o acesso aos logs do processo por SSH (disponível a partir do Box M) é uma ferramenta de diagnóstico fundamental, que permite ver o que aconteceu de facto no momento da falha ou do comportamento inesperado.

Uma boa prática consiste em usar logs estruturados (por exemplo, em JSON, com nível de gravidade e timestamp) em vez de simples console.log espalhados pelo código. Isso facilita a filtragem posterior dos logs por tipo de evento ou nível de erro, especialmente quando a aplicação cresce e o volume de logs aumenta.

O reinício do processo após uma falha (por exemplo, uma exceção não tratada que pare o Node.js) pode ser configurado através do gestor de processos a correr no contentor. Assim, uma falha de curta duração não implica uma longa indisponibilidade da aplicação antes de alguém da equipa detetar o problema e reagir manualmente.

Para aplicações com muitas dependências npm, vale a pena verificar periodicamente as vulnerabilidades conhecidas nos pacotes utilizados (com as ferramentas de auditoria padrão do npm), porque dependências desatualizadas são um vetor de ataque comum às aplicações Node.js, por muito bem escrito que esteja o código da aplicação.

Monitorizar o consumo de RAM do processo Node.js ao longo do tempo ajuda a detetar fugas de memória (memory leaks) antes que provoke a falha de toda a aplicação. Em processos de longa duração (servidores WebSocket, ligações prolongadas), isto constitui um risco real sem monitorização adequada. A verificação simples e regular da tendência de consumo de memória, mesmo sem ferramentas avançadas de profiling, permite detetar um problema crescente a tempo de planear a correção antes de provocar uma falha em produção.

O painel da Saplo mostra o consumo atual de recursos do contentor e é o primeiro ponto de referência no diagnóstico de problemas de desempenho, antes de recorreres a ferramentas de profiling mais detalhadas da própria aplicação Node.js.

9. A comunidade e o ecossistema npm como parte da escolha da stack

O Node.js tem um dos maiores ecossistemas de pacotes (npm) entre as linguagens e plataformas mais populares. Assim, a maioria das necessidades mais comuns (autenticação, ligação a bases de dados, gestão de ficheiros) já tem bibliotecas prontas e testadas, em vez de escrever essa lógica do zero para cada novo projeto.

Na Saplo, este ecossistema está totalmente disponível, porque a aplicação funciona num ambiente Node.js padrão, com acesso ao registo npm, sem as limitações impostas pela plataforma de alojamento que existem em algumas plataformas PaaS fechadas com uma lista restrita de pacotes suportados.

A escolha entre frameworks populares e o próprio Node.js (Express, Fastify, NestJS) depende inteiramente do programador, já que o starter fornecido pela Saplo (Express) é um ponto de partida que pode ser substituído, não uma restrição rígida, caso o projeto precise de outro framework.

As atualizações do ambiente Node.js, como a migração para uma versão LTS mais recente, estão disponíveis como opção ao reconfigurar a aplicação. Assim, podes manter-te a par do ciclo de lançamento do Node.js sem mudar de fornecedor apenas por causa de uma alteração na versão exigida.

Para equipas que acompanham a evolução do ecossistema JavaScript, incluindo novas ferramentas de build e novos padrões de arquitetura, a flexibilidade do acesso SSH integral e do ambiente Node.js padrão na Saplo não impõe limitações adicionais face ao que é possível num servidor tradicional gerido de forma independente.

10. Testar a aplicação Node.js antes de a colocar em produção

Antes de cada publicação em produção, vale a pena testar a nova versão da aplicação num ambiente próximo do ambiente de produção, por exemplo, numa aplicação temporária separada no mesmo Box, antes de a alteração chegar ao domínio final usado pelos clientes.

Testes automáticos, unitários e de integração, executados antes da publicação, mesmo num simples pipeline de CI ao nível do repositório, ajudam a detetar regressões no código antes de este chegar ao servidor de produção via git deploy. É muito mais barato do que corrigir um erro que os utilizadores já viram.

Para aplicações com tráfego crítico em produção, vale a pena implementar as alterações fora das horas de maior atividade. Assim, reduces o número de utilizadores afetados por um eventual erro breve durante a atualização do código via git deploy.

O rollback para a versão anterior do código, que funcionava, com um regresso ao commit anterior e um novo git push, é um mecanismo de segurança simples quando uma nova publicação dá problemas. Já o backup do Box, a partir do Box L, protege também a base de dados da aplicação em caso de problemas mais graves.

11. Resumo: Node.js com git deploy como caminho rápido para a produção

A combinação do starter Express pronto a usar, da escolha da versão do Node e da publicação automática com git push reduz o tempo entre a ideia e uma aplicação Node.js funcional e publicamente acessível de minutos, em vez das horas necessárias para configurar manualmente o servidor, a firewall e o reverse proxy de um VPS sem serviços de gestão. Tudo isto antes de a primeira linha do código da aplicação sequer começar a funcionar num endereço de produção com um certificado SSL ativo. Para um programador que esteja a testar uma nova ideia, esta diferença no tempo de arranque pode ser decisiva, pois permite concentrar as primeiras horas de trabalho na lógica da aplicação e não na configuração da infraestrutura que a tem de sustentar. O mesmo argumento aplica-se ainda melhor quando se testam várias ideias em paralelo, porque o custo de validar a ideia seguinte reduz-se ao tempo de escrever o código, sem repetir a mesma configuração do servidor em cada tentativa.