Guia de publicação

Última atualização: 6 de julho de 2026

O Hangar Cloud está em versão beta. Estes documentos serão atualizados conforme o serviço evolui — a data acima marca a versão vigente.

1. O essencial

O deploy funciona com qualquer repositório git público (ou um arquivo .tar.gz) que siga três regras:

• Os arquivos do projeto ficam na raiz — o package.json (ou equivalente) não pode estar dentro de uma subpasta.
• Escute na porta que a plataforma indica — leia a variável de ambiente PORT e escute em 0.0.0.0. Portas fixas (3000, 8080…) são a causa nº 1 de app publicado que não abre.
• Tenha um comando de start — o build detecta a linguagem e precisa saber como iniciar o app.
• Escreva a porta no log ao iniciar — uma linha como Listening on 3000. É assim que a plataforma descobre em qual porta o seu app está escutando na hora de configurar o domínio (frameworks como Express já fazem isso; num servidor feito à mão, adicione um console.log).

2. Node.js (validado ✓)

Detecção: um package.json na raiz com um script "start". Exemplo mínimo:

{
  "name": "meu-app",
  "scripts": { "start": "node index.js" }
}

// index.js (exemplo ilustrativo)
const http = require('http');
const port = process.env.PORT || 3000;
http.createServer((req, res) => res.end('no ar!'))
  .listen(port, '0.0.0.0', () => console.log('Listening on ' + port));

O exemplo validado na plataforma é o repositório heroku/node-js-getting-started — publica sem nenhum ajuste; use-o como referência.

3. Sites estáticos (hoje: com um servidor mínimo)

Um repositório só com index.html ainda não é servido diretamente — o plano dedicado para sites estáticos está em breve. Enquanto isso, o caminho que funciona é servir os arquivos com um servidor Node mínimo — dois arquivos a mais no seu projeto:

{
  "name": "meu-site",
  "scripts": { "start": "echo Listening on $PORT && npx serve -l tcp://0.0.0.0:$PORT ." }
}

(package.json acima na raiz, junto do seu index.html e demais arquivos. O echo registra a porta no log — a regra 4 acima. Receita ainda não validada individualmente; se não subir, os logs de build contam o porquê.)

4. Outras linguagens

O build usa a detecção do Nixpacks — em geral, o arquivo de manifesto da linguagem na raiz + um comando de start:

• Python — requirements.txt ou pyproject.toml; defina o start (ex.: um Procfile com web: gunicorn app:app --bind 0.0.0.0:$PORT).
• .NET — um .csproj na raiz; escute em http://0.0.0.0:$PORT.
• Go — go.mod na raiz; leia PORT do ambiente.

Ainda não validamos cada uma individualmente — se algo não subir, os logs de build mostram o que a detecção encontrou, e o suporte responde em contato@hangarcloud.com.br.

5. Enviando um .tar.gz (em breve)

O envio de arquivo aparece no formulário, mas esse caminho ainda está em validação — por enquanto, publique por uma URL git pública (um repositório no GitHub resolve, mesmo que temporário). Quando ativo, o .tar.gz seguirá a mesma estrutura: arquivos do projeto na raiz do archive.

6. Depois do deploy

• URL automática — assim que o app entra no ar, ele ganha <app>.<sua-conta>.hangarcloud.com.br com HTTPS. Domínio próprio? Adicione na página do app.
• Logs — build e runtime na página do app (é onde se descobre por que um deploy falhou).
• Bancos de dados — Postgres, MySQL ou Redis em "Bancos de dados"; a connection string aparece uma única vez, na criação.

7. Publicar com IA (MCP)

Seu agente pode publicar e depurar sozinho. Gere um token em Acesso no painel e conecte (exemplo com Claude Code):

claude mcp add --transport http hangar https://api.hangarcloud.com.br/api/mcp \
  --header "Authorization: Bearer SEU_TOKEN_AQUI"

Depois é pedir: "publica esse app no Hangar e acompanha os logs até ficar saudável".