AA
Artemy Arhipov
outubro 21, 2026
Atualizado outubro 21, 2026

VPS para hackathons: como fazer o deploy de um projeto rápido

VPS para hackathons: como fazer o deploy de um projeto rápido

Um hackathon dá à equipe de 24 a 48 horas para transformar uma ideia em algo que as pessoas possam testar. Muitos times escrevem um código que funciona e, na última madrugada, esbarram no mesmo problema: o projeto roda em um único notebook, e a banca precisa de um link.

Um VPS para hackathons resolve isso. É um pequeno servidor alugado que mantém o projeto no ar em um endereço fixo, para que você faça o deploy rápido e use as horas restantes na apresentação.

Este guia é para estudantes, quem vai ao primeiro hackathon e equipes sem uma pessoa de DevOps. Você vai entender:

  • o que é um VPS e como ele se compara à hospedagem gratuita em 2026;

  • como fazer o deploy passo a passo em menos de uma hora;

  • qual configuração combina com o seu tipo de projeto;

  • quais erros mais derrubam uma demo ao vivo.

Por que o deploy pesa tanto no resultado de um hackathon?

Hackathons viraram eventos de massa no Brasil. O hackathon de 2026 da Universidade Presbiteriana Mackenzie reuniu mais de 1.900 inscritos e 35 empresas. No cenário global, a Major League Hacking contou mais de 150 mil participantes em 184 eventos na temporada 2025, com mais de 12.500 projetos criados.

Em eventos desse porte, a banca avalia dezenas de projetos seguidos, e cada equipe tem poucos minutos. Nesse cenário, um link funcionando faz diferença:

  • A banca confia no que consegue abrir. Um projeto publicado mostra que a ideia funciona fora da máquina de quem programou.

  • O localhost falha no palco. Wi-Fi instável do evento, notebook que hiberna ou túnel expirado podem travar a demo antes da funcionalidade principal.

  • O deploy consome tempo. O criador da ferramenta QuickDeploy conta que a desenvolveu depois de quase perder o prazo de um hackathon, porque passou horas tentando colocar o app no ar para os jurados.

Quem publica cedo ganha duas vantagens: a demo fica previsível, e as últimas horas vão para o acabamento do produto.

O que é um VPS e por que ele supera a hospedagem gratuita no hackathon?

Primeiro, alguns termos em linguagem simples:

  • VPS (servidor virtual privado) é uma parte de um servidor físico potente que funciona como um computador separado só seu, dentro de um data center. Ele fica ligado 24 horas, tem IP próprio, e você instala nele o que quiser.

  • PaaS (plataforma como serviço) é uma plataforma onde você envia o código e ela cuida da execução. Render, Railway e Heroku são exemplos.

  • Túnel é uma ferramenta como ngrok ou Cloudflare Tunnel, que cria um endereço público para um projeto que continua rodando no seu notebook.

Por anos, os planos gratuitos de PaaS foram a escolha padrão dos times. Em 2026 essa opção encolheu:

  • Heroku, Railway e Fly.io não oferecem mais um plano gratuito real para um app que fica no ar.

  • O Render ainda tem plano gratuito, só que o serviço web hiberna após 15 minutos sem acesso e leva de 30 a 50 segundos para acordar. Se um jurado abrir o link depois de um tempo parado, a primeira coisa que ele vê é uma tela de carregamento.

  • A DigitalOcean saiu do GitHub Student Developer Pack. A oferta de US$ 200 em créditos para estudantes terminou em 31 de julho de 2026, segundo a Capital & Compute.

  • O plano gratuito do ngrok ficou mais restrito no início de 2026: sessões de duas horas, 1 GB de tráfego por mês e URLs aleatórias.

Para quem está no Brasil, existe ainda a questão do câmbio. Plataformas estrangeiras cobram em dólar, e uma compra no cartão internacional paga IOF de 3,5%, como explica o Santander. O valor final da fatura muda junto com a cotação.

Um VPS não tem esses limites. Ele não hiberna, mantém o mesmo endereço e continua no ar com o notebook fechado. Para um evento curto, o modelo de cobrança também conta. Na Serverspace, a cobrança acontece a cada 10 minutos, então a equipe pode manter o servidor no fim de semana e pagar só por essas horas.

A tabela abaixo compara as três opções.

