The best GitOps CI/CD setup for a 5-person team on Kubernetes with no platform engineer (2026)

Key points:

• The best GitOps CI/CD setup for a 5-person team with no platform engineer is GitHub Actions or GitLab CI for build and test, plus a managed Kubernetes platform running in your own cloud account (AWS, GCP, Azure, Scaleway, or your existing cluster) that owns upgrades, ingress, TLS, autoscaling and a preview environment per pull request.
• Argo CD and Flux CD are both CNCF-graduated, free to licence and excellent at what they do, and neither provisions a cluster, upgrades it, runs your ingress controller, rotates TLS certificates or creates preview environments. Pick them only if one of your five engineers genuinely wants to own that work.
• Argo CD vs Flux CD in one sentence: Argo CD if you want a dashboard any engineer can read plus the ApplicationSet pull request generator, Flux CD if you want the smallest set of controllers reconciling git with built-in image automation. The cluster maintenance burden is identical either way.
• Preview environments per pull request need six parts, not one: namespace per PR, DNS record, wildcard TLS certificate, seeded database, injected secrets, and reliable teardown. Argo CD's ApplicationSet PR generator covers the first part; managed platforms cover all six.
• Licence cost is the wrong comparison. Argo CD and Flux CD cost $0 in licence and 20 to 30 percent of an engineer's month in upkeep; at median platform-engineer compensation that is the single largest line item in the whole setup.
• Skip Kubernetes entirely with Heroku, Render or Fly.io only if you do not need workloads in your own cloud account. Running in your own account keeps data residency, VPC peering, and AWS Savings Plans or GCP committed-use discounts in your own name.

Small teams always ask me the same question: "Argo CD or Flux CD?" That is the wrong question. Both tools are free. The cluster underneath them is not. I have interviewed more than 200 CTOs and run Kubernetes in production for over 15 years, and at five engineers the thing that breaks is never a missing GitOps feature. It is a cluster nobody upgraded sitting in production six months later.

This is a buyer's guide for that exact team: five engineers, Kubernetes in your future or your present, and no one whose job title is "platform engineer." I build Qovery, so I will tell you outright where Argo CD, Flux CD, GitHub Actions, GitLab CI, Northflank, Porter or Devtron is the better pick, and I will keep Qovery out of the conversation until it is the honest answer.

What is the best GitOps CI/CD setup for a 5-person team with no platform engineer?

The best setup is GitHub Actions or GitLab CI for build and test, a managed Kubernetes platform running inside your own cloud account for deploy and operate, and an ephemeral preview environment on every pull request. Self-run Argo CD or Flux CD is the right answer only when one of your five engineers wants cluster upgrades, ingress, certificates and add-ons as a real part of their job description. Everything below deepens one part of that verdict.

One condition flips the answer: if a compliance mandate requires declarative desired state in git for audit, or if one engineer actively enjoys platform work, run a GitOps controller yourself and keep the money.

A 5-person team actually needs four things, and only four: git-push deploys, a preview environment per pull request, one-step rollback, and a cluster that upgrades without anyone remembering to do it. Notice that three of those four have nothing to do with GitOps controllers and everything to do with the platform underneath.

Here is what "good" looks like, measured, at this team size: first production deploy in under a day, a preview environment per pull request live in under 10 minutes, rollback in one revert or one click, and zero pages about the control plane. If your setup cannot hit those numbers, it is too heavy for five people.

This is a mainstream problem, not an edge case. In the CNCF 2025 Annual Survey, 82 percent of container users said they run Kubernetes in production, up from 66 percent in 2023. Kubernetes is the default target. The open question for a small team is who keeps it alive.

What does GitOps actually mean, and which part of the job does it not cover?

GitOps means git holds the desired state of your system and a controller continuously reconciles the cluster to match it. Argo CD and Flux CD are the two CNCF-graduated reference implementations, and both cover exactly one of the three jobs a small team has to do: they reconcile state, they do not build your images, and they do not run your cluster.

The Argo project, which includes Argo CD, graduated from the CNCF on 6 December 2022. Flux graduated a week earlier, on 30 November 2022. Graduation is the CNCF's highest maturity tier, so you are not betting on abandonware with either one.

