★ 33,964GoApache-2.0updated Jun 2026
best for anyone who lives in the terminal and wants a faster, friendlier replacement for raw kubectl
k9s is what you reach for once kubectl's get/describe/logs dance has worn you down. The breadth is real — cordon and drain nodes, roll back a ReplicaSet, trigger a CronJob, pull up an XRay dependency graph, all without leaving the terminal. FastForwards is the kind of detail that tells you someone uses this daily: annotate the manifest once and the port-forward dialog never bothers you again.
The catch is that it's still pre-1.0 after seven-plus years, and the README says as much — config file locations are explicitly called out as 'still in flux.' That's not nothing if you're trying to standardize a whole team on it: settings are spread across multiple YAML files in different XDG paths, and a new hire needs someone to just tell them which file does what. RBAC requirements aren't documented anywhere either, so on a cluster with tight policies you'll hit permission errors before you know which service account role k9s actually wants.
It's also not a competitor to Rancher or Portainer below — those manage clusters from the outside, k9s lives inside one you already have access to.
Our full take →GitHub ↗
★ 29,866GoApache-2.0updated Jun 2026
best for packaging and templating manifests — the default package manager everyone else gets compared to
Helm is the thing almost everything else on this page quietly depends on. Argo CD and Flux both consume Helm charts rather than replace them — you're not choosing Helm instead of GitOps, you're choosing it underneath GitOps. The release model is sound: state lives in the cluster as Secrets, so there's no separate store to fall out of sync with, and dropping Tiller in the v3 rewrite removed a real security liability.
The templating language is the permanent problem. Go templates were never meant for config, and the nested conditionals plus the whitespace-trimming dance get unreadable fast at any real scale — that's not a bug that gets fixed, it's the foundation. helm upgrade does a three-way merge that produces diffs you'll stare at for a while, and hooks firing out of order have taken down more than one production deploy. When a release fails, you're debugging the Helm state and the cluster state at once, and the error messages rarely point at which one is lying to you.
Our full take →GitHub ↗
★ 22,830GoApache-2.0updated May 2026
best for teams doing GitOps who want the most mature CD tool and the best web UI for it
Argo CD is the one with the UI people actually open. ApplicationSet's matrix and merge generators let you describe genuinely complicated multi-cluster setups declaratively instead of scripting them, and the Projects model — RBAC, source repo restrictions, destination whitelisting — is multi-tenancy that's been tested at companies much bigger than yours. It's also one of the better-secured projects in the CNCF: SLSA Level 3, signed releases, an actual SECURITY.md with a real CVE process.
Compared to Flux, Argo CD is one tool to learn rather than five controllers to coordinate, which is exactly why most teams start here. The tradeoff shows up at scale: every manifest render funnels through the repo-server, and past a thousand or so Applications, or with slow Helm/Kustomize builds, it becomes a bottleneck you can't tune without understanding its caching internals. Secret management is explicitly out of scope, so you're bolting on Sealed Secrets or External Secrets Operator yourself, and the overlap between app-of-apps and ApplicationSet isn't explained well anywhere, so teams commonly end up running a confusing mix of both.
Our full take →GitHub ↗
★ 33,232GoApache-2.0updated Jun 2026
best for edge, IoT, or single-node setups that need real Kubernetes without the resource overhead
k3s is Kubernetes with the weight taken out, not a toy version of it — it passes the full conformance suite and ships as a single binary under 100MB with containerd, CoreDNS, and Traefik already wired in. SQLite as the default datastore means a single-node or edge deployment skips etcd's operational overhead, and tunneling the kubelet API over websockets means worker nodes don't need inbound ports open, which matters once you're talking about edge or IoT hardware.
The SQLite default is also where teams get bitten: it's fine for dev or a single node, but nothing stops you from promoting that cluster to production without switching to a real HA datastore, and the docs warning you about it doesn't stop it from happening. The bundled Traefik and Flannel are opinionated — swapping in Cilium or nginx-ingress means disabling the built-ins first, which eats into the 'simple' pitch. If you're on ARM, test your specific variant before committing; support lags x86_64 more than the marketing suggests. Unlike minikube below, this is meant to keep running after you've closed your laptop — don't confuse the two.
Our full take →GitHub ↗
★ 31,904GoApache-2.0updated Jun 2026
best for running a disposable cluster on your own laptop for local dev and testing
minikube is where you start, and where you stay for local dev — it's backed by the actual SIG-cluster-lifecycle team, and the driver model (Docker, containerd, VirtualBox, HyperKit) means you can switch runtimes without rebuilding anything. The addon system gets you ingress, metrics-server, or a dashboard in one command, and the project's CI discipline — functional tests per addon, performance benchmarks, automated dependency PRs across 40-plus bundled components — is more rigor than most tools this size bother with.
What it isn't is k3s: minikube's cluster is disposable by design, and multi-node support is clearly second-class — anything testing real pod scheduling or node affinity pushes you toward kind or an actual cluster instead. The vendored addon YAML templates lag upstream releases despite all that automation, so you'll occasionally hit a version mismatch the addon hasn't caught up to yet. If you're on Windows, budget for a worse experience generally and genuinely bad filesystem mount performance specifically — it'll kill any dev loop that depends on hot reload.
Our full take →GitHub ↗
★ 8,185GoApache-2.0updated Jun 2026
best for teams who'd rather assemble GitOps from composable CNCF primitives than adopt one big app
Flux's pitch is that GitOps shouldn't be one big app — Source, Kustomize, Helm, Notification, and Image are separate controllers with separate CRDs, so you adopt what you need and a failure in one doesn't take down the rest. OCI artifact support lets you version Kubernetes manifests the same way you version container images, a real improvement over plain Git for some workflows, and the image automation controllers solve 'auto-bump this tag in Git' without reaching for a separate tool.
The composability is also the cost: debugging a failed reconciliation means chasing status conditions across four or five CRDs, and flux logs doesn't aggregate them for you, which is a worse experience than Argo CD's single UI above. Image automation commits back to Git under a bot identity, which muddies blame history with no clean way to batch the noise. And bootstrapping requires giving Flux write access to your repo — workarounds exist, but if your team has strict branch protection, that's a real conversation before you even start.
Our full take →GitHub ↗
★ 25,708GoApache-2.0updated Jun 2026
best for ops teams managing many clusters across clouds and on-prem from a single pane of glass
Rancher is for the moment you stop managing one cluster and start managing a fleet — RKE2, K3s, AKS, EKS, GKE, and bare metal all provision through the same UI, with RBAC, Helm catalogs, monitoring, and logging wired up consistently across every one of them. The Norman/Steve dual-API setup is ugly under the hood, but it means the UI and CLI both work without proxying everything through kubectl, and the upgrade hooks handle CRD migrations that trip up most people running Helm by hand.
None of that matters if you're running a single cluster — Rancher's value only clears the overhead of running Rancher once you're at three clusters or more. The codebase is genuinely large, the dependency graph pulled in by its meta-repo structure makes build times painful without their own CI setup, and the separate UI repo tends to lag a release or two behind the API. Compared to Portainer below, this is the heavier, more serious tool — pick it because you need fleet management, not because you want a simple GUI.
Our full take →GitHub ↗
★ 37,832TypeScriptZlibupdated Jun 2026
best for small teams who want a simple web GUI instead of learning kubectl or Helm
Portainer's whole appeal is the single docker run setup — no external database, BoltDB is embedded, and you're looking at a working UI for Docker, Swarm, and Kubernetes a minute later. The edge agent tunnels through Chisel so you can manage remote hosts over an outbound connection with no inbound firewall holes, a real problem solved for distributed setups, and the Go backend's test coverage, migrations included, is better than you'd expect from a tool this size.
The catch is the Community Edition's permission model is admin-or-not — for any team bigger than a couple of people, that's a wall you hit almost immediately, since real RBAC lives behind the Business Edition. Matomo analytics are opt-out, not opt-in, firing on first start unless you catch the setting during the install wizard. The frontend is also mid-migration from Angular to React with no stated timeline, so expect inconsistent UI until that finishes. Next to Rancher above, Portainer is the lighter, cheaper-feeling tool right up until you need the access control Rancher gives you without a paywall.
Our full take →GitHub ↗
// questions people ask
Before you choose
Argo CD or Flux — which one should I use for GitOps?
Argo CD if you want one tool with a real web UI your team will actually open and a single mature project to learn. Flux if you'd rather adopt separate controllers piece by piece and are comfortable debugging reconciliation across several CRDs when something breaks. Most teams pick Argo CD first and only move to Flux once they have a specific reason to want the pieces separate.
What's the difference between k3s and minikube?
minikube runs a disposable cluster on your own laptop while you're building or learning — it's not meant to survive past your dev loop. k3s is a real, conformant Kubernetes distribution meant to run in production at the edge or on a single node, with the overhead stripped out. Don't run production on minikube's cluster, and don't expect k3s's bundled defaults to match a full upstream cluster without some work.
Do I still need Helm if I'm using Argo CD or Flux?
Probably yes — both tools consume Helm charts rather than replace them, so Helm is still doing the templating work underneath your GitOps pipeline. What Argo CD and Flux replace is the manual `helm upgrade` step, not the chart format itself. If everything you deploy is plain manifests or Kustomize, you can skip Helm entirely, but most of the ecosystem still ships as charts.
Rancher or Portainer for a management UI?
Rancher if you're an ops team running three or more clusters across clouds and on-prem and need real multi-cluster RBAC and provisioning. Portainer if you're a small team that wants a simple GUI for Docker and Kubernetes without learning kubectl, and you're fine paying for the Business Edition once you need actual per-user permissions. Running a single cluster makes Rancher's overhead hard to justify either way.
None of these eight are wrong, exactly — they're just wrong for some set of people reading this page. If you want more of this same kind of specific, honest take on repos outside Kubernetes, that's what the weekly email is for.