Open source tools for deployment, orchestration, monitoring, and infrastructure management.
Ranked by Discovery Score — our 0-100 composite of adoption, maintenance, community, and license health. How scoring works.
By Erik Loyd, SaaS CEO and former COO/CFO of an AWS Premier Partner.
Kubernetes runs your containers across a fleet of machines and keeps them alive: it picks which server each one lands on, restarts crashed ones, wires up networking and scales out when traffic spikes. It's the default for running containers at scale, and the whole project is free under Apache 2.0, with no gated features. Kubernetes alone isn't a production platform. You still install and patch ingress, certificates, monitoring, logging and storage, each a separate project. Most teams should rent the control plane: EKS and GKE charge $0.10 per cluster per hour, AKS Standard is $73 per cluster per month, DigitalOcean's is free. Nodes cost extra. Solo: skip it, Docker Compose on one server does the job. Small teams: managed only, and only if you need multi-node scheduling. Larger teams: this is where it pays off, with someone owning it. The catch is the upgrade treadmill. Only the three newest minor versions get patches, each for about a year. Fall behind on EKS or GKE and extended support costs $0.60 per cluster per hour, six times the standard fee. And ingress-nginx, the long-time default ingress controller, stopped getting fixes after March 2026, so many clusters owe a migration to Gateway API.
Kubernetes is free; a managed control plane runs from $0 (DigitalOcean, AKS Free without an SLA) to $0.10 per cluster per hour on EKS and GKE, plus your nodes. Fall behind on upgrades and EKS and GKE charge $0.60 per cluster per hour for extended support.
**Free:** All of Kubernetes: API server, scheduler, controller manager, kubelet, kubectl. Apache License 2.0, no paid edition, no gated features. kind or minikube run a local cluster on a laptop for $0. **Self-hosted:** You can run your own control plane on bare metal or VMs, but you also own etcd, upgrades, certificates, and every add-on a production cluster needs (ingress or Gateway API controller, cert-manager, monitoring, logging, storage). The project patches only the three newest minor releases (currently 1.37, 1.36, 1.35), each for about a year; 1.34 reaches end of life on 2026-10-27. Expect to upgrade every few months. **Paid:** The software is free; managed control planes are where the bills are. EKS: $0.10 per cluster per hour (about $73/month) for versions in standard support (14 months), $0.60 per cluster per hour in extended support. GKE: $0.10 per cluster per hour for every mode, with a $74.40 monthly credit per billing account that covers one Autopilot or zonal cluster (not regional); extended support adds $0.50 for $0.60 total. AKS: Free tier with no SLA (not recommended past 10 nodes), Standard $73 per cluster per month, Premium with long-term support $438 per cluster per month, AKS Automatic $116.80 per cluster per month plus a per-vCPU management charge. DigitalOcean: free control plane, $40/month for high availability, nodes from $12/month each. All prices exclude worker nodes, storage, load balancers and bandwidth.
Docker Compose lets you define all of them in one YAML file and start everything with a single command. Instead of running five separate docker run commands with flags you'll never remember, you write a docker-compose.yml and run docker compose up.
It's become the standard way to define local development environments. Clone a repo, run docker compose up, and you have a fully working environment with the correct database version, the right Redis config, and all the networking already wired. No "works on my machine" problems.
Compose V2 (the current version) is built into Docker CLI as a plugin. No separate install needed. It's faster, supports GPU access, watch mode for development (auto-restart on file changes), and profiles for running subsets of services.
The catch: Compose is for development and simple deployments. It runs on a single host. For production with multiple servers, you need Kubernetes, Docker Swarm, or a platform like Coolify. The YAML syntax is straightforward but verbose. A complex stack can hit 200+ lines. And Compose doesn't handle secrets well for production. Environment variables in a YAML file aren't secure secrets management.
Completely free. Docker Desktop has licensing requirements for large companies, but Compose itself is Apache 2.0 with no restrictions.
### Free Fully open source under the Apache 2.0 license. Docker Compose is free to use, regardless of whether you use Docker Desktop (which has its own licensing) or Docker Engine on Linux. ### Docker Desktop Licensing (Related but Separate) - **Personal:** Free - **Pro:** $5/mo - **Team:** $9/user/mo - **Business:** $24/user/mo Note: Docker Compose works with Docker Engine on Linux without Docker Desktop. The Desktop license only applies if you use Docker Desktop on Mac/Windows at a company with 250+ employees or $10M+ revenue. ### The Math Docker Compose itself: $0, always. The infrastructure it runs on (VPS, cloud instances) is your only cost. A $10/mo VPS can run a Compose stack with 3-4 services comfortably.
Terraform lets you define your cloud infrastructure in code files instead of clicking through the AWS, GCP or Azure consoles. Write what you want, run terraform apply, and it creates everything. Change the file, run it again, and it updates only what changed. It's what most infrastructure teams reach for first.
The license is the part to understand. Since version 1.6 in 2023 it's under the Business Source License, now with IBM as licensor. Production use, including for your clients, is allowed; offering Terraform itself as a paid hosted or embedded product that competes with IBM's is not. Each version converts to open source MPL 2.0 four years after release. opentofu/opentofu is the fully open fork, MPL 2.0 under the Linux Foundation.
The CLI is free. HCP Terraform, the hosted version, is free up to 500 managed resources, with SSO, remote state and a private module registry included. Past that, Essentials runs about $0.10 per resource per month, Standard (policy checks and drift detection) about $0.47, and Premium (audit logs) about $0.99. Solo and small teams: CLI plus the free tier. Larger teams: Standard.
The catch is state. The state file is the source of truth, and a corrupted or out-of-sync state is the classic multi-hour outage. Store it remotely with locking from day one.
CLI free for production use under BUSL. HCP Terraform is free to 500 resources, then roughly $0.10 to $0.99 per resource per month by tier.
### CLI Free under BUSL-1.1. Internal and client production use is allowed; offering Terraform as a competing paid hosted or embedded product is not. Each version converts to MPL 2.0 four years after release (1.6.0 converts around October 2027). ### HCP Terraform (hosted) **Free:** Up to 500 managed resources, 1 concurrent run. Includes SSO, remote state and runs, VCS integration, team management and the private module registry. **Essentials:** About $0.00013 per resource-hour, roughly $0.10 per resource per month. 3 concurrent runs. HashiCorp's own example: 1,000 resources is about $98/mo. **Standard:** About $0.00064 per resource-hour, roughly $0.47 per resource per month. Adds policy enforcement, cost estimation and drift detection, with 10 concurrent runs. **Premium:** About $0.00135 per resource-hour, roughly $0.99 per resource per month. Adds audit logging, 200 concurrent runs. Prices are IBM's indicative pay-as-you-go rates and may vary by country. ### Terraform Enterprise Self-hosted HCP Terraform. Sales-priced. ### Alternatives OpenTofu is the MPL 2.0 fork. Spacelift, env0 and Scalr sell hosted runs and state for both.
K9s gives you a terminal UI that lets you browse, manage, and debug your cluster in real time. It's a dashboard for Kubernetes that lives in your terminal. Completely free. You get real-time resource monitoring, log tailing, shell access into pods, port forwarding, RBAC visualization, and support for custom resource definitions, all with keyboard shortcuts that make kubectl feel slow. It supports multiple clusters and namespaces with quick switching. Installation is a single binary. Homebrew, snap, or download from GitHub releases. No cluster-side components needed. It uses your existing kubeconfig. Anyone working with Kubernetes should have this installed. It's free, it's fast, and it makes cluster management significantly less painful. The catch: the learning curve is the keyboard shortcuts. There's no mouse support. It's fully keyboard-driven. You'll spend 30 minutes learning the navigation, but once you do, you won't go back to raw kubectl for day-to-day work. Also, for complex debugging, you'll still drop to kubectl or stern for advanced log aggregation.
Free, always. Zero cost, zero setup complexity. Install it if you touch Kubernetes.
### Fully Free k9s is 100% free and open source under Apache 2.0. No paid tier, no hosted version, no premium features. ### Setup Single binary download. `brew install derailed/k9s/k9s` on Mac, `snap install k9s` on Linux, or grab the release from GitHub. Uses your existing kubeconfig. Zero additional setup. No cluster-side agents or CRDs to install. ### What You Get for $0 - Real-time cluster view with resource usage - Pod logs (tail, follow, filter) - Shell into containers - Port forwarding - RBAC matrix view - CRD support - Multi-cluster/namespace switching - Customizable skins and hotkeys - Plugin system for extensions - Benchmark resources ### The Math Lens Desktop (the main competitor): free tier exists but commercial use requires a subscription at $199/year. k9s: $0, forever. If you prefer a GUI, Lens is fine. If you live in the terminal, k9s is the answer. ### Verdict Install it. There's literally no cost and it makes kubectl workflows 10x faster.
K3s runs production Kubernetes in 100MB of RAM, packaged as a single binary under 70MB. Same Kubernetes API, same kubectl commands, same ecosystem, just without the components most people never touch. It runs on everything from a Raspberry Pi to production cloud servers. Fully free under Apache 2.0. No paid tier, no enterprise version, no feature gating. SUSE/Rancher maintains it, and they make money on Rancher (the multi-cluster management layer), not K3s itself.
Installation is a one-liner: curl -sfL https://get.k3s.io | sh -. You have a running Kubernetes cluster in under 60 seconds. Adding worker nodes is equally simple. It bundles containerd, Flannel (networking), CoreDNS, and Traefik (ingress) so you don't have to install them separately.
Solo developers: this is the easiest way to run Kubernetes locally or on a single VPS. Small teams: production-ready for most workloads. Growing teams: use it. It's the same Kubernetes, just lighter.
The catch: K3s uses SQLite by default instead of etcd, which means single-node setups aren't highly available. For HA, you'll switch to an external Postgres/MySQL database or embedded etcd, which adds complexity back. Also, some enterprise Kubernetes tools assume full K8s and might not work out of the box.
Free. Run production Kubernetes on a $10/mo VPS. Saves $70-150/mo vs managed Kubernetes control plane fees alone.
### Free Everything. K3s is a fully conformant Kubernetes distribution; it passes the same CNCF conformance tests as full Kubernetes. All bundled components (containerd, Flannel, CoreDNS, Traefik, local-path storage) are free. ### Self-Hosted (Only Option) K3s runs wherever Linux runs. Minimum requirements: 512MB RAM for a server node, 1 CPU. Recommended: 2GB+ RAM, 2+ CPU for production workloads. That's a $5-20/mo VPS. ### Infrastructure Costs - Single node: $5-20/mo VPS. Good for dev/staging and small production workloads. - 3-node HA cluster: $30-60/mo total. Production-ready with node failure tolerance. - Edge deployments: runs on Raspberry Pi ($35-75 hardware cost, zero ongoing). ### Cost Comparison - Managed Kubernetes (EKS, GKE, AKS): $70-150/mo just for the control plane, before any worker nodes. - K3s: $0 for the software. Your only cost is the VMs. ### Verdict The cheapest way to run production Kubernetes. $10-20/mo for a useful cluster vs $200+/mo for managed alternatives.
Podman is the drop-in Docker replacement that doesn't need a daemon running in the background. Same commands (podman run, podman build, podman pull) but no daemon process, no root access required, and the security model is fundamentally better.
Podman runs containers as your regular user by default (rootless). Each container is a child process of the podman command, not a daemon. If Podman crashes, your containers keep running. If Docker's daemon crashes, everything dies.
The Docker CLI compatibility is nearly perfect. Most people alias docker to podman and never notice the difference. Podman Compose exists for docker-compose files. Podman can build Dockerfiles. It pushes to and pulls from the same registries. Podman's unique feature: pods. Like Kubernetes pods, you can group containers that share network and storage. This makes it a natural stepping stone from local development to Kubernetes deployment.
The catch: "nearly perfect" Docker compatibility means occasionally you hit an edge case that works in Docker but not Podman. Rootless networking has quirks. Binding to ports below 1024 requires extra config. Docker Desktop's Kubernetes integration and extensions ecosystem doesn't exist in Podman. And some CI systems and dev tools assume Docker's socket API, requiring workarounds for Podman.
Completely free with no licensing restrictions. A genuine $0 alternative to Docker Desktop for teams that hit Docker's paid tier requirements.
### Free Fully open source under the Apache 2.0 license. No paid tier, no cloud service. Podman Desktop (the GUI) is also free. ### Cost Comparison vs Docker Desktop - **Podman + Podman Desktop:** $0, always, no licensing restrictions - **Docker Desktop Personal:** Free - **Docker Desktop Pro:** $5/mo - **Docker Desktop Team:** $9/user/mo (required for companies with 250+ employees or $10M+ revenue) - **Docker Desktop Business:** $24/user/mo ### The Math For a 20-person team at a company above Docker's revenue threshold: Docker Desktop Team costs $180/mo ($2,160/yr). Podman costs $0. The migration effort is a one-time cost of maybe 2-4 hours per developer to adjust workflows and handle edge cases.
Helm packages Kubernetes configurations into reusable templates called charts, so you stop managing dozens of YAML files by hand. It's a package manager for Kubernetes: instead of writing 15 config files per service, you install a chart and override the values you care about. CNCF graduated project, Go. The chart ecosystem is massive: Bitnami alone publishes hundreds of production-ready charts for databases, monitoring, CI tools. Helm 3 removed the server-side component (Tiller) that was a security headache in v2. Fully free, Apache 2.0. No paid tier, no hosted version. Helm is a CLI tool that runs on your machine and talks to your Kubernetes cluster. Every team size from solo to enterprise uses Helm, it's essentially the standard way to package Kubernetes applications. The ops burden is trivial for using charts; moderate if you're authoring and maintaining your own. The catch: Helm's templating language (Go templates) is painful to debug. Complex charts become unreadable fast. And Helm doesn't handle the full lifecycle; it installs and upgrades, but rollback is limited and drift detection doesn't exist natively. Tools like ArgoCD or Flux layer on top for GitOps workflows. If you're not on Kubernetes, Helm is irrelevant.
Free. Always has been, always will be. CNCF project with no commercial entity behind it.
Fully open source under Apache 2.0. No paid tier, no managed offering. Helm is a CLI tool; there's nothing to host. Charts from public repositories (ArtifactHub, Bitnami) are free. Private chart repositories can use free solutions like ChartMuseum or any OCI registry.
Jenkins automates builds, tests, and deployments with 1,800+ plugins covering virtually every tool in the software development ecosystem. Jenkins is the original and still the most extensible. It's been around since 2011 and there isn't a workflow it can't handle. MIT licensed. Jenkins runs builds, tests, and deployments using declarative or scripted pipelines defined in Jenkinsfiles. It scales from a single machine to hundreds of build agents. Fully free. No paid tier. CloudBees offers a commercial Jenkins distribution, but the community edition is complete. The catch: Jenkins is showing its age. The UI looks like 2012. Configuration is often click-through rather than code-first. Maintaining a Jenkins server means updating plugins constantly (some of which conflict), managing security patches, and dealing with Java memory tuning. Modern alternatives like GitHub Actions, GitLab CI, or ArgoCD handle common workflows with less operational burden. Jenkins still wins for complex, custom pipelines that nothing else can express, but if your needs are standard, you're paying an ops tax for flexibility you don't use.
Free. You pay for the server to run it on, not for Jenkins. Budget $60-120/mo for infrastructure.
### Open Source: Free - Full CI/CD pipeline engine - 1,800+ plugins - Declarative and scripted pipeline syntax - Distributed builds across agents - Blue Ocean UI (modern alternative interface) - Docker, Kubernetes, and cloud agent support ### CloudBees CI (Commercial) - Enterprise Jenkins distribution - Managed masters, RBAC, analytics - Custom pricing (typically $50K+/year for mid-size orgs) - Not required; community Jenkins is complete ### The Math Jenkins server on a t3.large: ~$60/mo. Build agents (2-4 t3.medium spot instances): ~$30-60/mo. Total: ~$90-120/mo for a small team's CI. Compare to GitHub Actions: 2,000 free minutes/month, then $0.008/min = ~$50/mo for equivalent usage. Jenkins is cheaper at scale but costs more in ops time.
Rancher gives you a web dashboard to manage all your Kubernetes clusters from one place. It's a control panel that sits on top of Kubernetes and makes the painful stuff (deploying apps, managing access, monitoring health) less painful. The core platform is fully open source under Apache 2.0. You get multi-cluster management, a built-in app catalog, RBAC (role-based access control, who can do what on which cluster), and monitoring out of the box. SUSE, which owns Rancher, sells enterprise support and additional security features, but the open source version is production-ready. Self-hosting is the default: Rancher runs on a Kubernetes cluster itself. Initial setup takes a few hours if you know Kubernetes. If you don't know Kubernetes, Rancher isn't going to save you from that learning curve. It manages complexity; it doesn't eliminate it. Solo developers: you probably don't need this. Use K3s directly. Small teams running 1-2 clusters: Rancher is great, and the free tier covers everything. Growing teams with 5+ clusters across environments: this is where Rancher really shines. The catch: Rancher managing Kubernetes means running Kubernetes to manage Kubernetes. If you're not already committed to K8s, this adds complexity rather than reducing it.
Open source covers everything most teams need. Pay $500-2,000/node/year for compliance and enterprise support.
### Free (Open Source) Rancher's core platform is Apache 2.0, fully free. Multi-cluster management, app catalog (Helm charts), RBAC, monitoring/alerting, CI/CD pipelines via Fleet, and cluster provisioning on any infrastructure. This covers what most teams need. ### Self-Hosted Rancher runs on any Kubernetes cluster. You can install it on a K3s single-node cluster for small deployments or a full HA setup for production. Docker single-node installs exist for testing but aren't recommended for production. Ops burden is moderate: you're maintaining Rancher's own cluster plus the clusters it manages. ### Paid (SUSE Rancher Prime) SUSE sells Rancher Prime with 24/7 support, security hardening, FIPS compliance, extended maintenance windows, and access to SUSE's vulnerability scanning. Pricing is per-node, per-year, typically $500-2,000/node/year depending on support tier and volume. Contact sales for exact quotes. ### When to Pay Pay when you need compliance certifications (FedRAMP, FIPS), guaranteed SLAs on support, or long-term security patches for older versions. The open source version gets community support on GitHub and Slack, which is usually sufficient for teams with Kubernetes expertise. ### Verdict The open source version is genuinely production-grade. Enterprise pricing only makes sense for regulated industries or teams without Kubernetes expertise who need guaranteed support.
Pulumi lets you define infrastructure using real programming languages: TypeScript, Python, Go, C#, Java. Same concept as Terraform, but instead of learning a DSL, you use the language you already know with loops, conditionals, functions, and your IDE's autocomplete. Go, Apache 2.0. Supports AWS, Azure, GCP, Kubernetes, and 150+ providers. The state management works like Terraform: tracks what's deployed and diffs against your code. Pulumi AI can generate infrastructure code from natural language prompts. The CLI and engine are free and open source. You can self-manage state in an S3 bucket or local file, truly $0. Pulumi Cloud (managed state + team features) has a free tier for individual use: 1 user, unlimited stacks, 200 resources. Pulumi Cloud Team: $50/user/month: adds RBAC, audit logs, CI/CD integrations. Enterprise: custom pricing for SAML SSO, self-hosted options, and policy-as-code. Solo developers: free, self-manage state or use the free Pulumi Cloud tier. Either way, $0. Small teams: self-managed state works fine until you need collaboration features. $50/user/month for Cloud Team is steep if you're just managing a few stacks. Medium to large: Pulumi Cloud starts making sense for RBAC and audit trails. The catch: the ecosystem is smaller than Terraform's. Fewer blog posts, fewer Stack Overflow answers, fewer example configs. And using a real programming language is a double-edged sword: you CAN write bad abstractions and over-engineer your infrastructure code. Terraform's simplicity is a constraint that prevents some of that.
CLI is free forever. Self-manage state for $0 or use Cloud free tier. $50/user/month Team plan is the team collaboration tax.
### Free Tier CLI and engine are Apache 2.0, fully free. Self-managed state (S3, local file, Azure Blob, GCS) costs nothing. Pulumi Cloud free tier: 1 user, unlimited stacks, 200 resources. ### Paid Tiers - **Team ($50/user/month):** RBAC, CI/CD integrations, secrets management, audit logs, unlimited resources - **Enterprise (custom):** SAML SSO, self-hosted Pulumi Cloud, policy-as-code, dedicated support - **Business Critical (custom):** Air-gapped deployments, custom contracts, 99.9% SLA ### Self-Hosted Costs The CLI runs locally, no server needed. State storage: S3 bucket at $0.023/GB/month. Total self-hosted cost: effectively $0. ### When to Pay Pay $50/user/month when your team needs shared state with RBAC, or when managing state backends yourself becomes a burden. Enterprise for SSO requirements.
Cilium is the networking layer for Kubernetes that runs on eBPF (a technology that lets programs run safely inside the Linux kernel), so it handles networking, security, and observability without the overhead of older approaches. It covers all CNI (Container Network Interface) duties plus L3, L4, and L7 network policies, transparent encryption, sidecar-free service mesh, and Hubble for network observability. Free and open source, mostly Apache 2.0, and a CNCF graduated project. Self-hosting is the default. Cilium replaces your cluster's CNI plugin: install via Helm and it takes over networking. Setup is moderate for anyone comfortable with Kubernetes networking. It needs Linux kernel 5.10 or later (or RHEL 8.10's 4.18), and the project maintains the last three minor releases. Solo developers: unless you are learning Kubernetes networking, stick with the CNI your distro bundles. Small teams: worth the setup when network policies and observability matter. Medium teams: Hubble alone justifies it. Large teams: Isovalent, the company behind Cilium and now part of Cisco, sells the Isovalent Enterprise Platform with 24x7 support, Hubble Timescape for historical flow data, and a separate runtime security product. Pricing is not public. The catch: older kernels and non-Linux nodes will not work. And swapping the CNI plugin on a live cluster is not a trivial operation. Plan the migration like a migration.
Open source covers most needs. Isovalent's enterprise platform adds support, historical flow data, and runtime security at contact-sales pricing.
**Free:** Full CNI implementation, L3/L4/L7 network policies, transparent encryption (WireGuard or IPsec), Hubble observability, sidecar-free service mesh, Cluster Mesh for multi-cluster networking, bandwidth management, and BGP. User space components are Apache 2.0. The BPF code templates are dual licensed under GPL 2.0 and BSD 2-Clause. **Self-hosted:** Cilium runs as a DaemonSet on every Kubernetes node, installed via Helm. It needs Linux kernel 5.10 or later. Moderate work up front, lighter once it is running. Three minor versions are maintained at a time. **Paid:** The Isovalent Enterprise Platform from Isovalent (now part of Cisco): Isovalent Networking for Kubernetes, Runtime Security, Load Balancer, Hubble Timescape for historical network flows and policy auditing, and 24x7 support. No public pricing. The site offers a demo and a sales contact. Pay when you need historical flow data for compliance or forensics, or guaranteed support. The open source version is production-ready for most teams.
ArgoCD watches your Git repo and automatically syncs what's deployed in Kubernetes to match what's committed, making Git the single source of truth for your infrastructure. Push a change to Git, ArgoCD deploys it. Someone manually edits the cluster, ArgoCD reverts it. That's GitOps. Apache 2.0, CNCF graduated project. The UI shows you a live dependency graph of every resource in your app, color-coded by sync status. You can see at a glance what's deployed, what's out of sync, and what's degraded. Fully free. No paid tier from the Argo project. Akuity (founded by Argo creators) offers a managed version starting at $0 for small clusters, scaling with usage. ArgoCD handles multi-cluster deployments, Helm charts, Kustomize overlays, plain YAML, and Jsonnet. RBAC is built in. SSO works via OIDC/SAML. The catch: ArgoCD itself needs to run somewhere, and it's not lightweight. The controller, server, repo server, and Redis consume real resources. Initial setup for a production-grade deployment (HA mode, SSO, RBAC policies) takes days, not hours. And the application-of-applications pattern for managing many apps has a learning curve.
Free self-hosted. Akuity offers managed ArgoCD with a free tier for small deployments.
### Open Source: Free - Full GitOps deployment engine - Multi-cluster support - Helm, Kustomize, Jsonnet, plain YAML - Web UI with live resource visualization - RBAC and SSO (OIDC/SAML) - Webhook-triggered and polling sync - Automated drift detection and correction ### Akuity (Managed ArgoCD): Free tier available - Managed control plane, no self-hosted ArgoCD infra - Free for small clusters - Paid tiers for larger deployments (contact for pricing) - Enterprise features: audit logs, policy engine, support SLAs ### The Math Self-hosted ArgoCD HA mode: ~3 pods, 500MB-1GB RAM total. On existing Kubernetes clusters, the marginal cost is near zero. Akuity's managed version saves ops time but you lose some control over upgrades and configuration.
It's the container runtime that actually pulls images, manages container lifecycle, handles storage, and runs your containers. Docker, Kubernetes, and most cloud providers use containerd underneath. You just don't interact with it directly most of the time. Everything is free under Apache 2.0. CNCF graduated project. No paid tier, no commercial entity selling premium features. Core infrastructure maintained by contributors from Docker, Google, Microsoft, AWS, and others.
You typically don't install containerd directly unless you're building a container platform or running Kubernetes without Docker. Kubernetes dropped Docker as a runtime in v1.24 and switched to containerd directly, which actually simplified things. If you're on any managed Kubernetes service, containerd is already running. Solo developers: you'll never interact with this directly. Docker Desktop or Podman wraps it for you. Platform engineers building Kubernetes clusters: you need to understand containerd, its configuration, and its relationship to the CRI (Container Runtime Interface).
The catch: containerd is deliberately low-level. It doesn't have a CLI for humans (well, ctr exists but it's not user-friendly). It's meant to be used by other software, not by people. If you're looking for a Docker alternative to run containers, look at Podman instead.
Completely free. Apache 2.0. You're almost certainly already using it via Docker or Kubernetes.
### Free Everything. Container lifecycle management, image pulling/pushing, snapshotting, networking setup (via CNI plugins), and the CRI interface for Kubernetes. Apache 2.0. ### Self-Hosted (Only Option) containerd is a daemon that runs on your Linux hosts. Installation is straightforward. Package managers have it, or download the binary. Configuration is a single TOML file. Kubernetes distributions (K3s, RKE2, kubeadm) handle containerd setup for you. ### Resource Usage Minimal. containerd itself uses ~30-50MB RAM. The containers it runs use whatever they use. This adds essentially zero overhead compared to alternatives. ### Verdict Free infrastructure. You're probably already running it. The "cost" is knowing it exists and how to configure it if something goes wrong.
Semaphore gives you a web UI to manage and trigger your Ansible playbooks and shell scripts. It's a control panel for your DevOps automation. The open source version is useful: you get task scheduling, inventory management, team access controls, and a clean dashboard to see what ran and what failed. For a solo dev or small team managing a handful of servers, this is more than enough. Self-hosting is straightforward: single Go binary, throw it behind a reverse proxy, point it at a Postgres or MySQL database. Semaphore Pro adds LDAP/AD integration, audit logs, and priority support starting at $99/mo. Worth it if you're a growing team that needs enterprise auth. For everyone else, the free version handles the core workflow. Solo devs: use the free version. Small teams (2-10): free version covers you. Growing teams needing LDAP: evaluate Pro. Large orgs: you probably already have AWX or Terraform Cloud. The catch: it's not a CI/CD platform. If you need build pipelines and artifact management, look at Woodpecker CI or Jenkins. Semaphore is specifically for running automation tools through a UI instead of SSH sessions.
Free self-hosted covers everything most teams need. Pay $99/mo only when LDAP or audit logs are required.
### Free Tier (Self-Hosted) The open source Semaphore covers the full core workflow: task templates, scheduling, inventory management, user management, notifications (Slack, Telegram, email), and support for Ansible, Terraform, Bash, and PowerShell. No user limits, no run limits. ### Self-Hosted Setup Single Go binary. Needs a database (Postgres, MySQL, or BoltDB for testing). Minimal resource requirements: runs comfortably on a $5/mo VPS. Put it behind Nginx or Caddy with TLS and you're done. Updates are manual but infrequent. ### Paid Tier: Semaphore Pro - **Starts at $99/mo** for teams - LDAP/Active Directory integration - Audit logging - Priority support - Advanced RBAC ### The Math Self-hosted free: $5-10/mo for a VPS + maybe 2 hours/mo of maintenance. Semaphore Pro at $99/mo makes sense only when your team needs enterprise directory integration. If you're using GitHub OAuth or local accounts, the free version does everything you need. ### Verdict Stay free until LDAP or compliance audit logs become non-negotiable. That's the only real trigger to pay.
Cert-manager automatically provisions and renews TLS certificates. You tell it what domains you need certificates for, it talks to Let's Encrypt (or your internal CA), and your certs just work. No more manually renewing SSL certificates or writing cron jobs to handle expiration. Fully free under Apache 2.0. It's a CNCF project, which means it has serious institutional backing and isn't going anywhere. Works with Let's Encrypt, Vault, Venafi, and most certificate authorities. Installation is a single Helm chart. The catch: this is Kubernetes-only. If you're running Docker Compose or bare metal, look at Caddy (automatic HTTPS built in) or certbot. And while cert-manager itself is simple, debugging certificate issuance failures requires understanding DNS challenges, ACME protocols, and Kubernetes RBAC. When it works, it's invisible. When it doesn't, you're reading three layers of logs.
Free. CNCF-backed, no paid tier. Let's Encrypt certificates are also free.
Fully open source, CNCF project. No paid tier, no hosted version. The certificates from Let's Encrypt are also free. **Zero cost for most setups.** Let's Encrypt covers 99% of use cases. If you need extended validation (EV) or wildcard certs from a commercial CA, those costs come from the CA, not cert-manager. **Ops cost:** Minimal once configured. The main time investment is initial setup (1-2 hours) and occasional debugging when certificate renewals fail (usually DNS or permissions issues).
You define an S3 bucket or RDS instance the same way you define a Kubernetes deployment, with a manifest. Completely free and open source under Apache 2.0. A CNCF incubating project, so it has serious backing. You get providers for all major clouds, the ability to compose custom APIs (called Compositions) that abstract infrastructure for your team, and drift detection built in. If someone changes something in the console, Crossplane reverts it. The catch: the learning curve is steep. You need to understand Kubernetes well before Crossplane makes sense. The abstraction layers (Providers, Managed Resources, Compositions, Claims) are powerful but feel over-engineered for simple infrastructure. If you just need to spin up a few AWS resources, Terraform is simpler. Crossplane shines when you want to offer self-service infrastructure to developers through a Kubernetes-native API. Solo: use Terraform instead. Crossplane is overkill. Small teams: still probably Terraform. Platform teams at growing companies: this is where Crossplane starts to make sense. Large orgs building internal platforms: Crossplane's sweet spot.
Free. The real cost is the Kubernetes expertise required and the operational complexity of running it.
### Fully Free Crossplane is 100% free and open source under Apache 2.0. CNCF incubating project. No paid tier from the core project. ### Self-Hosted Setup Installs as a Helm chart into an existing Kubernetes cluster. Requires a running cluster (obviously). Provider packages install separately for each cloud (AWS, GCP, Azure, etc.). The control plane adds resource overhead to your cluster. Budget 1-2GB RAM for Crossplane + providers. ### What You Get for $0 - Cloud provider controllers (AWS, GCP, Azure, and 50+ more) - Compositions, create custom infrastructure APIs - Drift detection and reconciliation - Kubernetes-native RBAC for infrastructure access - GitOps compatible (works with ArgoCD, Flux) ### The Math Crossplane: $0. Terraform Cloud Team: $20/user/mo. Pulumi Team: $50/user/mo. The cost of Crossplane is the Kubernetes cluster it runs on (which you probably already have) and the significant ops investment in learning and maintaining it. ### Verdict Free and powerful, but the real cost is complexity and expertise. Worth it for platform teams building self-service infrastructure. Overkill for simple IaC needs.
Dagger is CI you can run on your laptop. Write build and test steps as code, or install an official module for Go, pytest, ESLint or Playwright, and the same checks run locally, on your server, or in Dagger Cloud. The engine is Apache 2.0 and free. Version 1.0 hit beta on October 23, 2026, repositioned as full CI built for coding agents.
Locally it's a brew install plus Docker. Team self-hosting is real work: shared engines on big persistent disks (the docs push a Helm chart), and GitHub Actions or GitLab CI still starts the jobs. The engine's TCP port has no authentication, so keep it private.
Dagger Cloud is the paid part: managed engines, shared cache, traces, and Cloud Checks that run on every GitHub push with no workflow file. It bills usage against a monthly minimum: $20 for one user, $200 for unlimited users. No free Cloud tier, just a trial. Solo: free engine. Small teams: self-host one engine, or Scale. Larger teams: Enterprise for SSO.
The catch: 1.0 is a beta with breaking CLI changes, and the hosted CI pitch is days old. A GitHub Actions setup that already works rarely justifies the move.
The engine is free forever, self-hosted or on your laptop. Dagger Cloud is usage-billed with a $20/mo minimum for one person or $200/mo for a team, so a team on Scale pays at least $2,400 a year.
**Free:** The Dagger Engine and CLI are open source under Apache 2.0 and run on your laptop or your own servers at no cost. Local runs, the terminal trace UI, official modules and SDKs are all free. **Self-hosted:** Run shared engines for your team yourself. The docs recommend the official Helm chart on Kubernetes, one engine per persistent node with large fast disks, and a CI runner from another platform (GitHub Actions, GitLab CI) to start each job and run `dagger check` against the engine. Plain `tcp://` engine addresses have no authentication, so they belong on a private network. You also do your own cache balancing: Dagger Cloud's scheduler is not part of the self-hosted setup. **Paid:** Dagger Cloud bills actual pipeline usage: 0.5¢/CPU-min and 0.5¢/GB-min of memory for new work, 0.1¢ for repeat work that could be served from cache, plus 2.5¢/GB pipeline inputs and 10¢/GB outputs (0.5¢ and 2¢ for repeat work). You pay the plan price or your usage, whichever is higher, invoiced monthly. Starter is a $20/mo minimum for 1 user with 1 month of trace retention. Scale is a $200/mo minimum with unlimited users, access control and 1 year of traces. Enterprise is custom and adds SSO and 24/7 support. Both self-serve plans start with a free trial; there is no permanent free Cloud tier.
Ansible configures servers, deploys applications, and automates IT work across dozens or thousands of machines by describing what you want in YAML instead of writing shell scripts. No agents on the target machines; it connects over SSH and runs commands. That simplicity is why it became the default. GPL v3, Python, Red Hat owns it. You write playbooks, YAML files describing desired state, and Ansible connects to your servers and executes them. Thousands of community modules cover everything from AWS provisioning to Cisco router configuration. The CLI is fully free. Red Hat sells Ansible Automation Platform on top: a web dashboard, RBAC, audit trails, execution environments, and certified content, priced by quote rather than published. Solo and small teams: the free CLI does everything, run from a laptop or a CI server. Medium teams reach for AWX, the free upstream of AAP's web UI, but check its status first: no release since July 2024 while the project is refactored. Large orgs: RBAC, compliance trails, and certified modules start justifying a quote past 50 people touching infrastructure. The catch is that YAML-as-code hits a wall. Complex logic in playbooks is painful, Jinja2 templating inside YAML is ugly and hard to debug, and the agentless SSH model runs slower than agent-based tools at scale. Past a thousand nodes, Ansible needs careful tuning to keep up.
The CLI is free under GPL v3 and does the real work. Red Hat does not publish Automation Platform pricing; it is quote-only and sized on your estate. AWX is the free middle ground, but it has not shipped a release since July 2024.
### Free Tier The Ansible CLI, fully open source under GPL v3. All modules, all playbook features, community Galaxy roles. AWX, the open source web UI, is free as well, though you self-host and maintain it. ### Paid (Red Hat Ansible Automation Platform) Red Hat does not publish AAP prices. Their pricing page lists support tiers and sends you to sales: - Standard: 9 AM to 5 PM support, maintenance and upgrades, full access to the platform. - Premium: 24x7 support, otherwise the same access. Deployment is self-managed on your own infrastructure or cloud, or consumed as a managed service. Subscriptions are sized on your estate, so the figure depends on how many nodes you manage. Any dollar amount you find on a third-party page is unsourced; the only real number comes from a quote. ### AWX as the Middle Ground, With a Caveat AWX gives you the web UI, REST API, and task engine for free, and it is the upstream of AAP. Know its state before building on it: the last release was 2 July 2024, and the project has paused releases during a refactor into a pluggable, service-oriented architecture. You can still run it, and plenty of teams do, but you are running a two-year-old release while that rebuild happens. Budget 4 to 8 hours a month of ops for a production instance. ### When to Pay Pay when you need RBAC, audit trails for compliance, Red Hat certified content, or a support contract with an SLA behind it. Most teams under 50 people never get there. If the web UI is the only thing pulling you toward AAP, run AWX first and find out whether the ops burden actually bothers you.
Knative Serving brings serverless, scale-to-zero workloads to Kubernetes. Instead of paying for idle pods, your services sleep and wake up on demand. Like AWS Lambda but on your own infrastructure. Apache 2.0. CNCF incubating project. Knative handles request-based autoscaling (including scale-to-zero), traffic splitting for canary deployments, automatic TLS, and revision management. You deploy a service, and Knative manages the lifecycle. Fully free. No paid tier from the project. Google Cloud Run is built on Knative if you want managed. The catch: Knative adds significant complexity to your cluster. It requires a networking layer (Istio, Kourier, or Contour), and the cold start latency when scaling from zero can be seconds, not milliseconds. If your services need instant response times, scale-to-zero defeats the purpose. And the resource overhead of Knative's own components (controller, activator, autoscaler, networking) means it only makes sense if you're running enough services that the savings from scale-to-zero outweigh the platform cost.
Free. Self-host on Kubernetes. Google Cloud Run is the managed alternative if you don't want the complexity.
Fully open source under Apache 2.0. No paid tier. CNCF incubating project. ### Managed Alternatives Built on Knative - **Google Cloud Run:** Free tier (2M requests/month, 360K GB-seconds), then $0.00002400/vCPU-second - **IBM Code Engine:** Free tier available, pay per use after ### Self-Hosted Costs Knative components consume ~500MB-1GB RAM in your cluster. The real cost is the networking layer: Istio adds another ~1-2GB. Kourier is lighter (~100MB) but less feature-rich. On a 3-node cluster, Knative's overhead is ~10-15% of resources. ### The Math If you run 20 services that are idle 80% of the time, scale-to-zero saves ~80% of their compute cost. On 20 services at 512MB each, that's 8GB RAM saved. At ~$0.05/GB/hr on cloud VMs, that's ~$290/mo savings. Minus Knative's own overhead (~$50/mo equivalent), net savings ~$240/mo.
OpenTofu is the community fork of Terraform that stays truly open source. It's a drop-in replacement for Terraform, maintained by the Linux Foundation. MPL-2.0 licensed. You take your existing Terraform configs (.tf files), point them at OpenTofu instead, and everything works. Same HCL language, same provider ecosystem, same state management. The migration is almost trivial for most setups. Fully free. No paid tier from the project itself. Companies like Spacelift, env0, and Scalr offer managed OpenTofu platforms, but the CLI tool is free forever. The catch: OpenTofu tracks behind Terraform on new features: HashiCorp has more engineers. Some newer Terraform features (like the testing framework improvements) take time to land in OpenTofu. The provider ecosystem is shared, but if HashiCorp ever changes how providers work in an incompatible way, OpenTofu has to adapt. For most teams, this doesn't matter; infrastructure code doesn't need cutting-edge features. But if you're on the Terraform bleeding edge, check feature parity before switching.
Free forever. The value is open source licensing, not cost savings over Terraform CLI.
Fully open source under MPL-2.0. The OpenTofu CLI is free with no paid tier. **Managed platforms (third-party):** - Spacelift: from $40/mo for state management and policy - env0: free tier available, paid from $35/mo - Scalr: enterprise pricing **Comparison to Terraform:** - Terraform CLI: now BSL licensed, free to use but not truly open source - Terraform Cloud: free for up to 500 managed resources, then $20/user/mo - HCP Terraform Plus: $50/user/mo Switching to OpenTofu saves $0 on the CLI (both are free to use) but gives you genuine open source licensing and community governance.
Push a commit, cluster updates itself. Flux is a GitOps tool that makes Git the source of truth for your infrastructure. It watches your Git repos and container registries, detects changes, and reconciles your cluster to match. No CI/CD pipeline needed for deployments. Git IS the pipeline. Fully free under Apache 2.0. CNCF graduated project. You get Git repository syncing, Kustomize and Helm support, image update automation, multi-tenancy, and notifications (Slack, Teams, webhooks). It runs as a set of controllers inside your Kubernetes cluster. The catch: Flux is Kubernetes-only. If you're not on Kubernetes, this isn't for you. The learning curve assumes you already understand Kubernetes concepts (CRDs, controllers, namespaces, RBAC). Debugging reconciliation failures requires understanding both Flux's logic AND Kubernetes internals. And compared to Argo CD (the other major GitOps tool), Flux has no built-in UI; you either use the CLI or third-party dashboards like Weave GitOps.
Free. CNCF graduated with strong community support despite Weaveworks' closure.
Fully open source under Apache 2.0. CNCF graduated. No paid tier from the Flux project itself. **Commercial offerings:** Weaveworks (Flux's original corporate sponsor) went bankrupt in 2024. ControlPlane and others now provide commercial support. Weave GitOps (the dashboard) has both free and enterprise versions. **Self-hosting costs:** Flux controllers consume minimal resources: 256MB-1GB RAM total. The cost is your Kubernetes cluster itself, not Flux. **Comparison:** Argo CD (also CNCF, also free) includes a web UI out of the box. If you want a visual dashboard for GitOps, Argo CD is more turnkey. Flux is more composable and lightweight if you're comfortable with the CLI.
Woodpecker is a self-hosted CI engine that's dead simple to set up. It's a community fork of Drone CI, after Drone went commercial. Apache 2.0, Go. The YAML pipeline syntax is nearly identical to Drone's. Docker-based execution means each step runs in an isolated container. Supports GitHub, GitLab, Gitea, Forgejo, and Bitbucket. Multi-platform: Linux, ARM, Windows agents. Fully free. No paid tier, no premium features, no hosted offering. Everything (parallel pipelines, matrix builds, secrets management, cron jobs) is included. Self-hosting is straightforward. One server + one or more agents. A small VPS ($5-10/mo) handles most projects. Docker Compose gets you running in under 15 minutes. The ops burden is light. It's a Go binary, not a Java monstrosity. Solo to small teams: perfect. You get unlimited CI minutes for the cost of a cheap VPS. Medium teams: works well with multiple agents for parallel builds. Large teams: possible, but you'll miss the plugin ecosystem and enterprise features that Jenkins or GitLab CI offer. The catch: the plugin ecosystem is smaller than Drone's was, and vastly smaller than GitHub Actions or GitLab CI. If you need a niche integration, you might be writing your own. And the community, while active, is small. Fewer tutorials and Stack Overflow answers.
Free. Self-host on a $5 VPS and never think about CI billing again.
Fully open source under Apache 2.0. No paid tier, no hosted offering, no enterprise edition. All features (parallel pipelines, matrix builds, cron, secrets, multi-platform agents) are free. Your only cost is the server to run it on ($5-10/mo for a VPS).
Nomad runs containers, VMs, and standalone executables across a cluster of servers without the complexity of Kubernetes. It's a workload orchestrator: you tell it 'run 3 copies of this service' and it handles placement, restarts, rolling updates, and health checks. What's free: The Nomad binary is free to download and use. Source-available under BSL 1.1 (same license change as Terraform). All core scheduling, service mesh (Consul integration), and multi-region features work without paying. Nomad's pitch is simplicity. A single binary, no etcd, no API server fleet. Just nomad agent on your nodes. You can go from zero to a running cluster in 30 minutes. It handles Docker containers, Java JARs, raw executables, even Windows services. That flexibility is rare. The catch: the BSL 1.1 license means it's not truly open source anymore. You can use it freely but competitors can't build products on it. The ecosystem is a fraction of Kubernetes' size. Fewer tutorials, fewer integrations, fewer people who know it. And while it's simpler than K8s, 'simpler' still means distributed systems complexity. You'll want Consul for service discovery and Vault for secrets, pulling you deeper into the HashiCorp ecosystem.
Binary is free. Self-host a cluster for $25-200/mo. HCP managed starts at ~$22/mo if you don't want the ops burden.
### What's Free The Nomad binary and all core features. Job scheduling, multi-region federation, service mesh (with Consul), CSI volumes, Sentinel policies. BSL 1.1 license: free to use, restricted for competing products. ### HCP Nomad (Managed) HashiCorp Cloud Platform offers managed Nomad: - **Development**: ~$0.03/hr (~$22/mo) for a small cluster. - **Standard**: ~$0.08/hr (~$58/mo). Multi-node, production-ready. - **Plus/Enterprise**: Custom pricing. SSO, audit logging, dedicated support. ### Self-Hosting Cost - **Minimum viable**: 3 server nodes + N client nodes. On cheap VPSes ($5-10/node), a small cluster runs $25-60/mo. - **Production**: 3-5 server nodes with 4GB+ RAM each. $60-200/mo depending on provider. - **You'll also want**: Consul ($0 self-hosted) + Vault ($0 self-hosted, paid for cloud). ### The Kubernetes Comparison Nomad is cheaper to operate at small scale. A 3-node Nomad cluster needs ~1GB RAM per server. A comparable K8s control plane needs ~2-4GB. The real savings are in ops time -- Nomad's simpler architecture means less to debug. ### When to Pay for HCP When you don't want to manage the server cluster. HCP handles upgrades, backups, and HA. Worth it at $22-58/mo if your time is worth more than $20/hr.
Packer builds identical machine images for AWS, Azure, GCP, and VMware from the same configuration, defined in code. Packer does that. Instead of manually configuring a server and hoping you remember every step, you write a template that says "start with Ubuntu, install these packages, configure these settings" and Packer builds the image automatically.
The entire tool is free under the BSL license (business source license, free for most use cases, restricted for competing managed services). No paid features, no cloud tier from HashiCorp specifically for Packer. You download the binary and run it.
There's nothing to host; it's a CLI tool that runs on your machine and talks to cloud APIs. Install it, write a template in HCL or JSON, run packer build. It creates the image in your cloud provider and exits. Ops burden is trivial. Solo developers: useful if you're automating infrastructure. Otherwise, a manual AMI snapshot works fine. Small teams: Packer templates in version control mean everyone builds the same image. Growing teams: this is where it shines: golden images across multiple clouds, baked into your CI/CD.
The catch: Packer solves one problem well but it's only the image layer. You still need Terraform or similar to deploy those images. And the BSL license change in 2023 upset the open source community; if you're philosophically opposed, look at alternatives.
Completely free CLI tool. Only costs are cloud provider charges for build instances and image storage.
### Free Everything. Packer is a standalone CLI tool with no paid tier. All builders (AWS, Azure, GCP, Docker, VMware, etc.), provisioners, and post-processors are included. The BSL license is free for all use cases except building a competing managed Packer service. ### Self-Hosted (Only Option) Packer runs on your local machine or in CI. Download the binary or use your package manager. No server to maintain, no database, no background processes. It runs, builds your image, and exits. ### Real Costs Your cloud provider charges for the temporary instances Packer spins up during builds. An AWS build typically runs a t3.micro for 5-15 minutes, pennies. The images themselves have storage costs (EBS snapshots on AWS: ~$0.05/GB/month). ### HCP Packer (Optional Cloud Service) HashiCorp Cloud Platform offers a managed image registry that tracks which images are built, where they're deployed, and flags revocable images. Free tier: 10 managed images. Plus tier: $50/mo for more. This is optional metadata management; Packer itself works fine without it. ### Verdict The tool is free. Your only costs are cloud provider charges for build instances and image storage.
Caddy-docker-proxy reads your Docker labels and configures Caddy automatically. Add a label to your container saying "this is app.example.com" and caddy-docker-proxy handles the routing, SSL certificate, and renewal. Zero config files. Fully free under MIT. It's a Caddy plugin that watches the Docker socket for container events and generates Caddy configuration on the fly. Works with Docker Compose and Docker Swarm. Every container gets HTTPS automatically via Let's Encrypt. The catch: it's Docker-only. If you're on Kubernetes, use Traefik or an ingress controller. The Docker labels syntax has a learning curve. Complex routing rules (path-based routing, headers, redirects) get verbose as labels. And because it watches the Docker socket, it needs elevated permissions, which is a security consideration. For simple setups with 5-15 containers, it's magic. For complex routing, you might want a proper Caddyfile instead.
Free. Caddy + Let's Encrypt + Docker labels. No cost beyond your server.
Fully open source under MIT. No paid tier. **Zero cost.** Caddy itself is free (Apache 2.0). Let's Encrypt certificates are free. You pay for your server and Docker hosting. **Compared to alternatives:** - Traefik: Also free, also reads Docker labels, more features but more complex config - Nginx Proxy Manager: Free, GUI-based, but manual certificate management - Coolify: Includes reverse proxying as part of its PaaS, more features, more overhead caddy-docker-proxy is the simplest path from Docker labels to working HTTPS.
Kargo orchestrates that promotion pipeline. Consider it a GitOps-native way to move application versions through stages with approval gates and verification steps. Apache 2.0, Go. Built by the creators of Argo CD. Kargo doesn't replace your CI. It sits on top of your GitOps tools (Argo CD, Flux) and manages the lifecycle of getting a change from one environment to the next. It watches for new container images or Helm chart versions and can auto-promote or require manual approval. Fully free and open source. No paid tier currently. Akuity (the company behind it) offers a managed Argo CD platform but Kargo itself is free to self-host. Self-hosting requires a Kubernetes cluster (it runs as a controller). Setup is straightforward if you already have Argo CD running. Ops burden is moderate. It's another controller to monitor. Solo: overkill unless you're learning GitOps. Small teams with multiple environments: this is where Kargo starts making sense. Medium to large: strong fit for managing promotion across many services. The catch: it's young. The API is still evolving, documentation is thin in places, and you're locked into the GitOps model. If you're not already using Argo CD or Flux, adopting Kargo means adopting GitOps first.
Free. Self-host on your Kubernetes cluster. No paid tier exists.
Fully open source under Apache 2.0. No paid tier for Kargo itself. Akuity offers managed Argo CD (separate product) but Kargo is free to self-host. No feature gating.
Cozystack turns a rack of bare-metal servers into your own cloud. It runs on Kubernetes and hands you an API to provision Kubernetes clusters, virtual machines, managed databases, and load balancers, the same primitives you'd otherwise rent from AWS or a managed provider. Apache 2.0 licensed, free, and a CNCF Sandbox project. This is infrastructure for people who run infrastructure. You bring the hardware and a working Kubernetes base; Cozystack layers the cloud services on top. Hosting providers use it to resell managed Kubernetes and VMs; large orgs use it to build a private cloud their internal teams self-serve from. Setup is real work: networking, storage, and the underlying cluster all have to be solid before Cozystack earns its keep. Solo and small teams: skip it. If you just want to deploy an app, Coolify or Dokku get you there in an afternoon. Cozystack is overkill until you're handing out infrastructure to other teams or customers. Where it shines is the org or provider that would otherwise stand up OpenStack or pay for VMware. You get a modern, Kubernetes-native control plane without the licensing bill. The catch: this is a platform you operate, not a product you consume. There's no managed Cozystack to fall back on when something breaks at 2am, and the people who run it well already know Kubernetes cold. If that's not your team, you're signing up to babysit a second full-time system.
Free and open source (Apache 2.0). The real cost is the platform engineering time to run it; commercial support is available from partners.
**Free:** The entire platform is Apache 2.0 and free to run. No feature gating, no per-node licensing. **Self-hosted:** This is the only way to run it. Budget for bare-metal or VM hardware plus the engineering time to operate Kubernetes underneath it. The software cost is zero; the operational cost is a platform engineer's attention. **Paid:** No first-party paid tier. Commercial support is available from Ænix and partner companies if you want an SLA behind your cloud.
KWOK stands for Kubernetes Without Kubelet. It simulates a Kubernetes cluster with fake nodes and fake pods, so you can test scheduling, controllers, autoscaling, and cluster-wide behavior without paying for real infrastructure. The maintainers claim it holds 1,000 nodes and 100,000 pods on a laptop with low CPU and memory overhead, and creates resources at 20 per second.
Install is a pre-built binary or a Docker image, plus kwokctl to manage simulated clusters the way kind or minikube manages real ones. It speaks the standard Kubernetes API, so kubectl, helm, and any custom controllers you've written work against it unchanged. Configure node types, labels, taints, and pod behaviors to mirror your production setup.
Solo developers writing operators or controllers: this is the right tool for unit testing at scale. Platform teams validating multi-cluster configurations or testing scheduler changes: KWOK is cheaper than spinning up real clusters and faster than waiting for pods to actually schedule. Large teams running chaos and failure scenario tests: ideal.
The catch: KWOK simulates the control plane, not the data plane. It will not catch container runtime bugs, networking issues, or anything that depends on real workloads executing. Use it alongside real cluster tests, not as a replacement for them.
Free Kubernetes SIG project. Simulates clusters on hardware you already own.
**Free:** Apache 2.0, full source, no enterprise tier. SIG project under the Kubernetes organization. **Self-hosted:** Runs on your laptop or CI runners. No infrastructure required beyond the machine you're already using. **Paid:** None. It's a Kubernetes SIG project; there is no commercial version.
Fleet keeps Kubernetes clusters in sync with a Git repo, and it was built for the case where you have a lot of clusters. Put raw YAML, Helm charts, or Kustomize in Git and Fleet deploys it to one cluster or a large fleet, turning everything into Helm releases under the hood. Apache 2.0, free, and made by Rancher, now part of SUSE. You need a Kubernetes cluster and Helm already. Install is two Helm charts. For many clusters you run a manager cluster plus an agent in each downstream cluster. The agents pull from the manager, so clusters behind NAT or on private networks work without inbound access. That pull design is why it suits edge deployments. It also comes preinstalled in Rancher as Continuous Delivery. Solo and small teams with one or two clusters: free, but argoproj/argo-cd and fluxcd/flux2 are the more common picks, and Argo CD ships its own web UI. Medium and large teams already on Rancher: use it, it is already there. Paid support means SUSE Rancher Prime, and SUSE does not publish the price. The catch: it is still 0.x with v1alpha1 APIs after six years. At scale the bottleneck is etcd, because stored objects grow as clusters times bundles. The docs warn against polling Git at scale and admit a GitRepo can get stuck in a Failed state under high load.
Completely free and open source. Paid support exists through SUSE Rancher Prime at unpublished, quote-only pricing.
**Free:** Everything. Apache 2.0 GitOps and HelmOps controllers, per-cluster agents, and a CLI. Works standalone on any community-supported Kubernetes version, or preinstalled inside Rancher. **Self-hosted:** The only way it runs. Two Helm charts on an existing cluster. Multi-cluster means a manager cluster plus an agent on every downstream cluster, with etcd object count as the scaling limit. **Paid:** No hosted Fleet. Commercial support comes through SUSE Rancher Prime, where Fleet is sold as Continuous Delivery with 24x7 support. SUSE lists it as request pricing and publishes no number.
k8s-config-connector is Google's official Kubernetes controller for managing GCP resources, Cloud SQL, GCS buckets, Spanner, IAM, as Kubernetes manifests. Write YAML, kubectl apply, and a controller in your cluster keeps the GCP-side resources synced. Apache 2.0 and free. This is the GCP-native answer to 'I'd rather declare infrastructure than click through a console or maintain a separate Terraform repo.' Install the controller, give it a service account, and your CI pipeline can manage cloud resources the same way it manages workloads. It uses the standard CRD pattern, so kubectl, kustomize, and GitOps tools work out of the box. For teams already running everything through Kubernetes manifests on GCP, this collapses two infrastructure systems into one. Solo developers running a small GCP project: trivial to add. Larger teams get unified RBAC, GitOps workflows, and a single deployment surface for app and cloud resources. The closest comparison is Crossplane, but Config Connector is single-cloud and Google-maintained. The catch: it only manages GCP, so any multi-cloud story still needs Terraform or Crossplane on the side. The controller is one more critical thing to run in your cluster, and resource drift between the cluster's view and the GCP console is a real category of bug you'll occasionally chase. A complex Terraform setup that works is not automatically worth replacing.
Free and open source under Apache 2.0. The GCP resources it provisions still bill at standard Google Cloud rates.
**Free:** The full controller, Apache 2.0, Google-maintained. **Self-hosted:** Install as a Kubernetes controller in your cluster, give it a GCP service account, apply CRD manifests for the GCP resources you want. **Paid:** None directly. The cloud resources you provision (Cloud SQL, GCS, and so on) bill at GCP standard rates.
Doco-CD is GitOps for Docker Compose. Point it at a Git repo containing your docker-compose.yml, and it automatically deploys when you push. Webhooks or polling, your choice. ArgoCD stripped down to just Docker Compose, without the Kubernetes complexity. Runs as a single container with minimal RAM. Supports multiple Git providers, external secret management with SOPS encryption, Prometheus metrics for monitoring deployments, and built-in notifications. Also works with Docker Swarm stacks if you have graduated past single-host Compose. Solo developers and small teams running Docker Compose in production (and there are more of you than the Kubernetes crowd admits): this gives you automated deployments without learning Kubernetes, Helm, or ArgoCD. Push to main, services update. The catch: if you need canary deployments, rolling updates with health checks, or multi-cluster orchestration, you have outgrown this tool. It does one thing and does it well.
Completely free and open source. Apache 2.0 license, no restrictions.
## Free Tier Full tool, all features. Apache 2.0 license. ## Self-Hosted Single container, minimal resources. Trivial to deploy alongside your Compose stack. ## Paid No paid tier. Completely community-driven.
Ingress NGINX is retired. It was the Kubernetes project's own ingress controller: the piece that takes outside web traffic and routes it to the right service in your cluster, using NGINX and rules you write in YAML. Kubernetes stopped maintaining it in March 2026 and made the repo read-only on March 24, 2026. Still free under Apache 2.0. Existing deployments keep running, and charts and images stay available. What's gone is patching: no releases, no bug fixes, no security fixes. The final release, v1.15.1, bundles NGINX 1.27.1. Chainguard keeps a free fork that has been backporting NGINX CVE fixes on a best-effort basis, and sells patched images with a remediation SLA. Everyone should migrate. Kubernetes points you to Gateway API, the newer routing standard, through a controller like Envoy Gateway, Traefik or NGINX Gateway Fabric. The ingress2gateway tool converts existing Ingress objects. Solo and small teams: do it now. Medium and large teams: Chainguard's fork buys time while you test. The catch: its 2026 CVEs shared one shape. A crafted Ingress injects config into NGINX, giving code execution and, in the default install, every Secret in the cluster. The last fix shipped days before the archive. The next one won't.
Free, but unpatched upstream since March 2026. Budget engineering time to migrate to Gateway API, or pay Chainguard for patched images while you do.
**Free:** Apache 2.0. The final controller releases (v1.15.1, v1.14.5, v1.13.9) and Helm charts stay available. No further releases, bug fixes or security updates from the Kubernetes project. **Self-hosted:** Runs as controller pods inside your cluster. Nothing to pay, but every NGINX or controller vulnerability found from here on stays open upstream. Chainguard maintains a free Apache 2.0 fork (chainguard-forks/ingress-nginx) that has backported NGINX CVE fixes onto the bundled NGINX 1.27.1, on a best-effort basis. **Paid:** No paid tier from Kubernetes. Chainguard sells commercial ingress-nginx container images under its remediation SLA (contact sales, no public price). The real cost is engineering time to migrate to a Gateway API controller, helped by the free ingress2gateway converter.
These are the official Docker images. Alpine, Debian, Ubuntu variants. You pull the image, write your Dockerfile, and your Deno app runs in a container. This isn't a tool you evaluate. It's infrastructure. If you use Deno, you use these images (or build your own, which is more work for no benefit). The images are maintained by the Deno team and track Deno releases. Everything is free. Official Docker images, MIT licensed. The catch: this is a Docker image repository, not a standalone tool. If you're not already using Deno, this isn't relevant. If you are using Deno, you probably already found these on Docker Hub. The Alpine variant is ~40MB, which is great for image size. The main thing to watch: Deno updates frequently, and pinning to a specific version in your Dockerfile (which you should do) means manually bumping versions.
Free. Official Docker images, nothing to pay for.
Free. Official Docker images distributed through Docker Hub at no cost. MIT licensed. **Cost of use:** $0 for the images. Your container hosting costs (ECS, GKE, a VPS with Docker) are separate and depend on your infrastructure choices.
Zadig is a self-hosted DevOps platform from KodeRover, a Shanghai company, for building, testing and deploying dozens of microservices on Kubernetes. It runs the whole product in parallel instead of one pipeline per service, and spins up isolated test environments per developer. The Basic Free Edition covers workflows, test environments, code scanning and RBAC. You need a Kubernetes cluster: the docs recommend 8 CPU cores and 16GB of RAM, and Zadig itself takes 4 cores and 8GB. The Helm chart can bundle MinIO, whose community repo was archived in April 2026, so use external storage. The paywall sits on production. Production environments, canary and blue-green releases, LDAP login and audit logs need Expert Edition at ¥119 (about $18) per person per month. The advertised AI agents are Enterprise only, quote on request. Solo and small teams: free for test environments, pay to ship to prod. Larger teams: Enterprise. The catch: the README says Apache 2.0, but the LICENSE adds conditions. Selling or embedding it needs KodeRover's permission, multi-tenant SaaS is banned, and contributors agree the license can change. That's source-available. Approvals are built around Feishu, DingTalk and WeCom; most Western teams will fit GitHub Actions or Argo CD better.
Free for building and testing in non-production environments. Shipping to production with canary or blue-green releases means Expert at ¥119 (about $18) per person per month, and the AI agents are Enterprise only.
**Free:** Basic Free Edition: multi-service concurrent workflows, shared builds, test environment management, test management, code scanning, GitHub/GitLab and other code hosts, Linux/macOS/Windows host builds, standard Kubernetes clusters, a template library, built-in accounts and RBAC. Community self-upgrade only. **Self-hosted:** All editions are private deployments on your own Kubernetes (v1.16+, recommended 8 cores/16GB; Zadig itself uses 4 cores/8GB for two concurrent workflow tasks) via Helm or a one-click script, plus an all-in-one host install for trials. Built-in MySQL, MongoDB and MinIO are optional; MinIO's community edition was archived in April 2026, so use external object storage. **Paid:** Expert Edition ¥119 (about $18) per person per month, aimed at teams under 30: production environment management, GitOps, canary and blue-green releases, Nacos/Apollo config and SQL changes, AD/LDAP/OAuth login, ABAC, audit logs, cloud registry support. The page does not say whether this is billed monthly or annually. Enterprise Edition (teams over 50) is custom priced with a 30-day trial: built-in AI review and AI release agents, Istio/MSE full-link canary, Jira integration, release planning, multi-project efficiency analysis. Licenses cap users; past the cap, new users cannot log in. An expired license falls back to free features.
MASH Playbook is an Ansible playbook that deploys 230+ self-hosted FOSS services via Docker: Nextcloud, Gitea, Vaultwarden, PeerTube, Grafana, and more. Shared infrastructure including Traefik, Postgres, and Let's Encrypt is managed centrally. AGPL-licensed and free. You need a Linux server with Docker and Ansible knowledge. The playbook handles routing, certificate management, and database sharing across services. Initial setup takes hours, not minutes. Each service runs in its own container, and the configuration is unified in one inventory file. Self-hosters who want to run multiple services systematically instead of managing each Docker Compose stack separately will find this valuable. Yunohost and Caprover are simpler for non-technical users. MASH is the right tool if you want Ansible-driven reproducibility and flexibility to mix services from different upstream projects. The catch: 230+ services means update coordination is ongoing work. AGPL licensing is fine for personal use but requires source disclosure if you modify and distribute it commercially.
Fully free; only cost is your own server.
**Free tier:** AGPL-licensed, completely free. **Self-hosted:** Your server + Docker + Ansible. No software licensing cost. **Paid:** No paid tier.
Lift provides pre-built constructs that plug into your serverless.yml. It's essentially higher-level building blocks for AWS infrastructure alongside your Lambda functions. MIT license, TypeScript. Lift adds constructs like 'website' (S3 + CloudFront), 'queue' (SQS), 'storage' (S3), 'database' (DynamoDB), and 'webhook' with sensible defaults. Instead of 50 lines of CloudFormation, you write 3 lines of YAML. Fully free and open source. No paid tier. However, the Serverless Framework itself has gone through licensing changes; Serverless Framework v4 requires a paid subscription for organizations above a certain size. Lift is an MIT plugin, but it only works with the Serverless Framework. Solo developers on Serverless Framework: useful time-saver. Everyone else: look at SST or AWS CDK instead. The catch: Lift's value is tied entirely to the Serverless Framework ecosystem. If you're not using Serverless Framework, this does nothing for you. And with the Serverless Framework's licensing changes pushing larger teams toward alternatives like SST, CDK, or Terraform, Lift's future relevance is uncertain. The project appears to be in maintenance mode.
Free plugin, but check Serverless Framework v4 licensing for your org size.
Lift itself is fully open source under MIT. No paid tier. But it requires the Serverless Framework, which has paid tiers for organizations with >$2M revenue (Serverless Framework v4). The plugin is free; the host framework may not be.
Webernetes runs a Kubernetes cluster entirely in your browser, no backend, no real infrastructure. You boot a cluster and create Pods, Services, Deployments, and Namespaces, define container images in TypeScript, and watch HTTP and DNS traffic move between them. Built by ngrok for teaching and demos, Apache-2.0, free, and published as an npm package with a live demo. Because it is a simulator, setup is trivial and there is nothing to provision. It models a useful subset of Kubernetes resources so the behavior feels real enough to learn from, without the cost or wait of a live cluster. The trade is obvious: it is not real Kubernetes and will not run production workloads, by design. This is for educators, content authors, and developers learning Kubernetes who want hands-on cluster behavior without spinning up infrastructure. Solo or team, it is free. If you need a real cluster, or features beyond the supported core resources, reach for the real thing: kind, k3s, or minikube for local work, a managed cluster for production. The catch is the boundary of the simulation. Webernetes is a teaching tool, and a clever one, but the moment you need behavior it does not model, you are back to a real cluster. Use it to build intuition, not to validate production config.
Completely free and open source. A client-side library, nothing to host.
**Free tier:** Apache-2.0 and fully free, published as the npm package @ngrok/webernetes with a live demo. **Self-hosted:** It is a client-side library that runs in the browser. Nothing to provision. **Paid:** None.