Pitch: estou construindo um PaaS brasileiro para deploy sem Kubernetes

Eu queria compartilhar um projeto que estou construindo e pedir feedback técnico da comunidade.

O projeto se chama Hangar: um PaaS brasileiro para times que querem colocar aplicações em produção no Brasil, com cobrança em reais, deploy via GitHub e menos operação manual de infraestrutura.

A motivação veio de uma dor bem específica que vi se repetir em software houses, startups pequenas e produtos B2B brasileiros:

• deploy em VPS começa simples, mas vira script, proxy, SSL, logs, backup, firewall, banco, volume e monitoramento manual;
• cloud estrangeira resolve muita coisa, mas traz cobrança em dólar e, dependendo do cliente, perguntas sobre onde a aplicação e os dados estão rodando;
• Kubernetes é excelente quando a empresa já tem maturidade de plataforma, mas pesado demais para um time pequeno que só quer colocar uma API, worker ou SaaS em produção;
• cada cliente/projeto acaba virando uma operação diferente, e isso consome margem e tempo de produto.

A hipótese do Hangar é que existe espaço para uma terceira via: um PaaS brasileiro, com experiência moderna de deploy, mas pensado para a realidade de empresas daqui.

A ideia não é “substituir AWS/Azure/GCP em todos os cenários”, nem prometer compliance automático com LGPD. Isso seria desonesto. A tese é mais pragmática:

se o time precisa hospedar aplicações no Brasil, pagar em reais e reduzir a quantidade de infraestrutura que mantém manualmente, um PaaS brasileiro pode ser uma opção melhor que VPS improvisada ou cloud dolarizada para muitos casos.

Como estou desenhando a plataforma

O fluxo que estou buscando é:

1. O usuário entra com GitHub.
2. Cria um projeto e um ambiente.
3. Conecta um repositório.
4. Configura runtime, variáveis, CPU/RAM, domínio e, quando necessário, volumes.
5. Faz deploy e acompanha logs, status, uso e custo no painel.

Algumas decisões que tomei:

Deploy via GitHub

A entrada principal é o repositório. A ideia é manter o deploy perto do fluxo natural de desenvolvimento: push, build, deploy, logs e rollback.

Para times pequenos, isso evita montar pipeline customizado cedo demais. CI pode continuar no GitHub Actions, mas o CD fica na plataforma.

Sem exigir Kubernetes do usuário

Por baixo pode existir orquestração, scheduler, proxy, storage e automação, mas isso não deveria vazar para o usuário comum.

A interface mental que quero entregar é mais próxima de:

• “este é meu serviço”;
• “este é meu banco”;
• “este é meu domínio”;
• “este é meu custo”;
• “este deploy passou ou falhou por este motivo”.

Não “crie Deployment, Service, Ingress, Secret, PVC, StorageClass, NetworkPolicy...”.

Billing em reais e por uso

Uma parte importante é previsibilidade. Plano em reais, franquias claras e uso medido de recursos como CPU, RAM, banda, build minutes e volumes.

Para software house, isso ajuda a repassar custo para cliente sem ficar explicando variação cambial todo mês.

Infra no Brasil

O foco inicial é aplicação brasileira rodando em infraestrutura no Brasil. Isso não resolve LGPD sozinho, porque compliance depende de arquitetura, contratos e processos do cliente. Mas ajuda muito na conversa sobre residência de dados, latência local e jurisdição.

Postgres, volumes, logs e domínios no mesmo painel

O objetivo é reduzir aquele “kit produção caseiro” que todo mundo acaba montando:

• banco provisionado em um lugar;
• DNS em outro;
• logs em outro;
• deploy via script;
• custo em planilha;
• backup manual;
• alerta inexistente.

Ainda estou evoluindo bastante coisa, mas o norte é deixar o básico de produção integrado e visível.

Onde acho que o Hangar NÃO faz sentido

Também quero ser transparente sobre os casos em que eu mesmo não recomendaria usar:

• se você já tem um time de plataforma maduro e Kubernetes bem operado;
• se sua aplicação exige serviços muito específicos de hyperscaler;
• se você precisa de escala global multi-região agora;
• se você quer free tier permanente para hobby project;
• se você espera que a plataforma “resolva LGPD” sozinha.

Nesses casos, provavelmente AWS/GCP/Azure, Kubernetes próprio, Vercel/Fly/Render/Railway ou outra stack podem fazer mais sentido.

Onde acho que pode fazer sentido

Os casos que mais me interessam validar:

• software house que hospeda vários sistemas de clientes e quer padronizar deploy;
• startup brasileira com backend em produção ou perto de produção;
• SaaS B2B que vende para empresas brasileiras e precisa explicar melhor onde roda;
• time pequeno que está cansado de manter VPS, proxy, SSL, banco, logs e deploy manual;
• produto que hoje usa um PaaS estrangeiro, mas sente o custo em dólar ou a falta de operação local.

O que eu queria de feedback

Mais do que divulgar, queria ouvir opiniões técnicas de quem já passou por essa dor.

Algumas perguntas:

1. Se você usa VPS hoje, qual parte da operação mais te incomoda?
2. Se você usa Railway/Render/Fly/Heroku/Vercel, o que te faria considerar um PaaS brasileiro?
3. Para software houses: vocês cobram hospedagem do cliente separado ou embutem no contrato?
4. A dor de “rodar no Brasil e pagar em reais” é real para vocês ou ainda é argumento fraco?
5. O que um PaaS brasileiro precisaria ter para você confiar em colocar algo de produção nele?

Quem quiser testar o Hangar, deixei o acesso aqui:

Hangar Cloud

Mas principalmente: quero feedback sincero. Pode ser crítica técnica, dúvida de arquitetura, comparação com outras plataformas ou experiência real de deploy em times pequenos.

Estou tentando validar se essa dor é grande o suficiente para virar uma plataforma sustentável no Brasil.