Publicar sem Git: do ZIP ao site no ar em minutos

Tecnologias suportadas sem Dockerfile

Se houver um Dockerfile na raiz do ZIP, ele é usado no lugar da receita automática. Quando não há, o log do build mostra o Dockerfile gerado — útil para entender e corrigir um erro.

Passo a passo

• Crie a conta em devoracloud.com/register (7 dias grátis, sem cartão).
• No painel, crie um projeto novo e escolha o envio por ZIP.
• Envie o arquivo (até 512 MB).
• Acompanhe o build: análise, construção, publicação e verificação de saúde.
• Quando o status ficar pronto, o site responde em https://seu-projeto.apps.devoracloud.com, com certificado automático.

Prefere não fazer nada disso? Gere o token de IA no painel e peça à sua IA para publicar: ela prepara o ZIP, cria o projeto e acompanha o build por você.

Como montar o ZIP

Coloque na raiz do ZIP o arquivo que identifica o projeto: package.json, requirements.txt, go.mod ou index.html. Uma única pasta no topo também funciona. Use ZIP; o formato tar não é aceito.

Deixe de fora:

• node_modules — as dependências são instaladas no build.
• .next, dist e build — o build é refeito na plataforma.
• .git — o histórico não é necessário.
• .env e qualquer arquivo com senhas ou chaves — use as variáveis de ambiente do projeto.
• Uploads de usuários e bancos locais, como arquivos .sqlite — arquivos vão para o S3 e dados para o PostgreSQL.

Um ZIP enxuto sobe mais rápido e evita levar para a nuvem algo que só fazia sentido no seu computador.

PORT e 0.0.0.0: o erro mais comum

A aplicação precisa escutar no endereço 0.0.0.0 e na porta indicada pela variável de ambiente PORT. Se ela escutar só em localhost (127.0.0.1) ou numa porta fixa diferente, o build termina com sucesso, mas a verificação de saúde não consegue falar com o app e o deploy falha.

• Node.js: app.listen(process.env.PORT || 3000, "0.0.0.0").
• Next.js: o script start padrão (next start) já respeita a variável PORT.
• Python: rode o servidor (uvicorn, gunicorn) com host 0.0.0.0 e a porta de PORT.
• Go: leia os.Getenv("PORT") e escute em ":" + porta.

Confira também os scripts: em projetos Node, o package.json precisa ter build (se houver etapa de build) e start.

Outros erros comuns no primeiro deploy

Se o deploy falhar, abra o log antes de mudar qualquer coisa. Os casos mais frequentes são simples de resolver:

• Dependência faltando: o pacote funciona no seu computador porque foi instalado à mão, mas não está no package.json ou no requirements.txt.
• Versão errada do runtime: o projeto exige uma versão de Node.js ou Python diferente da que o build detectou.
• Caminho com letras maiúsculas e minúsculas trocadas: funciona no Windows ou no macOS, mas não no Linux do build.
• Variável de ambiente ausente no build: o código tenta ler uma chave que só existia no seu .env local.

Corrija, gere um ZIP novo e publique outra vez. Enquanto isso, a versão anterior continua no ar.

Variáveis, banco e S3

Senhas e chaves entram como variáveis de ambiente do projeto, disponíveis no build e na execução. Se o sistema usa banco, crie o PostgreSQL ou o Redis antes do primeiro deploy: a conexão chega ao app como DATABASE_URL (ou REDIS_URL). Para imagens e documentos, crie o S3 privado do projeto; o app recebe as variáveis S3_* prontas.

Nunca coloque segredos em variáveis lidas pelo navegador, como as que começam com NEXT_PUBLIC_.

Novas versões e GitHub depois

Para atualizar, envie um novo ZIP e publique de novo. Um deploy que falha nunca substitui a versão que está no ar: o site continua funcionando enquanto você corrige.

Quando o projeto amadurecer, conecte o GitHub uma vez no painel, em Conexões, e vincule o repositório ao projeto. A partir daí, cada push na branch escolhida gera um deploy. O envio por ZIP continua disponível para quem preferir.

Perguntas frequentes