People conflate three separate jobs. Job one is CI: build, test, push an image. Job two is CD and GitOps: reconcile the desired state in git onto the cluster. Job three is the platform underneath: cluster lifecycle, ingress, TLS, DNS, autoscaling, secrets, observability, and upgrades. Argo CD and Flux CD do job two. They do not touch jobs one or three.

Job three is the one that eats a small team. Kubernetes ships roughly three minor releases a year and supports each minor version with patches for about 14 months before end of life. On the managed side the window is similar: Amazon EKS gives 14 months of standard support, Google GKE lands around 14 months on the regular channel, and Azure AKS gives 12 months of community support per version. Whichever cloud you pick, a cluster needs a real upgrade every few months whether or not anyone owns it.

Skipping upgrades has a literal line item. On EKS pricing, a cluster in standard support costs $0.10 per hour, and once its version falls into extended support the control plane jumps to $0.60 per hour. That is roughly $73 a month becoming roughly $438 a month, per cluster, as the price of deferring maintenance.

Nobody on a 5-person team has spare capacity for this. In Spectro Cloud's 2024 State of Production Kubernetes report, 76 percent of adopters said complexity had held back their Kubernetes adoption and 40 percent said they lacked the skills and headcount to manage it. That is the context in which "just run Argo CD" is advice, not a plan.

To be fair to GitOps, it is genuinely great at three things: drift detection when someone changes the cluster by hand, an auditable history of every change in git, and reproducible environments you can rebuild from a commit. Those are real benefits. They just do not include running the cluster.

How did we compare these GitOps CI/CD setups?

We scored seven setups on six criteria that only matter when nobody on the team is a platform engineer, starting with the one that decides everything: who gets paged when the control plane or an add-on breaks at 2am.

• Criterion 1 - Who maintains Kubernetes itself: you, the vendor, or nobody.
• Criterion 2 - Does it run in your own cloud account (AWS, GCP, Azure, Scaleway) or your existing Kubernetes cluster, so the bill, the committed spend and the data stay yours.
• Criterion 3 - Time to first production deploy for a team with no prior Kubernetes platform experience.
• Criterion 4 - Preview and ephemeral environments per pull request: built in, do-it-yourself, or not possible.
• Criterion 5 - What it actually costs at 5 engineers in 2026: per seat, per cluster, per workload, or free plus your time.
• Criterion 6 - Lock-in and exit path: is the output standard Kubernetes manifests or Helm charts you could keep and run elsewhere.

I will state the bias openly: we build Qovery, which lands in criterion 1 as "the vendor maintains it." So this guide names outright the cases where Argo CD, Flux CD, GitHub Actions, GitLab CI, Northflank, Porter or Devtron is the better pick. Every price here comes from the vendor's public pricing page or the project's GitHub releases, read on 21 October 2026, and anything I could not verify is described qualitatively instead of guessed.

Which GitOps CI/CD setup should a small Kubernetes team choose? (comparison table)

Ordered by how much Kubernetes maintenance each setup leaves on a 5-person team: CI plus a managed platform in your own cloud account leaves the least, raw Argo CD or Flux CD on a cluster you provisioned yourself leaves the most, and GitHub Actions alone sits in between until you add a second cluster.

On exit path: Argo CD, Flux CD and Devtron all output standard Kubernetes manifests or Helm charts you can keep and run anywhere. Among the managed options, the ones that deploy standard Kubernetes resources into your own cluster leave you the most portable; Qovery, for example, manages standard open-source Kubernetes, so your workloads stay where they are if you leave.

Render, Heroku and Fly.io are the non-Kubernetes escape hatch, simplest of all, but your workloads live in their account, not yours. The most common correct answer at five engineers is CI plus a managed platform in your own cloud account. The one condition that flips it: an engineer who actively wants to own the cluster, in which case run Argo CD or Flux CD.

Is Argo CD the best GitOps tool for a small team?

Argo CD is the strongest pure GitOps controller on the market, and it is the right pick when one of your five engineers genuinely wants to own the platform. It reconciles manifests extremely well, and it does not provision your cluster, run your ingress, rotate your TLS certificates or create your preview environments for you.

