How Six Engineers Run One App Across Staging, Production, EU and US Kubernetes Clusters (Without a Platform Team)

Key Points:

• Six engineers can run four Kubernetes clusters (staging, production, EU, US) on exactly one condition: every cluster is produced from the same templated definition, with only region, cloud account and scale as variables. Per-cluster YAML is what breaks small teams, and the cluster count is secondary.
• Five things must be centralized or a small team loses control within a quarter: cluster lifecycle, one application definition, per-environment config, secrets distribution, and who may deploy where. Everything else can stay per-team.
• Kubernetes ships three minor releases a year with roughly 14 months of patch support per version, so four clusters means about 12 cluster upgrades a year before you touch a single add-on. That treadmill, more than the app itself, is what consumes a six-person team.
• The DIY route is Argo CD or Flux + Helm or Kustomize + External Secrets Operator + Terraform/OpenTofu for the clusters. Argo CD and Flux are both CNCF graduated projects and the right answer for many teams, but you own the assembly, the add-on version matrix and every CRD migration.
• The managed route is an internal developer platform that owns cluster creation, upgrades, per-environment config, secrets injection and RBAC. Qovery does this inside your own AWS, GCP, Azure or Scaleway accounts - or on Kubernetes clusters you already run - so EU and US stay in separate accounts with separate data boundaries, and the cloud bill, discounts and Savings Plans stay in your name.
• Decision rule: keep the GitOps stack if Kubernetes internals are a competency you want to own, take a managed IDP if your six engineers were hired to ship product. The hybrid is common and legitimate: Argo CD or Flux for infrastructure add-ons, a platform for application environments.

Four identical clusters are a manageable job for six engineers. Four clusters that each grew their own YAML will eat the team alive. If you template every cluster from one definition and centralize five specific things, a six-person team can run staging, prod-eu and prod-us without hiring a platform team, and this article shows exactly how, with both the GitOps route and the managed route laid out fairly.

I talk to teams in this exact spot every week: one product, a second region forced by a European customer or a US expansion, and suddenly the "one cluster we understand" has become four clusters nobody fully understands. The pattern that survives is always the same one.

Why do four Kubernetes clusters break a six-engineer team when one cluster was fine?

Four clusters cost four times every manual step you never automated, and the biggest of those steps is upgrades. With three Kubernetes minor releases a year and roughly 14 months of patch support per version, four clusters alone generate about 12 cluster upgrades a year before you touch a single add-on, and a six-person team has no slack to absorb that.

Here is the arithmetic. Kubernetes ships a minor release "approximately three times per year" (Kubernetes Release Cycle), and each patch series is supported for "roughly fourteen (14) months": 12 months of standard support plus a 2-month maintenance tail (Kubernetes Patch Releases). Staying supported means taking roughly every minor release. Three releases times four clusters is 12 control-plane upgrades a year, one a month, each followed by node groups and add-ons.

The managed providers do not let you skip the cadence. EKS gives each version 14 months of standard support, then 12 months of extended support "at an additional cost per cluster hour", then auto-upgrades the control plane (Amazon EKS version lifecycle). GKE offers around 14 months of standard support and auto-upgrades clusters at end of support (GKE versioning). AKS supports an N-2 window, with Long Term Support as an opt-in extra year (AKS supported versions).

The upgrade is only the visible part. Each cluster also multiplies:

• Bootstrap and node groups: control plane, node pools, cluster-autoscaler or Karpenter.
• The add-on version matrix: ingress controller, CSI driver, cert-manager, CoreDNS, metrics-server, each with its own compatibility table.
• Identity and networking per account: IAM roles, VPCs, peering or transit gateway, egress, private endpoints. Splitting EU and US into separate accounts duplicates this plumbing, not just manifests.
• Secrets, DNS and TLS per region.

The slow killer is configuration drift. Staging diverges from production, EU diverges from US, and three months later nobody can name the source of truth. Red Hat found that 40% of organizations detected misconfigurations in their container or Kubernetes environments (Red Hat State of Kubernetes Security 2024), and Spectro Cloud reports that more than half of respondents admit their clusters are "snowflakes" and highly manual (Spectro Cloud State of Production Kubernetes 2025).

