
Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
Oitocentos contêineres isolados em três servidores bare-metal. Cada cliente recebe seu próprio sistema de arquivos, sua própria URL, seu próprio kernel namespace — uma conta de servidor de tarifa fixa, nenhuma métrica por tenant. A arquitetura honesta deixou de ser a cara.
dashboard de operações de frota · 812 tenants em 3 nós bare-metal · misto a $0,18 por conta por mês
Seu webhook de billing chama um script Hoody Exec. O script copia um contêiner de cliente novo a partir do snapshot template, o novo tenant cai em sua própria URL e o dashboard de frota incrementa em um. Três chamadas HTTP, sem orquestrador.
Um V8 isolate serverless. A URL do webhook é só um arquivo TypeScript em scripts/1/. Sem Express, sem config de servidor, sem contêiner próprio.
BTRFS copy-on-write — cada novo contêiner consome apenas o delta do template no servidor alugado. Regras de firewall e rede clonam com o snapshot. Cai em qualquer servidor da frota com folga.
O endpoint de authorize assinado emite um container_claim de uma hora. Seu app redireciona o cliente para o sandbox dele. Tempo total de signup: menos de sessenta segundos.
O pipeline inteiro são três chamadas HTTP. Sem operator do Kubernetes, sem YAML de namespace, sem cluster admin. A frota adiciona tenants do mesmo jeito que uma hash table adiciona entradas — só que cada entrada é um contêiner Linux real.
Seu modelo de cobrança cobra por tenant. Hoody cobra por servidor. Uma vez que a unidade de cobrança troca de tenant para caixa, a figura por tenant encolhe conforme você adiciona densidade — e a curva achata conforme você cresce.
Adicionar os próximos cem tenants não muda a fatura — muda o divisor. KSM deduplica páginas de memória idênticas entre contêineres; BTRFS copy-on-write mantém os bytes da imagem base compartilhados no servidor. Cada novo contêiner usa apenas o delta do template; cobrança fica no servidor de tarifa fixa.
O preço de servidor da Hoody é orientado pelo marketplace e varia por região, especificação e fornecedor. A frota de exemplo usa três nós; servidores do marketplace começam em $29/mês e variam por região, especificação e duração; estimativas de concorrentes são faixas ilustrativas a partir de preços públicos para computação por tenant comparável. A densidade assume cargas típicas de SaaS — tenants que ficam ociosos a maior parte do dia. Bancos de dados pesados ou cargas de IA precisam de mais folga por contêiner.
Quando isolamento é barato, a arquitetura para de fazer concessões. As features que seu CFO vetava viram padrão.
Webhook da Stripe → Hoody Exec → POST /containers/$TEMPLATE/copy. O novo tenant inicia do mesmo snapshot que todos os outros tenants iniciaram. Baseline idêntico, futuro isolado. Sem colunas tenant_id para enfileirar, sem linha compartilhada para esquecer.
DELETE /api/v1/containers/$CID. O sistema de arquivos vai, o SQLite vai, os cron jobs vão, o audit log vai — porque tudo morava em um lugar só. Nada de "DELETE … WHERE tenant_id … mais 12 outras tabelas que você esqueceu".
O script desgovernado de um cliente bate nas cotas de CPU e RAM do contêiner dele. Os outros 811 contêineres da frota não percebem. Sem auditoria de noisy-neighbor, sem tabela de lock compartilhada, sem connection pool compartilhado — kernel namespaces fazem o trabalho de isolamento que a camada de aplicação fingia.
Isolamento por tenant custava por tenant. Agora custa por servidor.
Isolamento por tenant historicamente significava ou um WHERE clever ou uma fatura por tenant. Contêiner-por-cliente em escala de frota desloca os dois:
Oitocentos tenants isolados nos mesmos servidores que seu laptop substitui. A arquitetura honesta finalmente é a viável.