Pular para o conteúdo
use-cases / per-customer-sandboxes-fleet-scale / hero
CONTAINERS · SAAS MULTI-TENANT · ESCALA DE FROTA

Sandboxes por cliente em escala de frota

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.

Ler os docs de frota
use-cases / per-customer-sandboxes-fleet-scale / mechanism

Como um signup vira um dos 812 sandboxes

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.

01 · WEBHOOK

A Stripe chama seu endpoint exec

POST /api/v1/exec/scripts/1/webhooks/signup

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.

02 · COPY

O script clona o template do cliente

POST /api/v1/containers/$TEMPLATE/copy

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.

03 · ROUTE

Nova URL devolvida ao usuário

https://$PROJECT-$CID-...containers.hoody.com

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.

use-cases / per-customer-sandboxes-fleet-scale / economics

A matemática que torna o isolamento em escala de frota barato

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.

LEDGER DA FROTA · 812 TENANTS
# três nós bare-metal, preço de marketplace3 flat-rate servers · one monthly bill# misto entre eu-1, us-1, ap-1812 tenants (287 + 304 + 221)# o custo-por-tenant colapsabill ÷ 812 = cost shrinks as density grows

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.

POR TENANT · OUTRAS STACKS
  • AWS FARGATE POR TENANTvCPU + memória cobrados por task, mesmo ocioso
    $8–25
  • K8S NAMESPACE POR TENANTOverhead de cluster amortizado entre namespaces
    $3–10
  • POD DEDICADO POR TENANTRAM + CPU reservados, pagos quente ou frio
    $5–15
  • HOODY · CONTÊINER POR TENANTum preço do servidor ÷ densidade do tenant — limitado pela máquina, não pela contagem
    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.

use-cases / per-customer-sandboxes-fleet-scale / powers

O que contêiner-por-tenant destrava nesse preço

Quando isolamento é barato, a arquitetura para de fazer concessões. As features que seu CFO vetava viram padrão.

ONBOARDING

Cada cliente novo é um `cp` de distância

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.

OFFBOARDING

Delete de GDPR é uma chamada HTTP

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".

RAIO DE EXPLOSÃO

O bug de um tenant fica dentro de um tenant

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.

use-cases / per-customer-sandboxes-fleet-scale / punchline

Isolamento por tenant custava por tenant. Agora custa por servidor.

ERA$3–25 / tenantfargate, namespace ou pod dedicado
AGORAuma conta de tarifa fixa812 sandboxes, 3 máquinas bare-metal, nenhuma métrica por tenant
use-cases / per-customer-sandboxes-fleet-scale / replaces

O que isso substitui

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:

  • AWS Fargate por tenantvCPU + RAM cobrados por task, quente ou frio
  • Kubernetes por namespaceOverhead de cluster + control plane por tenant
  • Multi-tenancy compartilhado com filtro tenant_idUm WHERE esquecido vaza dados de cliente
  • Overhead de Postgres row-level securityPolicy em cada tabela, audit em cada query
  • Pods de tenant dedicadosComputação reservada paga, usada ou não
use-cases / per-customer-sandboxes-fleet-scale / cta

Oitocentos tenants isolados nos mesmos servidores que seu laptop substitui. A arquitetura honesta finalmente é a viável.

use-cases / per-customer-sandboxes-fleet-scale / related

Leia os outros