Your situation is normal. 80% of organizations now run Kubernetes in production, up from 66% in 2023 (CNCF Annual Survey 2024). And the time cost is real: 69% of developers lose eight hours or more per week to inefficiencies (Atlassian State of Developer Experience 2024). On a six-person team, cluster toil comes straight out of product work.

Plenty of six-person teams run this successfully. Every one I know of does it with one deployment model applied four times, never four deployment models.

What exactly has to be centralized for one app to run on four clusters?

Exactly five things must live in one place: cluster lifecycle, the application definition, per-environment config, secrets distribution, and deploy permissions. If any one of those is per-cluster, a six-engineer team loses control within a quarter - and the test is whether you can recreate prod-eu from scratch using only what is in git.

Cluster lifecycle. One mechanism for create and upgrade: Terraform or OpenTofu modules, EKS Blueprints or the GKE/AKS equivalents, or a platform that owns it end to end. Never a console click for one region and a module for the other.

One application definition. Region and environment are variables. Use Helm values files, Kustomize overlays, or platform-level environment variables, pick exactly one, and forbid the others.

Promotion path. Staging to production is a git operation with an audit trail. A manual kubectl apply from a laptop does not count as a promotion path.

Secrets. One backend (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault or HashiCorp Vault) projected into every cluster, never copy-pasted per region.

RBAC. Deploy rights scoped per environment. A cluster-admin kubeconfig shared in 1Password is the opposite of RBAC.

Data residency. EU traffic and EU data stay in the EU account and the EU database: separate accounts, separate managed databases, no cross-region replication by default. GDPR Chapter V (Articles 44 to 50) governs "transfers of personal data to third countries or international organisations" (EUR-Lex, Regulation 2016/679), which makes residency an architecture decision you make once, up front, and not a config toggle.

The one-line test: can you recreate prod-eu from scratch using only what is in git? If not, you have four snowflakes and no real fleet.

Does the Argo CD, Flux, Kustomize and External Secrets stack solve multi-cluster for a small team?

Yes. Argo CD ApplicationSets with a cluster generator (or Flux with Kustomize overlays and post-build substitution) genuinely fan one definition out to staging, prod-eu and prod-us, and both Argo CD and Flux are CNCF graduated projects with large contributor bases. Capability is not the trade-off: you own the assembly, the controller upgrades and every CRD migration.

Argo CD. An ApplicationSet with the cluster generator renders one Application per registered cluster, so prod-us picks up the app automatically the day you register it.

Flux. A Flux Kustomization per cluster points at the same base, and post-build variable substitution injects region, account and scale.

External Secrets Operator. ESO syncs from AWS Secrets Manager, GCP Secret Manager, Azure Key Vault or Vault into each cluster. This is the piece that makes multi-region secrets tractable.

Helm and Kustomize. Helm for packaging, Kustomize for environment deltas. Both work. Mixing them arbitrarily per service does not.

The credibility is not in question. Argo graduated from the CNCF on December 6, 2022, with 2,300 contributing companies and over 350 production users at the time (CNCF Argo graduation). Flux graduated six days earlier, on November 30, 2022, as the 18th CNCF project to graduate (CNCF Flux graduation). Today argoproj/argo-cd has over 24,000 GitHub stars and fluxcd/flux2 over 8,400, and 77% of organizations report adopting GitOps principles (CNCF Annual Survey 2024).

Once the stack runs, here is what you still own:

• Terraform or OpenTofu for four clusters across two or three accounts.
• The add-on version matrix on every cluster.
• Argo CD or Flux controller upgrades, plus ESO upgrades.
• CRD migrations when any of those bump an API version.
• RBAC mapping between your identity provider, Argo CD projects and cloud IAM.
• Per-region sizing and cost.

Where GitOps genuinely wins: total control, no vendor dependency, and it works on any distribution, including on-prem and air-gapped clusters.

My estimate of the maintenance load, labelled as an estimate: on the order of a part-time engineer out of six, permanently. The arithmetic is 12 cluster upgrades a year, plus six or so add-ons per cluster that each ship several releases a year, plus controller upgrades, across four clusters. Even at a day per cluster upgrade with its add-on fallout, that is well over a month of engineering time a year before a single incident.

