Multi-Environment Kubernetes Setup (Dev/Stage/Prod): What a DevOps Engineer Delivers in 2026

As a DevOps Engineer at Acquaint Softtech, a software development partner, one of the most common configuration gaps I find in new Kubernetes engagements is inadequate environment separation. Teams have a dev namespace and a production namespace in the same cluster, sharing compute and networking. A misconfigured dev service that hammers the API server affects production response times. A developer testing with high resource requests starves production pods. True multi-environment Kubernetes is not two namespaces. It is a deliberate architecture with the right isolation, the right configuration management, and the right promotion workflow between environments. This guide covers what a DevOps engineer builds for a production-grade multi-environment setup.

---

The cheapest multi-environment Kubernetes setup is three namespaces in one cluster. The problem with this approach is that namespace isolation in Kubernetes do not prevent resource contention at the node level. A development namespace running load tests can consume node CPU and memory that production pods need. Network policy misconfiguration can allow dev traffic to reach production services. A single cluster control plane failure takes all three environments down simultaneously.

For the Helm-based deployment automation that makes multi-environment promotion manageable, the Helm charts and Kubernetes automation guide covers values files per environment and ArgoCD-based promotion workflows. This article focuses on the cluster architecture and isolation decisions.

Multi-Environment Architecture: 3 Options and When to Use Each

A DevOps engineer evaluates three architecture options for multi-environment Kubernetes. The right choice depends on the team's scale, compliance requirements, and cost tolerance.

Option 1: Namespaces in a Single Cluster (Minimum Viable)

Architecture: dev, staging, and prod namespaces in the same EKS or AKS cluster. Resource quotas on each namespace. Network policies isolating namespace traffic.

Right for: very early-stage teams with low traffic, limited budget, and a single dev team. The simplest setup to operate.

Problems at scale: resource contention at the node level is not prevented by namespaces. A node shared between dev and prod can have dev pods starve prod pods of memory. Control plane failure affects all environments simultaneously.

Cost: one cluster's AWS/Azure infrastructure cost. Lowest cost option.

Option 2: Separate Node Pools per Environment (Recommended for Most SaaS)

Architecture: a single cluster with separate managed node groups for each environment. Dev and staging run on smaller Spot Instance node pools. Production runs on dedicated on-demand node pools.

Right for: most SaaS startups and growing companies. Strong resource isolation without the operational overhead of multiple clusters. One control plane to manage and upgrade.

Isolation: node-level resource isolation via node groups. Pod affinity rules ensure dev pods never schedule on production nodes.

Cost: slightly higher than single node pool because dedicated production nodes cannot be shared.

Option 3: Separate Clusters per Environment (Maximum Isolation)

Architecture: three separate EKS or AKS clusters (dev, staging, production). Each cluster has its own control plane, network, and node groups.

Right for: teams with compliance requirements that mandate production cluster isolation (SOC 2, ISO 27001, PCI-DSS), large engineering organisations where a staging cluster failure should not risk production availability, and platforms where staging runs load tests that could destabilise a shared control plane.

Cost: three clusters means three sets of control plane costs (3x EKS $73/month) and separate VPC, NAT Gateway, and monitoring costs per cluster. Higher cost but maximum isolation.

For the Terraform code that defines each environment's cluster configuration, the Terraform infrastructure automation guide covers how Terraform workspaces or directory-per-environment structures manage multi-cluster infrastructure as code.

What a DevOps Engineer Configures for Each Environment Layer

Regardless of which architecture option is chosen, each environment need a consistent configuration layer. Here is what a DevOps engineer sets up for each of the three environments.

