Hospedagem de sites vs hospedagem de aplicações (Node, Python, bots)

A palavra "hospedagem" cobre dois serviços bem diferentes. Um guarda arquivos e os entrega a quem pedir. O outro executa o seu programa e o mantém vivo. Contratar o errado está por trás de muita mensagem do tipo "meu bot não sobe" ou "o painel não aceita Node".

Não existe vencedor universal entre os dois. A escolha depende do que o seu projeto faz quando ninguém está acessando.

O que é hospedagem de site?#

É um serviço que armazena os arquivos do site e os entrega pelo protocolo HTTP. A MDN descreve isso como um servidor web estático: ele envia os arquivos hospedados exatamente como estão para o navegador.

Esse modelo costuma vir com extras: painel de controle, e-mail do domínio, certificado TLS e, em muitos planos, PHP com um banco MySQL já instalados. Você envia arquivos por FTP ou pelo explorador de arquivos do painel, e o provedor cuida de como o servidor roda. Em geral você não escolhe a versão do runtime nem instala pacotes por conta própria.

Serve bem para site institucional, portfólio, blog em WordPress e landing page. Veja também o que é um site estático e onde hospedar.

O que é hospedagem de aplicações?#

É um serviço que executa o seu código em um processo que fica ligado. Você escolhe a linguagem (Node.js, Python, Java, Go e outras), envia o projeto, e a plataforma inicia o comando de start e o mantém rodando.

A MDN chama de servidor dinâmico aquele que tem, além do servidor HTTP, um servidor de aplicação e normalmente um banco de dados: o código gera ou altera a resposta antes de enviá-la. Numa hospedagem de aplicações essa camada é sua. Um exemplo mínimo em Node.js com Express 5:

// server.mjs (ou "type": "module" no package.json para usar .js)
import express from "express";

const app = express();

app.get("/", (req, res) => {
  res.send("Olá! Esta resposta foi montada por código, não por um arquivo.");
});

// A porta vem do ambiente; 3000 é só o valor local de desenvolvimento.
const port = process.env.PORT ?? 3000;
app.listen(port, () => console.log(`Rodando na porta ${port}`));

O ponto é o app.listen: o programa nunca termina. Enquanto ele estiver de pé, o site responde. Se cair, o site cai. Por isso a hospedagem de aplicações oferece reinício automático, logs e controle de memória.

Qual a diferença na prática?#

A segunda linha decide quase tudo: se algo precisa estar rodando mesmo sem visita, é aplicação.

Que projetos exigem hospedagem de aplicações?#

• Bots. Um bot do Discord mantém uma conexão WebSocket aberta com o Gateway. Sem processo contínuo, ele fica offline. O mesmo vale para bots de Telegram com long polling e de WhatsApp.
• APIs. Um backend em Express, FastAPI ou Spring recebe requisições, consulta o banco e responde. Precisa de runtime e porta, não de um diretório de arquivos. Veja como hospedar uma aplicação Node.js.
• Sites com renderização no servidor. A documentação do Next.js lista quatro formas de publicar: servidor Node.js, contêiner Docker, exportação estática e adaptadores. O servidor Node.js e o Docker suportam todos os recursos; a exportação estática é limitada e não oferece o que depende de servidor.
• Workers e tarefas agendadas. Filas, scrapers e rotinas que rodam a cada hora precisam de um processo seu.
• Conexões em tempo real. Chat, notificações e jogos usam WebSocket, que exige processo persistente.

Que projetos funcionam bem em hospedagem de site?#

• Site institucional, portfólio e página de produto em HTML e CSS.
• Blog ou loja em WordPress (PHP e MySQL, com instalação em um clique).
• Front-end gerado como estático: React com Vite, Astro, Next.js com output: "export" e similares, desde que não dependam de código no servidor.

A regra de bolso: se o resultado do build é uma pasta de arquivos que funciona abrindo no navegador, hospedagem de arquivos resolve. Se o projeto precisa de um comando como node server.mjs ou python main.py para existir, precisa de aplicação.

Como saber qual escolher?#

Responda em ordem:

1. O projeto tem um comando de start? Sim: aplicação. Não: siga.
2. Precisa guardar dados que mudam (usuários, pedidos, sessões)? Sim, e em linguagem que não seja PHP: aplicação, com um banco. Sim, e em WordPress: a hospedagem de site já traz tudo.
3. Quer escolher a versão da linguagem e as dependências? Sim: aplicação.
4. Só precisa mostrar páginas e quer o menor custo e a menor manutenção? Hospedagem de arquivos.

Fora dessas duas existem a VPS e a nuvem genérica, em que você administra o servidor inteiro. Elas dão mais liberdade e mais trabalho; a comparação está em VPS ou hospedagem compartilhada.

O que muda na hora de migrar de uma para outra?#

De site para aplicação, você passa a informar o que antes era invisível: o comando de start, a porta em que o programa escuta e as variáveis de ambiente (chaves, URL do banco). Guarde segredos em variáveis, nunca no código.

De aplicação para site estático, você abre mão do código no servidor: formulários, login e APIs precisam virar serviços externos ou ficar em outra aplicação. Muita gente separa as duas partes, com o front-end estático de um lado e a API do outro, ligados por chamadas HTTP.

Como fazer isso na Square Cloud#

Se as perguntas acima apontaram para aplicação, a Square Cloud é hospedagem self-service desse tipo: você envia o projeto, define o arquivo principal e a memória, e ele roda em um container isolado. O container fica sempre ligado, sem modo de suspensão, com reinício automático (ligado por padrão no deploy pelo painel) se o processo encerrar com erro. Isso serve tanto para um servidor Node.js ou Python quanto para um bot.

Para sites, o caminho depende do tipo. Entre diversos runtimes, há um para sites estáticos (HTML, CSS e JavaScript prontos), em que o nginx fica sempre no ar servindo os seus arquivos e cada atualização entra no ar na hora. Para servidores, há runtimes como Node.js, TypeScript, Python e PHP. Veja os runtimes disponíveis hoje em Runtimes. Toda aplicação web ganha um subdomínio *.squareweb.app com HTTPS. A partir do Standard, você aponta um domínio seu criando no seu registrador os registros DNS mostrados no painel, e o domínio continua registrado em seu nome.

O arquivo de configuração squarecloud.app é opcional: o painel o gera no deploy (runtime, memória e arquivo principal), e escrever à mão na raiz do projeto é a alternativa. A RAM do plano é um pool compartilhado entre suas aplicações, com mínimo de 512 MB por aplicação web, e todos os planos incluem analytics web sem cookies.

Os detalhes de hospedagem de sites estão na página de Sites.