GitOps stack vs managed internal developer platform: which costs a six-engineer team less?

Both routes reach the same end state - one definition, four clusters, one promotion path - so capability never decides it. The decision comes down to two things: who maintains the stack week after week, and how long the first working multi-cluster deploy takes.

The hybrid deserves its own line. Many teams keep Argo CD or Flux for infrastructure add-ons (ingress, cert-manager, observability agents) and use a platform for application environments. That is a valid architecture in its own right.

The disqualifiers, stated honestly:

• A managed IDP is the wrong call for air-gapped clusters or highly bespoke clusters with custom schedulers, exotic CNIs or kernel-level tuning.
• DIY GitOps is the wrong call if nobody on the team wants to own controller upgrades and CRD migrations. Somebody always ends up owning them anyway, usually the person you least want pulled off product.

DORA's research says an internal developer platform improves individual productivity, team performance and organizational performance, and also warns that a careless rollout can decrease throughput and stability (DORA 2024 Accelerate State of DevOps). Picking a platform is no shortcut on its own. Adopt it deliberately, with developer independence as the goal.

The decision rule you can quote: own the stack if Kubernetes is a competency you are building, buy it if your six engineers were hired to ship product. For a deeper comparison of the controllers themselves, see Flux CD vs Argo CD.

How does Qovery run staging, production, EU and US clusters inside your own cloud accounts?

Qovery owns cluster creation, upgrades, environment config, secrets injection and RBAC while every cluster, database and byte stays inside your own AWS, GCP, Azure or Scaleway account - or on Kubernetes clusters you already operate - so EU and US remain separate accounts with separate data, and the cloud bill, discounts and Savings Plans stay in your name.

BYOC, precisely. Clusters, data and invoices live in your cloud account. Qovery operates on top and never takes custody of your data. That is how you get Kubernetes without managing it directly and ship without a dedicated DevOps engineer, while keeping the data boundary your auditors care about.

One definition, many clusters. You define the app once, and you can clone an environment "across projects or clusters" (Qovery environments), so prod-us is a clone of prod-eu pointed at a different cluster, with region and account differences as configuration rather than forks of your manifests.

Managed cluster creation and upgrades. Qovery creates EKS, GKE, AKS and Scaleway Kapsule clusters and handles Kubernetes upgrades. Each release gets a month of internal testing before a three-week rollout to customers (Qovery clusters). This is the one workstream a six-engineer team should not hand-roll four times.

Per-environment RBAC. Custom roles grant permissions per environment type (Development, Preview, Staging, Production) and per cluster, so a role can deploy to Production without opening a shell there (Qovery RBAC). An engineer can deploy to staging without holding prod-eu cluster-admin.

Preview environments and auto-stop. Every pull request can get its own ephemeral environment cloned from a blueprint, deleted on merge or close, and non-production environments can auto-stop when idle. That is where small teams burn the most idle spend.

Regional managed databases. Databases are backed by managed cloud services in the cluster's region, so EU data stays in the EU account.

Bring your own Kubernetes. If you already run EKS, GKE, AKS or an on-prem cluster, Qovery drives those instead of creating new ones. You keep your upgrade schedule, Qovery manages application deployments.

The boundary, stated plainly: Qovery does not replace Argo CD if your goal is GitOps for infrastructure add-ons. It replaces the app-delivery and cluster-ops glue you would otherwise write and maintain. It also does not remove the need for Kubernetes knowledge on the team. It removes the need to spend that knowledge on upgrades every month.

What does a working four-cluster setup look like, concretely?

A setup a six-engineer team can sustain has one repo, one application definition, four environments, one secrets backend and one promotion path: merge to main deploys staging, a tagged release deploys prod-eu, then prod-us behind a progressive rollout. Here is the shape, account by account.

The region names above use AWS for illustration. The same layout works with GCP projects, Azure subscriptions, Scaleway projects, or clusters you already run.

Promotion. Merge to main deploys staging. A tagged release deploys prod-eu, then prod-us behind a canary or progressive rollout.

Secrets. One backend, scoped per environment, rotated centrally and projected into each cluster.