Critério VPS Plano gratuito de PaaS Túnel (ngrok, Cloudflare Tunnel)
Funciona com o notebook fechado Sim Sim Não
Hiberna sem acesso Não Sim, após 15 minutos no Render Não. A sessão gratuita do ngrok acaba em 2 horas
Endereço fixo IP próprio e domínio personalizado Subdomínio da plataforma URL aleatória no ngrok gratuito
Roda bots e bancos de dados Sim Com limitações Só enquanto o notebook estiver ligado
Tempo de configuração 30 a 60 minutos 10 a 20 minutos Cerca de 5 minutos
Custo no fim de semana Baixo com cobrança fracionada Gratuito dentro dos limites Gratuito dentro dos limites
Melhor uso Demo final e projetos que continuam Sites estáticos e testes rápidos Testes de webhook e trabalho em andamento

Que tipo de servidor um projeto de hackathon realmente precisa?

A maioria dos projetos de hackathon é leve. Um app web com API e um banco pequeno exige bem menos do que um serviço em produção. Um guia simples de dimensionamento:

  • 1 GB de RAM basta para um site estático, um bot ou uma API pequena.

  • 2 GB de RAM comportam frontend, backend e banco juntos, ou um painel de deploy como o Dokploy, que exige no mínimo 2 GB.

  • 4 GB de RAM fazem sentido para vários serviços com monitoramento, ou para o Coolify com alguns apps.

  • Ubuntu LTS é o sistema mais seguro para começar, porque a maioria dos tutoriais e respostas para erros comuns é escrita para ele.

A localização também importa. Quanto mais perto o servidor estiver da banca e dos usuários, mais rápido as páginas carregam. Um servidor nos Estados Unidos ou na Europa adiciona atraso perceptível para quem acessa do Brasil.

Ao alugar um VPS na Serverspace, a equipe recebe:

  • data center em São Paulo, no Equinix SP3, com SLA de 99,9%;

  • servidor pronto em menos de um minuto, o que ajuda quando o relógio está correndo;

  • imagem com Docker pré-instalado, que elimina uma etapa da configuração;

  • tráfego gratuito e ilimitado, sem surpresa na conta se a demo atrair visitantes.

Como fazer o deploy de um projeto em menos de uma hora?

Os passos abaixo partem de um projeto web típico: frontend, backend e banco de dados. Cada etapa é curta, e a primeira acontece antes do evento.

Passo 1. Prepare o projeto antes do evento começar

Monte os arquivos de deploy com antecedência, em um projeto modelo. Você precisa de duas coisas:

  • um Dockerfile para cada parte do app, que descreve como montar e iniciar aquela parte;

  • um arquivo docker-compose.yml, que lista todos os serviços e conecta uns aos outros.

Escreva também um roteiro curto da demo: o que o jurado vê primeiro, qual ação mostra a funcionalidade principal e como fica o resultado. A HackerEarth recomenda escrever esse roteiro antes de qualquer código relevante, porque ele mostra quais funcionalidades realmente precisam funcionar.

Passo 2. Crie o servidor e conecte via SSH

Crie o VPS no painel de controle e adicione uma chave SSH no lugar da senha. A chave é um par de arquivos: o privado fica no seu notebook, o público vai para o servidor. É mais seguro e mais rápido do que digitar senha.

Adicione as chaves públicas de todos que vão fazer deploy. Depois conecte:

ssh root@ip-do-servidor

Passo 3. Instale o Docker e suba o projeto

Se você escolheu a imagem com Docker, pule a instalação. Caso contrário, instale o Docker e o plugin Compose com o script oficial. Em seguida, clone o repositório e suba tudo com um comando:

git clone https://github.com/sua-equipe/projeto.git
cd projeto
docker compose up -d

O parâmetro -d roda os containers em segundo plano, e eles continuam funcionando depois que você fecha o terminal.

Duas configurações evitam dor de cabeça:

  • restart: unless-stopped em cada serviço do docker-compose.yml faz os containers voltarem sozinhos depois de uma falha ou reinicialização;

  • docker compose logs -f mostra em tempo real o que o app imprime, o jeito mais rápido de descobrir por que uma página não abre.

A cada mudança no código, a equipe roda git pull e docker compose up -d --build no servidor. A atualização leva um ou dois minutos.

Passo 4. Tire as chaves de API do código

Projetos de hackathon costumam usar APIs pagas: modelos de linguagem, mapas, pagamentos. Guarde as chaves em um arquivo .env no servidor e inclua .env no .gitignore. O Docker Compose lê esse arquivo automaticamente.

