Architecture advice for B2B Multi-Tenant SaaS Orchestration at scale? Hi everyone! 👋 I’m looking for some architectural validation and best practices from folks who have built large-scale multi-tenant infrastructure using Pulumi. The Context: We are building a B2B SaaS where each client gets a heavily isolated infrastructure footprint. For context, assume a "Dedicated EKS cluster + RDS instance + VPC per tenant" model. We are preparing to scale to hundreds (and eventually thousands) of tenants, meaning hundreds of active Pulumi stacks. Our Current Architecture Plan: 1. Control Plane: A custom stateful orchestrator (using Temporal + Postgres) that tracks tenant onboarding, feature rollouts, and configurations. 2. Execution: Our Control Plane makes asynchronous REST calls to the Pulumi Cloud Deployments API to trigger up/destroy operations, passing dynamic configurations for each specific tenant stack. My Questions for the community: 1. Repository Structure: We are currently leaning toward a strict Monorepo / Single Main Branch approach, using a "platform versioning" strategy to roll out updates to tenants in waves. However, we've seen others advocate for a "Branch-per-Tenant" model to guarantee strict isolation of states and code versions. Which model scales better when you hit 50+ tenants, and why? 2. Automation API vs. Deployments API: Is the Deployments API the recommended path for orchestrating 100s of concurrent tenant environments, or do large-scale teams still prefer running the Automation API on their own worker fleets? 3. Configuration Management: We are storing tenant-specific configs (instance types, scaling limits, feature flags) in our Stack YAMLs for massive multi-tenant sprawl. Is this the right way to go? 4. Cloud Provider Limits: For those doing heavy "tenant-per-stack" deployments, how do you handle AWS/GCP API rate limiting when a platform-wide upgrade triggers 50+ concurrent Pulumi runs? Would love to hear any "gotchas" or war stories from anyone doing dynamic multi-tenant orchestration! Thanks in advance. 🚀

👋 My team manage some per-tenant infra and we use Automation API that run on azure functions on container app (aka AzF on ACA). We keep configurable most of resources and we pass tenant's configuration from db. I feel that keeping branch per tenant would be rebase/merge hell o.O Automation API is nice but there are some issues in our setup. Our application deployment swaps images and when there are some infra deployment in progress, they will fail on app deployment. Sometimes it would be nice to have separate processing for infra deployment (maybe lambda triggering batch jobs?) Also at least our infra deployments are high resource consuming so we need to set some max concurrency, which solves both memory/cpu issues and rate limiting issues. As said before, we keep configuration in database and we pass it in runtime to pulumi automation and it just works 🙂

Hi @quick-noon-18541 thanks for the reply. Couple of questions: 1. How do you manage state in this case? Do you use Pulumi Cloud or S3 backend? 2. How do you guys maintain the audit trail for updates? You said that you use DB for config so how do you track the changes or updates done to client's environment? I believe you would need this trail for Audits right?

We manage states in blob storage (like s3 but in azure). We keep audit in db too, we log code version and config version there. We keep config immutable and versionable.

interesting setup that you describe there. We run a multi-tenant platform using pulumi, with multiple stages per tenant, and multiple levels which are an abstraction layer for permission boundaries/organizational layers. we use a cascade of repositories for the rollout, to rollout changes/updates in layers/stages. This allows us to have one layer where each tenant == one branch, but then onwards, each tenant has an own "tree" of repos for the tenant specific stacks. We use the automation API for orchestration, so cannot compare to the cloud deployments API. A few gotchas: • stack size: keep it small, so that rollouts are fast, and blast radius is in control. Also resource consumption can skyrocket if your stack becomes too large • use stack references where possible to pass data/config/information • use staged/delayed rollouts, to avoid hitting cloud provider API limits • pulumi config has a size limit (at least we did hit it in using typescript/pulumi), so we either have to split into smaller stacks or offload some config into a separate system/file. • also: you might want to consider having platform specific config and then also might need to enrich it with per-tenant-specific config. Think about how you could split this, so that you can update the platform config, without touching the customer specific inputs, and vice-versa