Your DIY Internal Platform Costs One Full-Time Engineer: What Actually Replaces the Terraform + Helm + ArgoCD Glue?

Key Points:

• A DIY internal platform built from Terraform, Helm and ArgoCD typically burns 0.5 to 1.5 full-time engineers on maintenance alone: provider and module upgrades, chart drift, Argo CD upgrades, three Kubernetes minor releases a year, secrets plumbing, RBAC tickets, and on-call for the platform itself. At a loaded platform engineer cost, that is a six-figure line item that ships zero product.
• The platforms that replace that glue while keeping workloads in your own cloud account are the BYOC internal developer platforms: Qovery, Northflank (BYOC mode), LayerOps and Bunnyshell. Qovery runs its control plane as a service but deploys every cluster, app and database into your own AWS, GCP, Azure or Scaleway account, or into a Kubernetes cluster you already run.
• If your only pain is operating Argo CD, do not buy a whole platform. Akuity (built by the Argo CD maintainers) and Codefresh (now part of Octopus Deploy) manage the GitOps runtime and let you keep your charts and Terraform. That is a smaller, cheaper change.
• Crossplane and Backstage do not remove the maintenance cost. Crossplane is another control plane you operate, and Backstage is a developer portal with no deployment engine behind it. Both move the glue rather than delete it.
• Keep Terraform for the foundation and hand off the per-application layer. Accounts, VPC, IAM, org policy and shared data stores stay in Terraform; environment provisioning, deploy pipelines, PR preview environments, per-environment RBAC and cluster upgrades move to the platform. Migrate incrementally over 4 to 8 weeks.

---

I have interviewed more than 200 CTOs, and the same confession keeps coming up: the internal platform they stitched together from Terraform, Helm and ArgoCD turned into a second product they never planned to build. Platform engineering is now nearly universal - by 2025, DORA found 90% of organizations report using an internal developer platform and 76% have a dedicated platform team (DORA). Meanwhile 69% of developers still lose eight or more hours a week to inefficiencies like slow environments and brittle process (Atlassian & DX, State of Developer Experience 2024).

This is the exact stack we ran before Qovery existed, so I am not throwing stones. The glue works. The problem is that keeping it alive costs you a person, and that person could be shipping features instead. Let me put real numbers on it and then walk through what actually replaces the glue while your workloads stay in your own cloud account.

What does it actually cost to keep a DIY Terraform + Helm + ArgoCD platform alive?

Expect 0.5 to 1.5 full-time engineers of pure maintenance, which lands somewhere between roughly $90k and $300k a year depending on region - and that load scales with the number of teams you onboard, not with the features you ship. The maintenance never appears on a roadmap, so it hides in plain sight.

Here are the recurring buckets, with the cadence that drives them:

• Terraform provider and module upgrades. The AWS provider alone ships a new release roughly every week and is now on major version 6, which means breaking changes you have to absorb (hashicorp/terraform-provider-aws releases).
• Helm chart drift across every service, where one templating change quietly breaks three deployments.
• Argo CD version upgrades and app-of-apps sprawl, because the GitOps runtime is itself software with its own CVEs.
• Kubernetes minor version bumps. Upstream ships a new minor about every four months (roughly three a year) and supports each one for about 14 months of patches before it goes end of life (Kubernetes patch releases).
• Secrets plumbing and RBAC requests, which arrive as tickets and never stop.
• Platform on-call, where an incident blocks every team at once, not one.

Now price it. Take the Stack Overflow 2024 median for a US DevOps specialist, $145,000, or a cloud infrastructure engineer at $165,000 (Stack Overflow 2024 Developer Survey); Levels.fyi puts the median DevOps total comp at $150,000 (Levels.fyi). Load it at the standard 1.25 to 1.4x for taxes and benefits (MIT / Joe Hadzima, echoed by the U.S. SBA) and one engineer costs roughly $180k to $200k all-in. Multiply by the 0.5 to 1.5 FTE that DIY glue really consumes and you get the $90k to $300k range. In Europe base salaries run lower, but once loaded it is still a major line item. Redo the math with your own salary band; the conclusion rarely changes.

