Compute Sandboxes · run9 Agent runtime · smith9 · soon Browser · web9 · soon Data Postgres database · db9 Object storage · drive9 Agent memory · mem9 Secrets · vault9 · soon Intelligence Model gateway · gate9 · soon Skills & tools · hub9 · soon Evals · eval9 · soon Coordinate Queues · task9 Realtime · inbox9 · pulse9 · tape9 Teamwork · chord9 · soon Scheduling · cron9 · soon Operate Observability · owl9 Auth · auth9 · soon All products → Explore Solutions Pricing Customers Enterprise CLI Docs Company GitHub Request access
Solutions · Per-tenant AI

Ship per-customer AI without rebuilding the bundle.

Adding an agent feature to a B2B SaaS means giving every customer isolated compute, isolated data, scoped credentials, and a cost you can attribute. That’s a stack most teams build from scratch. sys9 gives you each piece as an atomic service — fork a sandbox and a database per tenant, scope the secrets, and pay only when an agent actually runs.

Request access Already built it yourself? →
Isolation by constructionOne fork per customerPay only when running
the per-tenant bundle

Four things every customer needs.

Isolated compute, isolated data, scoped identity, and attributable cost — each an atomic service you compose, not a framework you adopt.

run9

Isolated compute per tenant

Fork a fresh sandbox per customer — its own OS, its own data, its own packages. One tenant’s agent runs in a sandbox another tenant’s agent never touches. Onboarding a customer is one fork, in ~50ms.

db9

Isolated data per tenant

Give each customer its own database, not a shared table with a tenant column. Branch the db, its data, and its files together. Isolation by construction — there’s no row policy to misconfigure.

drive9

Per-agent secrets

A secrets vault with per-agent grants: a tenant’s agent gets exactly the credentials it should, and nothing else. Plus a shared filesystem scoped to that customer’s work.

run9

Pay only when running

A tenant whose agent is idle costs nothing — sandboxes wake on call and sleep on idle. Usage meters per service, so cost attributes cleanly to the customer who actually ran an agent.

the shape

One fork per tenant. Isolation by construction.

Onboarding a customer isn’t a migration — it’s a fork. A separate database and a separate sandbox mean there’s no shared surface to leak across, and no row-level policy to get wrong.

per-customer, in three calls

Separate resources beat shared ones with rules.

Give each customer their own forked database and their own sandbox, and grant their agent only the secrets it needs. Isolation comes from separation, not from a policy you have to audit — and an idle tenant costs nothing.

db per tenant sandbox per tenant per-agent secret grants idle is free
terminal
db9 branch app tenant-acme
  ✓ isolated db + data + files for acme

run9 fork tenant-acme --as agent
  ✓ sandbox scoped to acme · pay only when running

drive9 vault grant --agent acme-agent stripe
  ✓ per-agent secret grant · nothing else exposed
cost that maps to customers

Idle tenants don’t show up on the bill.

Per-tenant AI only pencils out if a quiet customer is cheap. sys9’s model makes that the default.

Pay only when running

run9 sandboxes wake on call and sleep on idle. A tenant whose agent isn’t working costs nothing while it waits.

Per-product usage

Each service meters its own unit. Cost attributes to the customer who actually ran an agent — not a flat fee spread across every tenant.

Fork, don’t provision

A new customer is a ~50ms fork, not a provisioning job. Scale the tenant count without scaling the ops burden.

on the roadmap

One identity across every service.

Today you scope credentials per agent with drive9’s vault. Full sign-in identity is on the way.

auth9 — one identity, any sys9. Sign in once and unlock every sys9 service, with use-first claim-later for your service too — agent-native via Skill, CLI, and a self-service API. Until it lands, per-agent secret grants in drive9’s vault scope what each tenant’s agent can reach. auth9 · coming soon — follow along →
related products

The services behind this shape.

run9

Forkable sandbox

Isolated compute per tenant; pay only when running.

run9 → db9

Postgres, from terminal

A branched database per customer — db, data, and files.

db9 → drive9

Vault + filesystem

Per-agent secret grants and a tenant-scoped filesystem.

drive9 → auth9 · soon

One identity

Sign in once, unlock every sys9 service. Agent-native.

auth9 →
use-first, claim-later

Give every customer their own isolated agent.

Tell us about the per-tenant AI you’re shipping. Start with a db and a sandbox per tenant today — no signup to begin.

Request access Replacing a DIY stack? →