O risco é real. O relatório State of Secrets Sprawl 2026, da GitGuardian, encontrou 29 milhões de novos segredos expostos em commits públicos no GitHub em 2025, e os vazamentos de chaves de serviços de IA cresceram 81% em relação a 2024. Uma chave vazada pode esgotar o orçamento da API antes mesmo da avaliação.

Passo 5. Aponte um domínio para o servidor

Um endereço como nomedaequipe.com.br fica melhor no slide do que uma sequência de números. O domínio .com.br é registrado no Registro.br e custa cerca de R$ 40 por ano, um valor que cabe no orçamento de qualquer equipe.

Nas configurações do domínio, crie um registro A apontando para o IP do VPS. Mudanças de DNS costumam se propagar em minutos, às vezes mais, então faça isso cedo.

Passo 6. Ative o HTTPS com o Caddy

Navegadores alertam o visitante sobre sites sem HTTPS, e algumas APIs nem funcionam sem ele. O Caddy é um servidor web que obtém um certificado gratuito do Let’s Encrypt e o renova sozinho. A configuração inteira pode ter três linhas:

nomedaequipe.com.br {
reverse_proxy localhost:3000
}

Duas condições precisam ser atendidas: o domínio aponta para o servidor, e as portas 80 e 443 estão abertas.

Um alerta: se você reiniciar uma configuração com erro muitas vezes contra o Let’s Encrypt real, pode atingir os limites de emissão e ficar sem certificado por até uma semana. Durante os testes, use o servidor de staging do Let’s Encrypt e troque para o real quando tudo funcionar.

Passo 7. Teste o link como um jurado testaria

Peça que todo o time abra o link no celular ao mesmo tempo. Siga o roteiro da demo no servidor real e confira três pontos:

  • a página carrega no 4G ou 5G e também no Wi-Fi do evento;

  • várias pessoas conseguem entrar e usar o app ao mesmo tempo;

  • a funcionalidade principal responde com dados reais.

Depois, grave um vídeo curto da demo funcionando como plano B.

Quando um painel de deploy como Coolify ou Dokploy economiza tempo?

Um PaaS auto-hospedado é um programa que você instala no próprio VPS para ter um painel parecido com o do Heroku. Sobre o Docker, ele adiciona interface web, SSL automático, deploy a cada git push, bancos de dados em poucos cliques e rollback.

As duas opções mais populares em 2026:

  • Coolify tem a comunidade maior e centenas de modelos prontos para bancos e ferramentas. O painel sozinho usa cerca de 800 MB de RAM.

  • Dokploy tem interface mais simples e usa cerca de 600 MB de RAM. Exige servidor com pelo menos 2 GB.

O painel compensa quando o projeto tem vários serviços, quando colegas sem experiência com terminal precisam publicar atualizações, ou quando a equipe pretende manter o servidor depois do evento. Um relato publicado por um participante descreve um time que instalou o CapRover em um VPS barato às 4 da manhã, durante um hackathon em Cannes, e subiu painéis e análises em minutos.

Atenção à segurança: em janeiro de 2026, pesquisadores divulgaram 11 vulnerabilidades no Coolify. Qualquer que seja o painel escolhido, atualize logo após a instalação e proteja o acesso com senha forte.

Para um único serviço, o painel só adiciona peso. Docker Compose com Caddy resolve esse caso com menos peças.

Quais são as desvantagens de manter o próprio servidor?

O VPS dá controle total, e a equipe assume o trabalho que vem junto. Pese os dois lados antes do evento.

Vantagens:

  • o projeto não hiberna e mantém um endereço fixo;

  • um único servidor hospeda frontend, backend, banco e bot;

  • qualquer linguagem, framework ou ferramenta funciona;

  • o custo fica baixo e previsível em um evento curto.

Limitações:

  • a equipe cuida da configuração, das atualizações e da segurança básica;

  • portas abertas e senhas fracas atraem ataques automáticos em poucas horas;

  • se o servidor cair às 3 da manhã, ninguém reinicia por você;

  • a cobrança continua depois do hackathon até você excluir o servidor.

Hábitos simples reduzem a maior parte desses riscos: chaves SSH, firewall liberando só as portas 22, 80 e 443, e um lembrete para fazer a limpeza depois do evento.

Qual configuração combina com o seu tipo de projeto?

Um app web para a banca

Frontend em Next.js ou React com uma API. Um VPS com 1 a 2 GB de RAM, Docker Compose, Caddy e um domínio .com.br. É o caso mais comum, e o passo a passo acima cobre tudo.

Um projeto de IA que chama APIs de modelos de linguagem