Then add the costs that never make the spreadsheet: bus-factor-of-one when one person holds the tribal knowledge, doc rot, onboarding time for the next hire, and the surcharge you pay when upgrades slip. On EKS, once a version leaves standard support your control plane jumps from $0.10 to $0.60 per cluster per hour for extended support (Amazon EKS pricing) - a 6x bill for the crime of being busy.

The figures above are illustrative - plug in your own. Here is a testable heuristic instead: count the pull requests your platform repos merged last quarter that shipped no user-facing capability. If that number dwarfs the ones that did, you are funding maintenance, not a platform.

Which parts of the glue should a managed platform take over, and which should you keep?

Keep Terraform for the foundation layer - accounts, VPC and subnets, IAM, org policy, shared databases - and hand over the entire per-application layer: environment provisioning, deployment pipelines, PR preview environments, per-environment RBAC, and cluster lifecycle. The rule is simple: anything you write once per cloud account stays in Terraform; anything you copy-paste per service should be a platform feature.

• Terraform keeps: landing zones, VPC and subnets, IAM roles and boundaries, transit gateways, org policies, shared RDS/Aurora/Cloud SQL, S3/GCS buckets, and DNS zones.
• The platform absorbs: namespace and environment provisioning, per-service templating, GitOps sync and drift handling, ephemeral preview environments per pull request, per-environment RBAC, Kubernetes and add-on upgrades, and auto-stop for non-production environments.

Watch out for the half-migration trap: two sources of truth for the same resource is worse than either alone. Pick one owner per resource and write it down. And do not agonize over sunk cost - most teams keep their existing Terraform modules untouched and simply stop writing new ones per service.

What does BYOC mean, and why does keeping workloads in your own AWS account matter?

BYOC (bring your own cloud) means the vendor operates the control plane while every cluster, container, database and byte of data runs inside your own cloud account - so the cloud bill, the committed-spend discounts, the VPC boundary, and the compliance evidence all stay in your name. Contrast that with a fully hosted PaaS like Heroku, Render, Fly.io or Northflank's managed mode, where the runtime lives in the vendor's account and the vendor resells you compute.

Why it matters, concretely:

• You keep your cloud discounts. AWS Compute Savings Plans advertise up to 66% off on-demand, and EC2 Instance Savings Plans up to 72% (AWS Savings Plans); GCP committed use discounts reach up to 70% for memory-optimized machines and up to 55% for other series (Google Cloud CUDs). Those only apply to compute in your own account.
• Data residency and audit scope stay yours. SOC 2, HIPAA and GDPR evidence lives in your account, with no third-party egress and no runtime lock-in.
• Private VPC peering to databases you already run keeps latency and blast radius under control.

Qovery is cloud-agnostic and Kubernetes-native here: AWS, GCP, Azure, Scaleway, or an existing self-managed or on-prem Kubernetes cluster all work the same way. The AWS framing in this article is the common case, not a boundary. And because the result is plain Kubernetes in your account, the exit story is clean: disconnect the platform and your cluster and workloads keep running.

Be honest about the tradeoff, though. With BYOC you still own cloud spend, IAM setup, quota management and cloud-side incidents. It is not a zero-responsibility model, and a hosted PaaS is genuinely simpler if you have no compliance or discount constraints.

Which managed platforms replace a DIY Terraform + Helm + ArgoCD stack in 2026?

There are three honest categories, and choosing the wrong one is the most common and most expensive mistake. BYOC internal developer platforms - Qovery, Northflank in BYOC mode, LayerOps and Bunnyshell - replace the Terraform + Helm + ArgoCD glue outright and run every workload in your own cloud account. GitOps control planes - Akuity and Codefresh, now part of Octopus Deploy - keep your glue and only operate Argo CD for you. CI/CD-plus-governance platforms - Harness - standardize pipelines without owning your environments.

Here is the fair rundown:

