A white-labeled, multi-tenant SaaS is one of the hardest things to ship cleanly. Our founder, Altin Ukshini, presented the framework we use for exactly this problem at DevOpsCon Munich 2025 (and earlier at Berlin 2025). This is the architecture behind that talk.
The challenge
Picture a product where every client gets contractual isolation - one AWS account per client - and inside each account runs the full ladder of environments: dev, qa, uat, then prod1, prod2 through prodN. The product itself is a mix: ECS Fargate services, Lambda functions, and a static frontend on S3 and CloudFront.
Now multiply that by every tenant, every environment, and every team shipping into it. The mandate pulls in three directions at once - scale deployments, keep flexibility, and guarantee traceability - and the three usually fight each other.
The way teams normally “solve” this is to copy-paste a pipeline per service, per environment, per tenant. It does not scale, and it quietly destroys the audit trail the moment anything changes. Within a few quarters you are maintaining hundreds of near-identical pipelines and nobody can say with confidence what shipped where.
Our approach
The reframe at the heart of the work: white-labeled SaaS does not mean you duplicate services. It means you parameterize and control deployments through metadata.
That turns into an architecture that is deliberately scalable, isolated, and config-driven.
A single source of truth
One infrastructure repository defines the estate. Clients get isolated accounts provisioned from it, not forks of it - so there is one place to reason about, and isolation is a deployment property rather than a maintenance burden.
Outputs, not hardcoding
Shared infrastructure is provisioned with Terraform and CloudFormation, and it publishes its outputs - resource ARNs and names - into SSM Parameter Store. Everything downstream resolves those values at deploy time instead of baking them in. A service never needs to know where a queue or database lives in a given tenant’s account; it resolves the ARN through ${ssm:...}, which removes an entire class of cross-stack coupling.
Metadata as the control plane
The variables that actually differ between tenants - regions, feature flags, config locations, deployment eligibility - live in declarative metadata, not in pipeline code. The pipeline logic stays generic; the per-repo specifics stay in data.
Under the hood
The original contribution of the talk is the traits-driven repository. Every repo carries a .traits/ folder with two scoped dictionaries:
build.yml- how CI should build the service (family, pipeline type, overrides).deployment.yml- where the build is allowed to go.
The deployment file declares eligibility: which provider, environments, regions and clusters a given build may land in, with YAML anchors keeping it DRY and per-environment overrides where they are needed. From there the flow is mechanical and identical for every repo:
- The pipeline reads
.traitsand checks eligibility for the target environment. - It resolves the relevant infrastructure outputs from SSM.
- It builds once into an immutable, versioned artifact.
- It promotes that same artifact to every eligible environment via a rolling update driven off a generated task definition.
You do not have to adopt the full spec on day one. A first version can carry the same metadata in a file you already ship - the config and engines keys in package.json, for instance - and graduate to dedicated traits files once the matrix grows.
The outcome
This is not a whiteboard pattern. It runs in production across our clients’ infrastructure, deploying hundreds of services across more than 35 environments from a single, governed pipeline.
Deployments become something you parameterize instead of something you duplicate. One immutable, versioned artifact is promoted across every environment it is eligible for, carrying a complete record of what shipped, when, and who approved it.
The same metadata model holds across wildly different asset types - microservices, serverless functions, libraries, monoliths, mobile apps, infrastructure artifacts, database updates, and multi-cloud or on-prem targets. Auditability stops being a reporting exercise done before an assessment and becomes a property of how the system is built: GitOps for a single source of truth, transparency into what shipped, traceability for when, and accountability for who.
That combination - scale, flexibility and a guaranteed audit trail, held at the same time - is the whole point.
Key takeaways
- Metadata is the control plane. Keep pipelines generic; push what differs - tenant, region, environment, flags - into declarative metadata.
- Build once, deploy many. An immutable, versioned artifact promoted across environments is the foundation of both traceability and speed.
- Isolation without duplication. One account per client gives contractual isolation; a single infra repo plus metadata keeps it from becoming N copies to maintain.
- Wire services to outputs, not to each other. Publishing ARNs to SSM and reading them via
${ssm:...}removes cross-stack coupling. - Start with what you have. Any file you already ship can hold the first version of your pipeline metadata - adopt dedicated traits later.