What it is: a CNCF-graduated declarative CD controller with a web UI, app-of-apps, sync waves, and ApplicationSet with a pull request generator for PR-based environments. The dashboard is its signature strength: any engineer, and frankly any product manager, can open it and see what is deployed and whether it has drifted.

The strengths are real and measurable. Zero licence cost. The largest GitOps ecosystem, with around 24,000 GitHub stars on argoproj/argo-cd against around 8,400 for flux2. Best-in-class drift visibility. And Argo Rollouts for canary and blue-green deployments when you need them.

Here is what a 5-person team still has to build and keep running around Argo CD: cluster provisioning and upgrades, an ingress controller, cert-manager for TLS, external-secrets for secret injection, and either Argo CD Image Updater or a CI write-back step because Argo CD has no native image automation. Then, for PR previews, you wire ApplicationSet together with DNS, wildcard TLS, database seeding and teardown yourself.

Quantify the reading load honestly rather than guessing hours: argoproj/argo-cd cut 79 releases in the last 12 months. You do not have to apply all of them, but someone has to read the CRD upgrade notes and decide, and that someone is one of your five engineers.

If you want Argo CD without hosting the control plane, managed Argo exists: Akuity starts around $495 a month, and Codefresh GitOps, now part of Octopus Deploy, offers a hosted option. Who should not pick Argo CD: a team where nobody wants to debug a stuck sync, read CRD upgrade notes, or own a control-plane upgrade window.

Argo CD or Flux CD: which should a small team pick in 2026?

Pick Argo CD if you want a dashboard any engineer or PM can read plus built-in pull request generators; pick Flux CD if you want the smallest set of controllers that reconciles git with built-in image automation. The cluster maintenance burden is identical either way, because neither tool touches the cluster lifecycle.

Flux CD is a CNCF-graduated set of controllers: source, kustomize, helm, notification, and image automation, all driven by CRDs you keep in git. Its best feature for this profile is that image automation is built in, so a new image tag can update git without a separate component. It has a tiny footprint, clean tenant isolation through scoped GitRepository resources, and vendor-managed distributions such as the Azure Arc GitOps (Flux v2) extension if you run on Azure.

Flux CD's weaknesses for a small team are also real. There is no first-party UI; you add Weave GitOps or Capacitor, and Weave GitOps lost its commercial backing when Weaveworks shut down in 2024, so weigh that. Debugging is harder for engineers who do not know Kubernetes internals. And PR previews need bot plumbing rather than a built-in generator.

The decision rule in one line per team: dashboard-first teams take Argo CD, terminal-first Helm and Kustomize teams take Flux CD, and teams with nobody owning the cluster should take neither. Both share the same fundamentals: standard manifests, zero licence cost, full portability, CNCF graduation, and zero help with cluster upgrades.

Can you just use GitHub Actions or GitLab CI and skip GitOps entirely?

Yes, and for a 5-person team on one cluster it is a legitimate setup: build the image, push it, run helm upgrade --install with a per-environment values file. It breaks the day you add a second cluster, hit config drift nobody notices, or get asked for an audit trail of who changed production.

The minimal viable pipeline is five steps: build the image, push it to a registry, run helm upgrade --install with a per-environment values file, run a smoke test, and notify the channel. That is the whole thing. It works at five people because you have one cluster, two or three environments, everyone is trusted, and rollback is a git revert plus a pipeline rerun.

Where it breaks is specific, not vague: no drift detection, so a hand-edit to the cluster goes unnoticed; long-lived cluster credentials sitting in CI unless you wire OIDC; no single source of truth for what is running; manual rollback under pressure; and preview scripts that rot because nobody owns them.

GitHub Actions supports OIDC federation to AWS, GCP and Azure, so no static cloud keys sit in CI, plus environments with required reviewers. Its included minutes for private repositories are 2,000 a month on Free, 3,000 on Team, and 50,000 on Enterprise Cloud, with Linux overage at $0.006 a minute.

