Tenants, hosts, and the dataset filter

ToRun is built on ABP Framework's multi-tenancy model. A row marked IsMultiTenant has a TenantId column that the framework filters automatically; queries from inside a tenant context never see another tenant's rows. The host context (TenantId == null) sees a different slice — canonical catalogs like SubscriptionPlan, AiProvider and LegalDocument live there.

Why we treat the host as a first-class participant

Most SaaS products bolt the host on as "admin tooling". We model it as a sibling tenant: the host has its own dashboards, its own AI policies, and its own billing relationships. This lets us run our own production traffic on the same primitives every customer uses.

Per-tenant plan-bound features

Subscription plans carry FeatureLimit, Entitlement, Capability and Mode rows. When a tenant activates a plan, their accessible feature set is the intersection of their plan and the global catalog. Adding a new mode does not require touching every tenant — they get it automatically when the plan they are on includes it.

BYOK injection per call

Even with shared infrastructure, BYOK credentials remain scoped to the tenant that owns them. Each AI request resolves credentials inside the tenant context using the same data filter; cross-tenant key leaks are not possible at the storage layer.

What we deliberately do not do

We do not isolate tenants at the database or process level. The scaling cost of one-database-per-tenant kills the unit economics for a creator-marketplace product. The dataset filter plus per-tenant cache scoping is sufficient when the schema is designed for it from day one.