Configuration layer	Dev environment	Staging environment	Production environment
Node size	Smaller instances (t3.medium), Spot VMs	Medium instances (t3.large), mix of Spot/on-demand	Standard instances (m5.large), on-demand primary
Replica count	1 per service	2 per service (HA testing)	3+ per service (actual HA)
Resource requests/limits	Small (50m CPU, 128Mi memory)	Medium (200m CPU, 512Mi memory)	Standard (500m CPU, 1Gi memory)
Auto-scaling	Disabled or minimal	HPA enabled, conservative thresholds	HPA + Cluster Autoscaler, production thresholds
External access	Internal only or dev-team VPN	Staging subdomain, basic auth or IP allowlist	Production domain, full DNS, TLS certificate
Secret management	Dev secrets in Kubernetes Secrets	Staging secrets in Vault or AWS Secrets Manager	Production secrets in Vault or AWS Secrets Manager
Monitoring	Basic metrics, no alerting	Full metrics, team Slack alerts	Full metrics, on-call PagerDuty alerts, SLO tracking
ArgoCD sync policy	Auto-sync on every commit	Auto-sync after staging validation gate	Manual sync (PR review required for production)

The Promotion Workflow: How Code Moves from Dev to Production

The promotion workflow define how a code change moves from a developer's branch through staging and into production. A DevOps engineer builds the promotion logic to match the team's release cadence.

Dev environment (continuous)	Every commit to a feature branch or dev branch is automatically deployed to the dev environment by ArgoCD. Dev deployment is fast and disposable: failed dev deployments are expected and not alerted. The dev environment is for developer testing, not for stakeholder review.
Staging environment (on-demand or scheduled)	Staging deployment is triggered either by merging a PR to the staging branch or by a scheduled nightly build. Staging closely resembles production (similar replica counts, similar resources) so integration tests and stakeholder review are meaningful. A staging deployment that passes all integration tests and health checks is a candidate for production promotion.
Production environment (controlled)	Production deployment requires a manual approval step in the CI/CD pipeline or a reviewed PR to the production values file in Git. With ArgoCD, the promotion is a Git operation: update the image tag in the production values file, open a PR, get a review from a second engineer, merge. ArgoCD deploys to production within minutes of merge. The full audit trail is in Git.

For the EKS cluster setup that underlies this multi-environment architecture, the AWS EKS setup and management guide covers the node group and networking configuration that enables the separate-node-pool architecture described above.

What It Costs in 2026

The multi-environment setup cost has two components: the DevOps engineer time to build and configure the environments, and the ongoing AWS or Azure infrastructure cost. Here are the honest 2026 numbers.

AWS infrastructure cost for each architecture option (monthly estimate)

Option 1 (namespaces in single cluster):

• 1x EKS cluster: $73 + nodes shared across envs + single VPC/NAT

• Typical: $200 to $300/month total

Option 2 (separate node pools in single cluster):

• 1x EKS cluster: $73 + dev/staging Spot nodes + prod on-demand nodes

• Typical: $300 to $450/month total

Option 3 (separate clusters per environment):

• 3x EKS cluster: $219 + 3x VPC/NAT/monitoring overhead

• Typical: $900 to $1,300/month total

DevOps engineer setup cost at $22/hour:

• Option 1 (namespace isolation + resource quotas + network policies): 4-6 days = $704 to $1,056

• Option 2 (separate node pools + Terraform per env + promotion workflow): 6-10 days = $1,056 to $1,760

• Option 3 (3 separate clusters + GitOps promotion): 10-16 days = $1,760 to $2,816

Monthly retainer (multi-env management): $3,200/month

Acquaint Softtech's hire DevOps engineers service provides pre-vetted engineers with multi-environment Kubernetes experience. Every engineer has configured environment promotion workflows and values-file-based environment management. Starting at $22/hour or $3,200/month.

For the full rate comparison by region and seniority, the DevOps engineer cost guide covers what each price tier delivers.

Individual DevOps engineer on a monthly retainer through our staff augmentation model. Starting at $22/hour or $3,200/month. Available in 48 hours.

For teams building cloud infrastructure from scratch alongside the Kubernetes setup, Acquaint Softtech's software product development service covers the full product team structure including DevOps.

Frequently Asked Questions