Multi-Tenant SaaS on Cloud Run: URLs, JWT, and Provisioning
Hostname routing, tenant provisioning in one API call, and why we avoid per-client Cloud Run services.
One deploy, many tenants
Per-client container services do not scale operationally. Hostname and JWT context resolve tenants at request time — many subdomains can hit the same deployment image.
Platform admins provision tenants through an admin API that creates the tenant record, default admin access, and product deep links in one step.
Load balancer and SSL
Managed certificates and load-balancer URL maps route by host header to the right backend service. The same pattern works for product subdomains, tenant marketing sites, and API gateways on one project.
When to split databases
Early-stage products often use SQLite with backup or a shared PostgreSQL instance with separate schemas or databases per product. Split databases when traffic, compliance, or backup policies require it — not on day one.
FAQ
How fast can you onboard a new tenant?
Under a minute via the platform admin console — tenant slug, default credentials, and product links are returned in one API response.
Related
Service: Multi-Tenant SaaS on GCP
Case study: Multi-Tenant Business Automation Suite