O servidor basicamente repassa pedidos ao provedor do modelo, então precisa de pouca potência. A tarefa principal é proteger as chaves: guarde no .env, defina limite de gastos no painel do provedor e nunca coloque a chave no código do frontend, onde qualquer visitante consegue lê-la.

Um bot para WhatsApp, Telegram ou Discord

No Brasil, muitos projetos de hackathon giram em torno do WhatsApp. A API oficial do WhatsApp entrega mensagens por webhook, e o webhook exige um endereço público com HTTPS que responda o tempo todo. Um plano gratuito que hiberna após 15 minutos quebra o bot. Um VPS pequeno, com 1 GB de RAM, roda o bot em um container que volta sozinho depois de uma falha.

Vários serviços com banco de dados e painéis

Frontend, API, banco, fila e Grafana para métricas. Aqui Coolify, Dokploy ou CapRover economizam tempo, porque os colegas reiniciam serviços e leem logs pelo navegador. Reserve 4 GB de RAM para o painel e os apps.

Um hackathon online de uma semana

O MLH Global Hack Week é uma série de eventos virtuais gratuitos, com duração de uma semana e abertos a qualquer pessoa a partir de 13 anos, inclusive do Brasil. Em sete dias, o projeto recebe mais visitas e mais alterações. O VPS mantém o mesmo link a semana toda, e a equipe publica atualizações quantas vezes precisar.

Quais erros derrubam demos de hackathon e como evitá-los?

  • Fazer o deploy na última hora. Algo sempre quebra no primeiro deploy. Publique a primeira versão nas primeiras horas, mesmo que seja só uma página inicial.

  • Apresentar pelo localhost. Um notebook que hiberna ou um Wi-Fi fraco encerram a apresentação. Faça a demo pelo link publicado.

  • Não ter vídeo reserva. Deixe uma gravação de tela pronta e troque para ela com calma se a demo ao vivo falhar.

  • Testar sozinho. Você sabe quais botões evitar, a banca não sabe. Peça para quem não escreveu o código testar o app.

  • Chaves de API em repositório público. Robôs varrem o GitHub atrás de chaves o tempo todo. Use .env e revise o histórico de commits antes de abrir o repositório.

  • Estourar os limites do Let’s Encrypt. Use o servidor de staging enquanto experimenta com HTTPS.

  • Painel pesado em servidor pequeno. Coolify com 1 GB de RAM deixa quase nada para o app. Dimensione o servidor de acordo com o projeto.

  • Coletar dados pessoais reais sem necessidade. Se a demo pede e-mail, CPF ou telefone, use contas de teste. Dados reais de pessoas trazem obrigações da LGPD, e a ANPD pode aplicar multa de até 2% do faturamento, limitada a R$ 50 milhões por infração. Para uma startup que nasce no hackathon, começar com dados fictícios é o caminho mais seguro.

O que fazer com o servidor depois do hackathon?

Quando a avaliação terminar, escolha um de três caminhos:

  • Manter o projeto no portfólio. Um link funcionando no currículo diz mais a recrutadores do que uma captura de tela. Passe o servidor para o menor plano.

  • Transformar em produto. Alguns projetos de hackathon viram startups. Adicione backups, monitoramento e um ambiente de testes.

  • Excluir. Exporte o banco e os arquivos que quer guardar, depois remova o servidor e o registro DNS.

Se o projeto continuar, a infraestrutura cresce junto. A Serverspace permite adicionar recursos sem tempo de inatividade, e a API, a CLI e o suporte ao Terraform ajudam a automatizar o deploy quando a equipe passar a lançar versões com frequência.

Conclusão: checklist rápido de deploy para o próximo hackathon

Um VPS para hackathons elimina a parte mais estressante do evento: colocar o projeto no ar pouco antes de a banca chegar. O plano resumido:

  1. Prepare Dockerfile, docker-compose.yml e o roteiro da demo antes do evento.

  2. Alugue um VPS pequeno perto do seu público e conecte com chaves SSH.

  3. Suba o projeto com Docker Compose e guarde os segredos no .env.

  4. Configure o domínio e o HTTPS com o Caddy.

  5. Teste o link em vários celulares e grave um vídeo reserva.

Próximo passo: monte um modelo de deploy em um projeto de teste ainda esta semana. No dia do hackathon, basta copiar, fazer o deploy rápido e usar as horas economizadas no produto.

Você também pode gostar...

Usamos cookies para melhorar sua experiência no Serverspace. Ao continuar a navegar em nosso site, você concorda com o Uso de Cookies e com a Política de Privacidade.