[Kubernetes & alternativas]

Alternativa ao Kubernetes em 2026: panorama completo

80% das startups brasileiras não precisam de Kubernetes. O problema é descobrir antes de gastar 18 meses aprendendo.

Kubernetes é a escolha certa pra empresa Series B+ com 50+ servidores, time de plataforma de 3+ pessoas, ou compliance que pede o nome no contrato. Pra startup brasileira de 5-15 engenheiros e 1-30 servidores, é overkill: hello-world tem 300 linhas de YAML, instalar TLS automático pede operador especializado, dois SREs custam mais que toda a infra. Esta página agrega o que escrevemos sobre o segmento alternativo: quando Kubernetes não cabe, quais escolhas fazem sentido por estágio, e como sair de um cluster K8s sem reescrever o mundo.

TL;DR

O argumento "você precisa de Kubernetes pra escalar" é genuinamente verdadeiro pra um conjunto pequeno de aplicações — e completamente irrelevante pra maioria das startups que estão escolhendo orquestração hoje. O custo de Kubernetes não é o cluster, é o time: 6+ meses de curva de aprendizado, 1-2 SREs dedicados, stack de 5+ produtos ao redor (cert-manager, ingress-nginx, monitoring, service mesh). O segmento alternativo divide em três tiers: deployer minimalista (Kamal, single-server first), painel sobre Docker (Coolify, Dokploy), e orquestrador leve com plano de controle próprio (HeroCtl, K3s pra quem quer K8s simplificado). Os quatro posts agregados aqui cobrem o panorama completo: o frame original do "overkill", comparativo K3s vs orquestrador próprio, ECS gerenciado vs Kubernetes vs auto-hospedado, e o caso real de migração de K8s pra stack mais simples.

[01]

Quando Kubernetes é genuinamente overkill?

A pergunta certa não é "Kubernetes é bom?", é "Kubernetes é proporcional?". Pra startup brasileira de 5-15 engenheiros, a desproporção fica visível na primeira semana: 300 linhas de manifesto pra HTTP+TLS+ingress, RAM mínima de 4-8 GB no plano de controle, e a primeira pessoa contratada virando full-time DevOps. Listamos os sinais inequívocos de quando o custo escondido superou o benefício técnico.

Leia o post completo
Kubernetes overkill: quando você não precisa →
  • Hello-world K8s + TLS + ingress: 300+ linhas de YAML
  • Time mínimo: 1-2 SREs dedicados (R$ 30-40k/mês cada)
  • Stack ao redor pede 5+ produtos pra cobrir o básico
[02]

K3s ou orquestrador próprio: quando cada um faz sentido?

K3s resolve "Kubernetes leve" mas mantém o modelo K8s — você ainda escreve YAML K8s, ainda lida com pods/deployments/services, ainda precisa de cert-manager pra TLS. É a escolha certa pra quem quer manter compatibilidade total de manifestos com o ecossistema CNCF. Orquestrador com plano de controle próprio (como HeroCtl) entrega o outcome — HA, ingress, certificados, métricas — sem exigir que você fale K8s. Trade-off real, post completo.

Leia o post completo
K3s vs HeroCtl: quando cada um faz sentido →
  • K3s mantém compatibilidade com manifestos K8s
  • HeroCtl entrega o outcome com manifesto enxuto
  • Faixa ideal sobreposta: 1-30 servidores
[03]

AWS ECS, Kubernetes ou auto-hospedado: como decidir?

A trinca que aparece na maioria das discussões de plataforma na startup brasileira. ECS é "Kubernetes-lite gerenciado pela AWS" — esconde complexidade mas trava na AWS e cobra em USD. Kubernetes (EKS/GKE) é o padrão CNCF com tudo que ele implica. Auto-hospedado (Hetzner + orquestração leve) é o caminho de menor custo financeiro com o maior custo operacional inicial. Análise lado-a-lado dos três.

Leia o post completo
AWS ECS vs Kubernetes vs auto-hospedado →
  • ECS: trava na AWS + custo em USD + sem control plane fee
  • EKS: ~US$ 73/mês de control plane + NAT + LB
  • Auto-hospedado: 1/4 do custo, mas pede dev capaz
[04]

Como migrar de Kubernetes pra stack mais simples sem virar projeto de 6 meses?

