Architecting Multi-Tenant Backstage Instances in a Shared...
summary
Proposes deploying separate Backstage instances per customer inside a single Kubernetes cluster, using namespace isolation and per-instance app-config mounted as ConfigMaps, an auth interceptor/IDP per org, and shared Postgres with per-tenant DB prefixing (e.g., XYZ_catalog) to avoid cross-tenant data leakage. Adds a central Frontstage service + admin UI storing configs in MongoDB, automating plugin installs for the hundreds of Marketplace plugins, and a delegate agent installed in customer infra to fetch private Git/K8s data — yielding a working Backstage-as-a-Service.
AI-written summary · about
chapters (13)
- 0:00Multi-tenant Backstage intro
- 1:06Developer effectiveness basics
- 2:29Setting up Backstage app
- 3:33Installing plugins
- 7:08Adding auth middleware
- 9:14Upgrading Backstage
- 10:59Multi-tenancy with namespace isolation
- 12:21Database isolation for tenants
- 14:50Admin UI for plugins
- 17:44Plugins on private networks
- 20:36Enterprise user management
- 21:42Audit trails and policies
- 23:30Summary
related talks
01h 00mArchitecting multi-tenant PaaS offerings
29mManaging a Multi-Tenanted Kubernetes Cluster in Production
27mIntroduction to Backstage
29mNavigating the Multitenancy Maze: Avoiding Kubernetes Antipattern Pitfalls
28mBuilding Open Developer Platforms with Backstage
05mNamespace Multi-Tenancy, But All The Problems Related To It
46mAdvanced Kubernetes: Lesson Learned From Building..
49mA Front Row Seat to Backstage Adoption