GitLab CI has review apps for per-merge-request preview environments, and its included compute minutes are 400 a month on Free, 10,000 on Premium at $29 per user per month billed annually, and 50,000 on Ultimate at custom pricing.

In one quotable line: push pipelines need credentials pointed at the cluster, pull-based GitOps agents need none. Who should not pick CI alone: regulated teams needing declarative desired state in git for audit, or anyone running more than two clusters.

What if nobody on the team wants to own Kubernetes at all?

Then stop shopping for a GitOps controller and pick a managed internal developer platform that installs and operates Kubernetes inside your own cloud account: you keep the VPC, the data and the cloud bill, and the vendor keeps the pager for the control plane, the add-ons and the upgrades.

This category is bring-your-own-cloud, or BYOC. It sits between two extremes. At one end, DIY GitOps, where you own everything including the 2am page. At the other, a traditional PaaS, where the vendor owns everything including the account your data lives in. BYOC keeps the workload and the bill in your account while a vendor runs the control plane. That the category works is not vibes: Gartner predicts 80 percent of large software engineering organizations will have platform engineering teams by 2026, up from 45 percent in 2022, and the whole point of a platform team is to stop every developer from owning the cluster.

Qovery installs and manages Kubernetes on AWS, GCP, Azure or Scaleway, or connects to your existing Kubernetes cluster, whether self-managed or on-prem. Its verified capabilities are git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. It is best for a small team that must run in its own cloud account with no DevOps hire.

Qovery sits alongside Argo CD and Flux CD, not against them. A team already doing GitOps can connect its existing cluster and keep its manifests. Qovery is the wrong pick in two cases, and I will say them plainly: a team with a strong platform engineer who wants control of every manifest, or a team whose requirement is a free tier for hobby workloads. Neither is who Qovery is for.

The other managed options each win a different team. Northflank is strongest on mixed workloads, services, cron jobs, GPU and databases, with BYOC onto your own cluster, and suits teams wanting more build-system control inside one product. Porter is the closest thing to Heroku running on your own AWS, GCP or Azure account, and suits teams migrating off a PaaS who want to keep the PaaS mental model. Devtron is an open-source Kubernetes dashboard and CD layer built on Argo CD, and suits teams that want a self-hosted UI and accept operating it themselves.

How do you get preview environments per pull request without building them yourself?

A preview environment per pull request needs six moving parts, not one: a namespace or cluster per PR, a unique DNS record, a wildcard TLS certificate, a seeded database, injected per-environment secrets, and reliable teardown when the PR closes. Argo CD's ApplicationSet pull request generator covers the first part; managed platforms cover all six.

The Argo CD ApplicationSet pull request generator queries your SCM, supports GitHub, GitLab, Gitea, Bitbucket Server, Bitbucket Cloud and Azure DevOps, and generates one Application per open PR. By default it re-polls every 30 minutes unless you wire webhooks. It creates the application. It does not create the DNS record, the certificate, the database or the teardown.

On Flux CD the DIY bill of materials is longer: image automation plus a bot that writes a new HelmRelease per PR, plus external-dns for the DNS record, cert-manager for the certificate, and a teardown hook on PR close. Every one of those is a thing your five engineers now maintain.

The part nobody plans for is the database. A useful preview needs a per-PR database seeded with representative data and destroyed on close. Seeding from a snapshot restore beats running every migration from scratch, because it is faster and it matches production shape. Whoever builds previews by hand builds this last and regrets it first.

Cost control is arithmetic, so here is the arithmetic with the assumption in the open. A working week is about 45 of the 168 hours in a week. An always-on non-production environment therefore burns close to 3.7 times the compute hours of a working-hours-only one. That matters because idle is the norm: Cast AI's 2024 benchmark found organizations use only 13 percent of provisioned CPU and 20 percent of memory on larger clusters. Environment auto-stop is the lever that reclaims it.

Name the built-in options honestly: Qovery preview environments, Northflank preview environments, and GitLab review apps all handle the full flow; Vercel and Netlify do it beautifully for frontends only; and Argo CD ApplicationSet is the DIY baseline for everything else.

What does each GitOps setup actually cost at 5 engineers in 2026?