A maioria das migrações de saída de Kubernetes que vimos são gradativas, não big-bang. Começa pelo serviço menos crítico, segue pela primeira aplicação stateless, depois banco com janela de manutenção combinada. Documentamos um caso real: startup brasileira saindo de EKS pra cluster auto-hospedado, com cronograma, ferramentas usadas e armadilhas evitadas.

Leia o post completo
Migrar de Kubernetes pra stack mais simples: case real →
  • Cronograma típico: 6-10 semanas pra startup média
  • Migração gradativa por serviço, nunca big-bang
  • Custo recorrente caiu 68% no caso documentado
[05]

O que de Kubernetes vale levar pra próxima stack, mesmo saindo?

Sair de Kubernetes não é negar tudo que ele te ensinou. Conceitos como manifesto declarativo, health checks de aplicação, rolling deploy seguro e separação clara entre desired state e current state são patrimônio da indústria — qualquer alternativa séria implementa. O que se descarta é a ergonomia complexa: 17 tipos de recurso, RBAC granular ao extremo, e o ecossistema de operators que pede 5 produtos pra rodar TLS automático.

Leia o post completo
Os conceitos K8s que ficam, e os que saem →
  • Manifesto declarativo: fica
  • Health check de aplicação: fica
  • RBAC com 12 níveis e 7 CRDs: sai
[perguntas]

Perguntas que aparecem em todo planejamento

Quando devo usar Kubernetes apesar do custo?

Quatro sinais inequívocos: time de plataforma com 3+ pessoas dedicadas, escala de 50+ servidores, dependência de operators maduros (Postgres, Kafka, Cassandra) ou compliance que cita Kubernetes nominalmente (FedRAMP, alguns frameworks de saúde). Fora disso, o custo operacional supera o benefício na maioria dos casos brasileiros que medimos.

K3s é Kubernetes "de verdade" ou alternativa?

É Kubernetes de verdade — passa nos testes de conformidade CNCF. A leveza vem de empacotamento (binário único, SQLite no lugar de etcd por padrão) e remoção de features que a maioria não usa (alpha features, alguns drivers de cloud). Pro código da sua aplicação e seus manifestos, é indistinguível de K8s vanilla.

Posso usar AWS ECS sem AWS?

Não. ECS é serviço fechado da AWS — não existe distribuição on-prem ou em outras clouds. Se você quer "K8s-lite gerenciado", o equivalente em outras clouds é Cloud Run (GCP) ou Container Apps (Azure). Cada um trava na sua nuvem.

Migração de K8s pra stack simples perde features importantes?

Perde features que você provavelmente não estava usando bem. Service mesh, RBAC granular ao nível de cluster, custom resources — tudo isso some. Mas pra aplicação web típica (HTTP, banco, cache, workers), o conjunto que sobra cobre 95% do que estava efetivamente em uso. Audite o cluster antes da migração: quantos CRDs custom, quantos operators, quantos namespaces ativos.

Em quanto tempo um cluster auto-hospedado paga o custo da migração?

Pelos casos que medimos, entre 4 e 9 meses. O custo upfront é tempo de dev (3-6 semanas part-time) e a janela de aprendizado da nova stack. O ganho recorrente é a soma da fatura AWS evitada + tempo de SRE liberado pra outras coisas.

Posso rodar Kubernetes em VPS barato (Hetzner) e ter o melhor dos dois mundos?

Pode tecnicamente, mas a economia de hardware fica engolida pelo custo operacional. Você paga menos pelo servidor e continua pagando o mesmo tempo de dev/SRE pra manter o cluster. A maioria dos times que tentou esse caminho voltou pra orquestração leve em 12-18 meses.

Vale a pena migrar antes do próximo round de funding?

Depende do seu burn. Se a fatura AWS está representando >12% do MRR, sim — investidores vão perguntar. Se está em <5%, otimização precoce. O sinal mais forte é tempo de SRE, não dinheiro: se 1 dev sênior está dedicado a manter o cluster, você está pagando o custo de Kubernetes mesmo que a fatura ainda esteja pequena.

Saída de Kubernetes começa por uma comparação honesta

Não é sobre "Kubernetes ruim". É sobre proporção: quanto time, quanto dinheiro, quanta complexidade pra qual estágio. Os quatro posts cobrem o panorama; o comparativo direto te dá os números.

Posts agregados nesta página