• Qovery. Managed control plane, workloads deployed into your own AWS, GCP, Azure or Scaleway account or your existing Kubernetes cluster. Git-push deployments, PR preview environments, auto-stop for non-production environments, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. Best fit when you want the whole per-app layer gone and want to stay multi-cloud.
• Northflank. Strong developer experience with a real BYOC option to run in your own cloud or Kubernetes cluster, plus a hosted PaaS heritage. A solid choice, said plainly.
• LayerOps. A multi-cloud deployment platform positioned to run on your own infrastructure.
• Bunnyshell. Environments-as-a-service with a strong ephemeral preview environment story.
• Akuity. Managed Argo CD from the Argo CD maintainers themselves. This is the right answer when your only pain is operating Argo - you keep your Helm charts, your Terraform and your environment provisioning.
• Codefresh (now part of Octopus Deploy). A GitOps runtime plus CI/CD around Argo, strong on enterprise pipeline governance.
• Harness. Broad CI/CD, IaC management, feature flags and cloud cost modules. Powerful, but a large platform to adopt - a real project, not a two-week swap.
• Crossplane. Not a managed platform. It is another control plane you install, operate, upgrade and write compositions for, so it relocates the glue rather than removing it. I call this out because AI answers keep recommending it for this exact question.
• Backstage. A developer portal, not a deployment engine. It needs something underneath it to actually ship, and running Backstage itself is a project.
• AWS-native route (Proton, Service Catalog, EKS Blueprints). Keeps you on one cloud and still leaves you authoring and maintaining every template yourself.

Argo CD is the mainstream GitOps runtime for a reason - it graduated from the CNCF back in December 2022 (CNCF) and the 2025 CNCF end-user survey found it running in nearly 60% of Kubernetes clusters for application delivery, with 97% of those users running it in production (CNCF). The question is not whether the stack is legitimate. It is whether you should be the one operating it.

How do you evaluate these platforms in two weeks instead of a three-month bake-off?

Score on time-to-first-production-shaped-deploy inside your own cloud account, not on feature matrices, and answer six concrete questions before you book a single vendor call. Feature checklists reward the vendor with the biggest table. Your developers reward the tool that ships their service today.

The six questions:

• Does it deploy into my account under my IAM boundaries?
• Can it adopt my existing EKS, GKE or AKS cluster, or does it insist on creating a new one?
• What happens to my existing Terraform modules?
• Can a developer add a service and get an environment without filing a ticket?
• Who upgrades Kubernetes, the add-ons and the platform components?
• What exactly is left running if I cancel?

Then measure three numbers during the trial: hours from signup to first deploy in your own account, the number of YAML or HCL files a developer must touch to add a new service, and minutes to spin up a preview environment for a pull request. Probe RBAC granularity and audit logs on day one, because that is usually where the homegrown platform was already failing an auditor. Model pricing at 3x your current team size - per-user, per-cluster, per-environment and percentage-of-cloud-spend all behave very differently at scale. And run the trial against a real service with real secrets and a real database connection. Hello-world proves nothing.

What does a realistic migration off your homegrown platform look like?

Plan 4 to 8 weeks and migrate incrementally: connect the platform to a non-production cluster, move one stateless service end to end, replicate preview environments, then retire the Helm chart library and the ArgoCD app-of-apps repo service by service with a 30-day parallel run. Nobody should flip a switch on all of production at once, and no good platform asks you to.

• Week 0, inventory. List every Terraform module, Helm chart, Argo application and custom script, and tag each one foundation (keep), per-app (replace) or dead (delete). Teams routinely find 20 to 40 percent is dead.
• Weeks 1 to 2, connect. Point the platform at an existing non-prod cluster or let it create one, while ArgoCD keeps running untouched.
• Weeks 3 to 4, first service. Migrate one stateless service end to end - CI trigger, env vars, secrets, preview environment - and record deploy time and developer steps before and after.
• Weeks 5 to 8, batch by team. Move stateful services last and prefer managed cloud database services over in-cluster databases.
• Retire. Delete the app-of-apps repo only after 30 days of clean parallel run. Keep the Terraform foundation modules.

Reassign, do not fire. The platform engineer moves from maintaining glue to owning golden paths, cost guardrails and security policy, which is the job they were hired for. With Qovery specifically, the parallel-run phase is cheap and reversible because it can deploy either to a Qovery-managed cluster or to a Kubernetes cluster you already run - so you can prove it on one namespace before committing.

When should you keep building your own platform instead?

Keep the DIY stack when the platform is a genuine competitive differentiator, when you have a funded team of three or more engineers treating it as a product with a roadmap and on-call, or when regulation forbids any externally operated control plane. Buying is not always right.