Argo CD and Flux CD cost nothing in licence and the most in engineering time; managed platforms charge per seat, per cluster or per workload on top of a cloud bill you still pay your provider directly. The line item that decides the comparison is the fraction of a platform engineer's salary you avoid hiring.

Start with the infrastructure floor everyone pays regardless of setup. An EKS control plane is $0.10 per hour, roughly $73 a month; GKE charges the same $0.10 per hour per cluster with a $74.40 monthly credit that covers one zonal cluster; AKS has a free tier and a paid Standard tier that adds a per-cluster uptime SLA fee. On top of that control plane sit your nodes, load balancers and NAT gateway, which dwarf it.

Now the hidden DIY cost, with the assumption stated so you can redo the maths. US median DevOps engineer total compensation is around $154,500 (levels.fyi, accessed October 2026). Self-run Argo CD or Flux CD realistically consumes 20 to 30 percent of an engineer's month in upkeep. That is roughly $31,000 to $46,000 a year of engineer time spent not shipping features. The licence is free; the labour is the single largest line item in the whole setup.

The BYOC cost advantage is concrete. When workloads run in your own account, you keep AWS Savings Plans and Reserved Instances worth up to 72 percent and GCP committed-use discounts worth up to 70 percent on memory-optimized machines, plus any startup credits. A full PaaS gives you none of that, because the bill is theirs.

For the price ladder's bottom rung, a PaaS runs a production dyno on Heroku from $25 a month for Standard-1X up to $250 for Performance-M, Fly.io on pay-as-you-go per second, and Render on per-instance monthly tiers starting in the single digits. I will not pretend managed Kubernetes platforms are cheaper in raw dollars than a PaaS or than free GitOps controllers. The money moves from engineer salary to platform fee. Do the arithmetic for your team and decide where you would rather spend it.

What does a recommended end-to-end setup look like for a 5-person team?

The reference stack for most 5-person teams in 2026 has three parts: GitHub Actions or GitLab CI for build and test, a managed Kubernetes platform in your own cloud account for deploy and operate, and an ephemeral preview environment on every pull request with auto-stop outside working hours.

The pipeline runs in order. A PR opens. CI builds and tests. A preview environment spins up with its own URL and a seeded database. Someone reviews it. The PR merges to main, which auto-deploys to staging. One approval promotes to production. That is the full loop, and at five people it fits in your head.

The branch and environment model that fits five people is trunk-based development, one staging environment, ephemeral previews per PR, and auto-stop at night and on weekends. Set two guardrails on day one: per-environment RBAC so nobody deploys to production by accident, and an automated rollback path you have tested before you need it.

Instrument it from the start with the four DORA key metrics: deployment frequency, change lead time, change failure rate, and failed deployment recovery time. DORA's research associates elite performers with on-demand deploys, change lead time under a day, a low single-digit change failure rate, and recovery under an hour. You will not hit elite in week one, and that is fine; you measure so you can see the trend.

Here is a 30-day rollout a team can copy. Week 1: stand up the cluster and deploy the first service. Week 2: add staging and wire CI. Week 3: turn on a preview environment per PR. Week 4: set per-environment RBAC, run a rollback drill, and enable auto-stop.

Graduate to self-run Argo CD or Flux CD when you hit multiple clusters, make a dedicated platform hire, or get a compliance mandate for declarative desired state in git. That is a good outcome, not a failure. It means you grew into the work, and now you have someone who wants it.

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

You can hand the whole setup to a coding agent: install the Qovery Agent Skills once, then ask your agent in plain language to deploy the repo into your own cloud account with a preview environment per pull request.

Install for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Prefer to keep the skills inside the repo instead of installing them globally:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code. It uses OAuth and is read-only by default, so the agent can inspect existing environments and will ask you to approve the OAuth login in your browser:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want the agent to change things, which also requires enabling write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Which skill does what: qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, and qovery-terraform. The skills deploy; the MCP Server operates what already exists. Then just ask, in plain language: "deploy this repo to my AWS account with Qovery and open a preview environment on every pull request." The full walkthrough is in the AI agent quickstart and the Claude Code integration page.