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. Compose sys9 services with your application — create a Box and database per tenant, scope credentials, and track the resources each customer uses.
Four things every customer needs.
Compose separate compute and data with scoped credentials and your own resource inventory. Your application owns tenant identity, authorization, and attribution.
Isolated compute per tenant
Create a Box per customer from a template containing only shareable code and data. A Root Snap contains filesystem state; persistent Volumes and running processes are separate.
Isolated data per tenant
Create a database per customer and restrict its credentials to that customer. Map application tenants to the right resources and authorize every request; database separation does not replace those checks.
Per-agent secrets
Use drive9 contexts and explicit vault grants to limit credential access. Your application selects the correct tenant context, permission, and lifetime for each agent.
Track compute and storage
Track Host Compute, retained storage, and other service usage separately. Your application keeps the mapping from each resource to its tenant; idle capacity and retained data can still contribute to usage.
Separate resources with explicit tenant authorization.
A separate database and Box reduce shared execution and data surfaces. Your application still maps tenants to orgs, projects, databases, and credentials, and checks access on every operation.
Create resources, then grant access deliberately.
Before this example, install sys9, authenticate run9 in the intended project, and prepare app-template with only public seed data. Choose resource names unique to your customer. After creation, store the tenant-to-resource mapping and grant scoped credentials through your application. A Box name does not create a tenant access policy.
# app-template contains only shareable seed data sys9 db branch create app-template --name tenant-acme sys9 db db status tenant-acme # Do not route tenant queries until ACTIVE; stop on CREATE_FAILED. # Uses the authenticated run9 project sys9 run box create tenant-acme --image public.ecr.aws/docker/library/alpine:3.20 # Next: record resource IDs in your tenant inventory. # Issue scoped credentials and enforce access in your app. # Names alone do not authorize tenant access.
Account for retained data and reserved capacity.
Tenant attribution comes from your resource inventory. Measure compute and storage separately and confirm product-specific rates and quotas before setting your own prices.
Track compute and storage
Host capacity and retained storage have separate usage. Reclaim resources you no longer need; stopping an agent does not imply zero total usage.
Per-product usage
Keep tenant identifiers in your resource inventory and reconcile each service separately. Shared hosts and resources need an attribution policy in your application.
Prepare safe templates
Keep templates free of customer data and credentials. Validate provisioning, resource quotas, and deletion paths for each tenant.
Identity is still part of your application.
Use each product’s current authentication and your own tenant authorization. auth9 is a planned product, not a dependency you can deploy today.
The services behind this shape.
Forkable sandbox
Separate Boxes per tenant, in projects your application authorizes.
run9 → db9Postgres, from terminal
A branched database per customer — db, data, and files.
db9 → drive9Vault + filesystem
Per-agent secret grants and a tenant-scoped filesystem.
drive9 → auth9 · plannedOne identity
Planned identity service; continue using current product authentication.
auth9 →Give every customer their own isolated agent.
Tell us about the per-tenant AI you’re shipping. We can help map your identity model, resource boundaries, and expected usage to the current services.