Scaling Internal Developer Platforms with Stakater MTO

As organizations grow, the complexity of managing Kubernetes environments across multiple teams explodes. Internal Developer Platforms (IDPs) are emerging as the solution — abstracting away Kubernetes complexities and letting our teams focus on building and shipping software.

But how do we scale these platforms efficiently, securely, and cost-effectively?

Enter Stakater Multi-Tenant Operator (MTO) — a Kubernetes-native solution purpose-built to support multi-tenancy and help us scale internal developer platforms with confidence.

Why Internal Developer Platforms Need Multi-Tenancy

IDPs aim to:

• Give developers self-service access to infrastructure

• Apply guardrails to enforce consistency and security

• Centralize platform tools (CI/CD, observability, secrets, etc.)

• Reduce the cognitive load from Kubernetes YAMLs and access controls

But as we onboard more teams, we face challenges:

• Security: How do we isolate team environments?

• Governance: How do we enforce org-wide policies?

• Consistency: How do we standardize namespaces, roles, and quotas?

• Efficiency: How do we avoid spinning up one cluster per team?

All of these problems point to one thing: the need for scalable, namespace-based multi-tenancy.

How Stakater MTO Scales Your IDP

Stakater MTO helps our platform teams provide secure, self-service, and governed Kubernetes environments for every team — all within a single shared cluster.

Tenant Provisioning with a CRD

Teams are onboarded declaratively using a Kubernetes Tenant custom resource:

apiVersion: tenantoperator.stakater.com/v1beta2
kind: Tenant
metadata:
  name: team-gamma
spec:
  owners:
    users:
      - gamma@example.com
  quota: large
  namespaces:
    withTenantPrefix:
      - dev
      - prod
  hibernation:
    sleepSchedule: "0 22 * * *"
    wakeSchedule: "0 7 * * *"

This single CR:

• Creates multiple isolated namespaces (e.g., team-gamma-dev)

• Applies predefined RBAC, quotas, and labels

• Assigns ownership and restricts access

• Enables hibernation during off-hours to save costs

Built-in Guardrails

MTO enforces:

• Pod Security Standards (via labels like restricted)

• RBAC templates per tenant

• ResourceQuotas and LimitRanges

• NetworkPolicies to isolate network traffic

We can also extend this with Gatekeeper/OPA for custom policy enforcement.

Key Features for Platform Teams

Capability	Benefit
Tenant CRD	Declarative onboarding of new teams in minutes
Hibernation schedules	Idle namespace shutdown to save cost
Templates & metadata	Consistent environment creation
GitOps-ready	Seamless integration with ArgoCD or Flux
Integrated console (UI)	Visual management of tenants and namespaces
Tool integrations	Logging, monitoring, backup, Vault, and more via hooks
FinOps-ready	Showback reports, cost labels, and capacity insights

Security and Compliance

MTO helps our platform teams align with ISO 27001 and SOC 2 controls by:

• Automating RBAC and access segregation

• Enforcing consistent policies across tenants

• Offering audit logs, namespace-level isolation, and scoped secrets

• Supporting integrations with Vault, Velero, Prometheus, and more

Real Outcomes for Platform Engineering Teams

With MTO, our platform teams can:

• Onboard 10x more teams with the same operational effort

• Standardize environments across dev, staging, and prod

• Reduce costs by consolidating clusters and hibernating environments

• Eliminate one-off scripts and manual onboarding tasks

• Provide a secure, compliant platform with developer self-service

Final Thoughts

Stakater MTO is the missing multi-tenancy layer for organizations scaling their internal developer platforms on Kubernetes. By combining strong isolation, automation, and integrations, it lets us build a secure, developer-friendly Kubernetes platform that scales as fast as our teams do.

Build once. Reuse safely. Scale infinitely — with Stakater MTO.