Pular para o conteúdo
use-cases / one-sandbox-per-customer / hero
CONTAINERS · MULTI-TENANT SAAS

Um sandbox por cliente, automaticamente

Pare de espalhar tenant_id por cada tabela. Quando um cliente se cadastra, um script exec copia um contêiner novo-cliente e lhe entrega sua própria URL, seu próprio sistema de arquivos, seu próprio SQLite. Isolamento é o sistema operacional entre eles, não uma cláusula WHERE.

use-cases / one-sandbox-per-customer / trigger

What that single API call provisions

Each POST to /api/v1/projects/{id}/containers spins up an isolated environment. One call, one tenant, one URL handed back to your app.

01 · WEBHOOK

Signup triggers the container POST

Your Stripe (or any billing) webhook hits a Hoody Exec script. No Express, no server config — just a file in scripts/.

02 · ISOLATION

Linux namespaces, not a WHERE clause

The new container has its own filesystem, its own SQLite, its own ramdisk. Tenant A literally cannot see tenant B's data.

03 · URL

A unique URL back to your app

The response includes a container URL. Your app redirects the user into their own sandbox in the same deploy window.

04 · FIREWALL

Per-tenant network rules cloned

Container network and firewall rules are copied from your template. Every new tenant starts from the same security baseline.

05 · IDLE

Zero cost when idle

Stop the container and it costs nothing. BTRFS keeps only the delta from your template — disk stays cheap even at scale.

06 · OFFBOARD

DELETE container = forget tenant

One DELETE call removes the container and all their data. GDPR offboarding is not a script, it is a single HTTP call.

The whole flow is one webhook handler. No Kubernetes operator, no namespace YAML, no cluster admin. Three HTTP calls: webhook in, container out, URL to user.

use-cases / one-sandbox-per-customer / compare

Multi-tenancy compartilhado vs contêiner por cliente

As escolhas tradicionais eram uma coluna em toda tabela ou uma frota de VMs que você não conseguia bancar. O Hoody é uma terceira forma: contêineres baratos o bastante para dar um a cada cliente.

DIMENSÃO
BANCO COMPARTILHADO · TENANT_ID
HOODY · CONTÊINER POR CLIENTE
  • ISOLAMENTOWHERE tenant_id = $1 — e você torce para que toda query lembreNamespaces Linux. O tenant A literalmente não consegue ver o filesystem do tenant B.
  • SUPERFÍCIE DE VAZAMENTOtodo JOIN, todo hook do ORM, todo script de relatórioa fronteira do contêiner. Um artefato para auditar, não 200 sites de query.
  • CONFIG POR TENANTtabela de feature flags, frágil, meio-testada em devedite o ambiente de um contêiner. Os outros 399 ficam intactos.
  • VIZINHO BARULHENTOum cliente pesado pode travar o banco compartilhadocotas de CPU e disco por contêiner; a carga de um tenant fica na caixa dele.
  • OFFBOARDINGDELETE … WHERE tenant_id … mais 12 outras tabelas que você esqueceuDELETE no contêiner. Os dados vão junto. GDPR é uma chamada HTTP.
  • CUSTO EM OCIOSIDADEcada linha custa storage mesmo com o cliente dormindopare o contêiner — zero CPU, zero RAM. O BTRFS guarda só o delta.
  • sem colunas tenant_id
  • sem auditorias de segurança em nível de linha
  • sem YAML de namespace
  • delete = esquecer
use-cases / one-sandbox-per-customer / punchline

Multi-tenancy deixa de ser um problema de arquitetura. Vira um comando `cp`.

ONBOARDINGPOST /containers/$TEMPLATE/copy
OFFBOARDINGDELETE /containers/$CID
AJUSTE POR TENANTPATCH /containers/$CID [ env_vars ]
  • isolamento de nível namespace
  • delete GDPR em uma chamada
  • um contêiner por conta
use-cases / one-sandbox-per-customer / replaces

O que isso substitui

Isolamento por tenant historicamente significou ou uma cláusula WHERE inteligente ou um cluster caro. Contêiner por cliente desloca os contornos usuais:

  • Multi-tenancy compartilhado (coluna tenant_id)Uma query ruim expõe todo mundo
  • Middleware customizado de isolamento de tenantGuarda artesanal que você mantém para sempre
  • Políticas de row-level security do PostgresResposta certa, custosa de auditar por tabela
  • Namespace Kubernetes por tenantOverhead em nível de cluster, time de ops obrigatório
  • Schemas / bancos por clienteMultiplicador de migration, dor no pool de conexões
  • Linhas de metering Stripe em tabela compartilhadaRastreamento de uso colado na mesma caixa compartilhada
use-cases / one-sandbox-per-customer / cta

Clientes ociosos não custam nada. Os ativos escalam sob demanda. A coisa toda roda em $49 de bare metal até você ter centenas de pagantes.

use-cases / one-sandbox-per-customer / related

Leia os outros