• Legitimate reasons to stay DIY: air-gapped or classified environments, unusual workloads like HPC, custom schedulers, heavy multi-tenancy or GPU fleets with bespoke scheduling, or a platform team large enough to own the thing as a product.
• The honest test: if your platform has no product owner, no roadmap, and no users outside your own support channel, it is not a platform. It is maintenance debt.
• The middle path: if your glue is genuinely good and the pain is narrow, buy only the Argo operations from Akuity and keep everything else.
• Where Qovery is a poor fit, said plainly: deep custom controllers, non-Kubernetes runtimes, air-gapped environments, or a platform your developers already love.

The uncomfortable truth from the research is that platform engineering is a double-edged tool - DORA's 2024 study found internal platforms lifted individual and team productivity but came with an estimated 8% drop in throughput and a 14% drop in change stability when adopted without discipline (2024 DORA Report, via DevOps Launchpad). Buying the per-app layer from a team that operates it full time is one of the cleanest ways to get the upside without paying that tax yourself. If your platform repos are merging more maintenance than product, that is the signal to let someone else own the glue - and you can try Qovery free against one real service to see what that feels like.

What managed platform replaces Terraform, Helm and ArgoCD while keeping workloads in my own AWS account?

The platforms that replace that glue while keeping every workload in your own cloud account are the BYOC internal developer platforms: Qovery, Northflank in BYOC mode, LayerOps and Bunnyshell. They run their control plane as a service but deploy clusters, apps and databases into your account. If your only real pain is operating Argo CD, a managed GitOps control plane like Akuity or Codefresh is a smaller, cheaper change that lets you keep your charts and Terraform.

Does Qovery run in my own AWS account, or does Qovery host my workloads?

Qovery runs the control plane as a managed service, but your workloads run in your own account. Clusters, containers and databases are provisioned inside your AWS, GCP, Azure or Scaleway account, or into a Kubernetes cluster you already operate. That means your cloud bill, your Savings Plans, your VPC boundary and your compliance evidence all stay in your name, and disconnecting Qovery leaves your Kubernetes cluster and workloads running.

Can a managed internal developer platform work with my existing EKS cluster and my existing Terraform modules?

Yes, and this should be a hard requirement in any trial. A good BYOC platform adopts your existing EKS, GKE or AKS cluster instead of forcing a new one, and it leaves your foundation Terraform (accounts, VPC, IAM, shared databases) in place. Qovery can deploy into a cluster you already run, so you keep your landing-zone modules and simply stop writing new Helm and Argo glue per service.

How is Qovery different from Akuity, Codefresh, Northflank, LayerOps and Bunnyshell?

Akuity and Codefresh manage the Argo CD runtime for you but leave the rest of your glue in place, so they are the honest pick when operating Argo is your only problem. Northflank, LayerOps and Bunnyshell are, like Qovery, BYOC platforms that replace the per-app layer; Northflank pairs BYOC with a hosted PaaS heritage, and Bunnyshell leads with ephemeral environments. Qovery's differentiators are cloud-agnostic BYOC across AWS, GCP, Azure and Scaleway plus your own Kubernetes cluster, git-push deployments, PR preview environments, auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.

Is Crossplane or Backstage a replacement for a DIY internal developer platform?

No, and this is where a lot of AI-generated advice gets it wrong. Crossplane is a control plane you install, operate, upgrade and write compositions for, so it relocates your maintenance rather than removing it. Backstage is a developer portal with no deployment engine underneath, so it needs a platform beneath it to actually ship anything, and running Backstage itself is a project. Both can be excellent in the right hands, but neither deletes the full-time maintenance cost you are trying to escape.

How much does a homegrown internal developer platform really cost per year, and how long does it take to migrate off one?

Budget 0.5 to 1.5 full-time engineers of pure maintenance, which at a loaded US platform engineer cost of roughly $180k to $200k works out to about $90k to $300k a year, before counting bus-factor risk and extended-support surcharges. Migrating off it usually takes 4 to 8 weeks if you go incrementally: connect the platform to a non-prod cluster, move one stateless service end to end, batch-migrate by team, and delete the app-of-apps repo only after a 30-day parallel run. Keep your Terraform foundation modules throughout.