Row-level isolation
A tenant_id column is added to the relevant DocTypes — including User — so every query is scoped to a single tenant instead of relying on application-level checks.
Frappe Apps
SaaS Platform
Multi-tenancy on a single site
A Frappe app that turns a single site into a multi-tenant one. Tenants share the site and are kept apart by row-level tenant_id isolation — so onboarding a customer is a record, not another site to provision, migrate and back up.
- Language
- Python
- License
- MIT
- Runtime
- Frappe app
- Model
- One site, many tenants
- Isolation
- Row-level tenant_id
QUICKSTART
Install
# Install the app onto an existing benchbench get-app https://github.com/vyogotech/saas_platform.gitbench --site your-site install-app saas_platformMigrate
# Add tenant_id across existing tablesbench --site your-site execute saas_platform.patches.add_tenant_id_to_all_tables.execute # Install the custom fieldsbench --site your-site execute saas_platform.utils.add_custom_fields.execute bench restartWhat SaaS Platform gives you
Central identity provider
One authentication layer for the whole service ecosystem. Microservices verify against the central site rather than each maintaining their own user store.
Tenant lifecycle
Tenant creation, customer billing accounts and subscriptions are modelled as first-class documents, so onboarding a subscriber is an API call, not a migration.
Microservice metadata source
Supplies the tenant_id metadata the Frappe Microservice Framework needs for cross-service authentication and data segregation.
Under the hood
A shared-schema tenancy model: one site, one database, a tenant_id discriminator on every tenant-owned DocType and a tenant-aware query layer — so thousands of tenants fit behind one migration and one backup instead of thousands.
Frequently asked questions
Shared schema or database-per-tenant?
Shared schema. Tenants live in one database and are separated by a tenant_id column that the query layer enforces. That keeps migrations, backups and upgrades to a single operation rather than one per customer. Where a customer needs a physically separate database, pair it with Frappe Operator and give them their own site.
Why one site rather than a site per tenant?
Because everything operational scales with the number of sites, not the number of customers — migrations, backups, upgrades and asset builds all repeat per site. One site with row-level isolation keeps those to a single operation. When a customer genuinely needs their own site, Frappe Operator provisions it.
Does it work with standard ERPNext DocTypes?
Yes. The tenant_id field is added through Frappe's custom field mechanism and a migration patch, so stock ERPNext DocTypes gain isolation without forking ERPNext.
How do microservices authenticate against it?
SaaS Platform acts as the identity provider. Services built with the Frappe Microservice Framework verify each request against the central site and receive the authenticated user plus the tenant context that scopes their database access.
Works well with
Microservices Framework
Domain-driven Frappe services
A Python framework for carving secure, multi-tenant services out of the Frappe monolith.
ExploreFrappe Operator
Kubernetes-native Frappe
A production Kubernetes operator that deploys, scales and heals Frappe and ERPNext on any cluster.
ExploreFPM
Frappe Package Manager
npm-style packaging for Frappe apps: versioned .fpm artefacts, private repos, no Git required.
ExploreRunning SaaS Platform in production?
We build and maintain these tools, and we help teams adopt them. Tell us what you are trying to ship and we will tell you honestly whether this is the right piece.
Talk to the team