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.
Running containers on one machine is easy. Running them across a fleet, surviving failures and traffic spikes, is not. Kubernetes is the operating system for that. It takes your containers and distributes them across a cluster of machines, handles networking between them, restarts crashed processes, and scales up when traffic spikes. What's free: Everything. Apache 2.0 license. The entire Kubernetes project is free and open source: API server, scheduler, controller manager, kubelet, kubectl. No enterprise edition, no gated features. Kubernetes won. Every cloud provider offers a managed version, every DevOps engineer is expected to know it. The ecosystem (Helm, Istio, Argo, Prometheus) is massive. If you're building cloud-native infrastructure, K8s is the platform everything else runs on. The catch: complexity. Kubernetes has a brutal learning curve. A production cluster needs monitoring, logging, ingress controllers, cert management, RBAC policies, network policies, storage classes. The list doesn't end. Running your own control plane is a full-time job. Most teams should use a managed service (EKS, GKE, AKS) and even then, you need someone who understands K8s deeply.
Software is free. Managed clusters cost $12-73/mo for the control plane plus node costs. The real expense is engineering time to operate it.
### What's Free Everything. The entire Kubernetes project is Apache 2.0 licensed. No paid tier, no enterprise edition. Every feature CNCF ships is free. ### Self-Hosting Cost (Running Your Own Control Plane) - **Home lab/dev**: Minikube or kind on your laptop. $0. - **Small production**: 3 control plane + 3 worker nodes. On bare VPSes: $60-180/mo. - **Medium production**: 5+ nodes with monitoring, logging, and ingress. $200-1,000/mo. - **You're also paying for**: monitoring (Prometheus/Grafana), logging (Loki), ingress (nginx), cert-manager, etc. ### Managed Kubernetes (What Most Teams Should Use) - **EKS (AWS)**: $0.10/hr (~$73/mo) per cluster + EC2 node costs. - **GKE (Google)**: Free tier for 1 Autopilot cluster. Standard: $0.10/hr per cluster. - **AKS (Azure)**: Free control plane. You pay only for nodes. - **DigitalOcean**: $12/mo for the control plane + $12+/mo per node. ### The Real Cost Kubernetes itself is free. The infrastructure to run it is not. And the engineering time to operate it is the biggest cost of all. A team spending 20 hours/month on K8s ops at $100/hr = $2,000/mo in labor. Managed services reduce this dramatically. ### When Self-Hosting Makes Sense Almost never for the control plane. Use managed K8s. Self-host only if you're on bare metal, have compliance requirements, or are running at massive scale where managed service fees add up.
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.
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.
Terraform lets you define all of it in code files instead of clicking through AWS/GCP/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.
What's free: The CLI tool is free to download and use. You can manage any cloud provider, any scale, no limits. The language (HCL), the state management, the plan/apply workflow. All free.
Terraform is THE infrastructure-as-code tool. Used by everyone from startups to Fortune 500s. Every cloud provider has an official Terraform provider. The ecosystem of modules and providers is unmatched.
The catch: HashiCorp changed Terraform's license from open source (MPL) to source-available (BSL 1.1) in 2023. You can still use it freely, but competitors can't build commercial products on it. This spawned OpenTofu, a community fork under the Linux Foundation. The state file management is also a real pain point. You need remote state storage (S3, GCS, or Terraform Cloud) for any team usage, and state file corruption can ruin your day.
CLI is free forever. Cloud free tier covers 500 resources. Pay ~$1/resource/mo when you need team features or scale past the free tier.
### What's Free The Terraform CLI. Unlimited resources, unlimited providers, unlimited state files. You can manage billions of dollars of infrastructure with the free CLI. ### Terraform Cloud (HCP Terraform) - **Free tier**: 500 managed resources, remote state, 1 concurrent run. Enough for personal projects and small teams. - **Standard**: $0.00014/hr per managed resource (~$1.02/mo per resource). 20 resources = ~$20/mo. - **Plus**: $0.00028/hr per resource. Adds policy-as-code, drift detection, continuous validation. - **Enterprise**: Custom pricing. Self-hosted option, SSO, audit logging. ### What the Paid Tiers Get You Remote state management (huge for teams), run history, policy enforcement (Sentinel), cost estimation, private registry for modules. The free tier's 500-resource limit is genuinely generous. ### The License Situation BSL 1.1 since August 2023. You can use Terraform commercially. The restriction is on building competing products. If you're just using it to manage your infrastructure, nothing changed for you. If the license concerns you, OpenTofu is the Apache 2.0 fork. ### The Math Self-managing state in S3: ~$1/mo + the time to set up and maintain it. Terraform Cloud free tier: $0 for up to 500 resources. Paying makes sense when you need team collaboration features, policy enforcement, or you have 500+ resources.
Dagger lets you build CI/CD pipelines as code that run anywhere. You define build steps as functions, run them locally on your machine, and the same pipeline runs identically in any CI system (GitHub Actions, GitLab, Jenkins, whatever). Apache 2.0, Go. The core idea: pipelines are code, not config files. Everything runs in containers, so "works on my machine" actually means something. You can test your entire CI pipeline locally before pushing. The SDK gives you type-safe build steps with autocomplete in your editor. The open source engine is fully free. Write pipelines, run them locally, run them in any CI, no cost. Dagger Cloud adds caching, pipeline visualization, and debugging tools. There's a free tier. Paid plans haven't been publicly detailed with fixed prices yet, but the cloud offering is where the business model lives. Solo devs: free tier is plenty. Local execution is the killer feature. Small teams: free engine plus Dagger Cloud free tier for shared caching. Medium to large: evaluate Dagger Cloud paid for team-wide cache and observability. The catch: you're adding a layer of abstraction on top of your CI. If your YAML pipelines work fine and your team knows them, the migration cost is real. And while "write CI in TypeScript" sounds great, you're now debugging TypeScript instead of YAML. The complexity moved, it didn't disappear.
Engine is free. Dagger Cloud free tier for basics. Paid for team caching and observability.
### Free Dagger Engine is fully open source under Apache 2.0. Write and run pipelines in TypeScript, Python, or Go. Local execution, any CI system, no restrictions. ### Dagger Cloud Free tier available with pipeline visualization and basic caching. Paid tiers add advanced caching, team features, and debugging tools. Exact pricing not publicly listed. Contact sales for team plans. ### When to Pay Pay when shared caching across a team saves more CI minutes than the subscription costs. The math depends on your CI provider's pricing and pipeline duration.
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.
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).
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.
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.
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.
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.
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.
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.
Dockge gives you a clean web UI for managing Docker Compose stacks: create, edit, start, stop, and monitor containers without touching the terminal. From the same developer who built Uptime Kuma, and it shows. The UI is clean, fast, and does exactly what you expect. TypeScript, MIT. Growing quickly. The design philosophy: one compose file per stack, edit them visually or in the built-in YAML editor, see real-time container logs, and manage everything through a browser. It converts docker run commands into compose files automatically.
Fully free. No paid tier, no cloud version, no premium features behind a wall. Self-hosted only. Installation is a single docker-compose up. It manages your OTHER compose stacks, so it sits alongside your containers, not inside them. The UI shows stack status, lets you pull updates, and handles basic container lifecycle.
Solo developers and homelab users: this is the sweet spot. Managing 5-20 compose stacks through Dockge is pleasant. Small teams: works great for shared dev or staging environments. Medium to large: you probably need Portainer, Rancher, or Kubernetes at that scale.
The catch: Dockge is compose-only. No Docker Swarm, no Kubernetes, no standalone container management. It doesn't do networking configuration, registry management, or advanced orchestration. It's a compose stack manager and nothing more, which is exactly why it's good at what it does.
Free. No paid tier exists or is planned. MIT licensed.
Fully open source under MIT. No paid tier, no hosted version, no premium features. Run it with Docker Compose. Total cost: whatever server you're already running Docker on.
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.
It's the official NGINX-based ingress controller maintained by the Kubernetes project. You define routing rules in YAML, and it configures NGINX to make them happen. Apache 2.0. Handles TLS termination, rate limiting, basic auth, WebSocket proxying, and canary deployments. Pairs with cert-manager for automatic Let's Encrypt certificates. Fully free. No paid tier. This is community infrastructure maintained by the Kubernetes SIG. The catch: NGINX config through Kubernetes annotations is clunky. Complex routing rules turn into annotation soup that's hard to debug. Performance is solid for most workloads, but if you need advanced traffic management (circuit breaking, retries with budgets, traffic mirroring), you'll outgrow it. And there's a confusing namespace issue: this is kubernetes/ingress-nginx (community), not nginxinc/kubernetes-ingress (NGINX Inc's commercial version). Make sure you install the right one.
Free. Community-maintained Kubernetes infrastructure. No paid tier exists.
Fully open source under Apache 2.0. No paid tier, no commercial version (that's the NGINX Inc ingress controller, a different project). Maintained by the Kubernetes community. Your costs are just the compute for the controller pods, typically 1-2 pods running in your cluster, consuming ~100-200MB RAM each.
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.
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.