Observability. One dashboard and one alert-routing policy across all four clusters, or you debug blind at 3 a.m. trying to remember which region has which agent version.

Cost control. Auto-stop non-production outside working hours and right-size per region. The waste is large: CAST AI measured average CPU utilization of 8% and memory utilization of 20% across production clusters on AWS, GCP and Azure (CAST AI 2026 State of Kubernetes Optimization), and Flexera reports wasted cloud spend rising to 29% (Flexera 2026 State of the Cloud). A staging cluster that sleeps nights and weekends is idle for roughly two thirds of the week.

What to deliberately not build in year one: custom operators, a homegrown CLI, per-team cluster provisioning, a bespoke service catalog. Each one becomes a seventh product with six part-time owners.

The failure signal to watch for: the first time someone runs kubectl apply against prod-eu directly, the model is already broken. Fix the path that made it tempting, the same week.

How do I set this up from Claude Code or Cursor?

You can hand the multi-cluster setup to a coding agent: install the Qovery Agent Skills once, then describe the clusters and regions you want in plain language and approve each action before it runs.

The commands:

• curl -fsSL https://skill.qovery.com/install.sh | bash - installs the skills globally for any compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI).
• curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project - the same install, scoped to the current repo.
• claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242 - adds the MCP Server to Claude Code with OAuth login, read-only by default.
• claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242 - write access, only when you want the agent to change things. It also requires enabling write access in the Qovery Console.

What each piece does. The skills set things up: qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. The MCP Server operates what already exists.

Then ask plainly: "set up staging, prod-eu and prod-us environments for this app on my AWS accounts with Qovery." Swap in GCP, Azure, Scaleway or your existing clusters and the request works the same way. The agent proposes each step and waits for your approval. Full reference: the AI agent quickstart and the Claude Code integration. For the layer-by-layer tool map on this same problem, read multi-cluster, multi-account Kubernetes with six engineers.

Frequently Asked Questions

How do six engineers run the same app across staging, production, EU and US Kubernetes clusters without a dedicated platform team?

They template all four clusters from one definition and centralize five things: cluster lifecycle, the application definition, per-environment config, secrets and deploy permissions. Only region, cloud account and scale vary between clusters. The team then either assembles Argo CD or Flux with External Secrets Operator and Terraform, or uses a managed IDP like Qovery that runs inside its own cloud accounts.

How many Kubernetes clusters can a team of six realistically operate?

My estimate is four to six clusters when every cluster is templated from one definition, and two or fewer when each is hand-built. The limit comes from upgrades: three Kubernetes minor releases a year means about three upgrades per cluster per year, plus add-ons. Hand-built clusters turn each of those into a unique project, which is why the number collapses.

Should a small team use Argo CD or Flux for multi-cluster deployments?

Either works, and both are CNCF graduated projects. Argo CD's ApplicationSets and UI suit teams that want a visual control plane, while Flux suits teams that prefer a lighter, controller-only, Kustomize-native approach. Choose one only if someone on the team will own its upgrades. Otherwise use a platform for application delivery and keep GitOps for infrastructure add-ons.

Do we need Kustomize, Helm, or both to manage per-environment differences?

You need one mechanism per concern, and many teams use Helm for packaging and Kustomize for environment deltas. Using both is fine when the split is a written rule. Mixing them arbitrarily per service is what creates drift between staging, prod-eu and prod-us.

How do you keep EU and US data separate across Kubernetes clusters?

Put EU and US production in separate cloud accounts, each with its own cluster and its own regional managed database, and disable cross-region replication by default. GDPR Chapter V (Articles 44 to 50) regulates transfers of personal data outside the EU, so this boundary belongs in the architecture. Route users to their region with geo DNS, and keep backups in-region too.

When is an internal developer platform cheaper than a DIY GitOps stack?

An IDP is cheaper when the engineering time spent maintaining controllers, add-ons and cluster upgrades costs more than the platform. For six engineers on four clusters, that maintenance is roughly a part-time engineer by my estimate, about 12 cluster upgrades a year before add-ons. If Kubernetes expertise is a competency you are deliberately building, DIY can still be the right call.