CI/CD & Build

Last reviewed Aug 26, 2026 · 443 words

Before shopping this category, check what you already run: every modern self-hosted forge ships a built-in CI system, and for a homelab or small team that ends the search. The 21 tools here earn their keep in three specific situations — you run Kubernetes, you have pipelines too gnarly for forge CI, or you want to test workflows without a server at all. Anything from the Git hosting category with Actions support covers the rest.

How to choose a CI/CD tool

The first split is Kubernetes. The Argo family and Tekton are Kubernetes-native by design — pipelines and deployments expressed as cluster resources — and all carry Hard difficulty ratings because they assume you can already operate a cluster. No Kubernetes means that whole shelf is not for you yet. The second split is CI versus CD, which this category files together but which are different jobs: CI tools build and test on every push; CD tools like Argo CD take built artifacts and keep environments in sync with Git. The third axis is configuration style — YAML pipelines everyone can read, or pipelines as real code in a general-purpose language, which newer engines offer at the cost of new concepts to learn.

Where to start

Jenkins (MIT, 26,495 stars, 1 GB minimum) remains the pick when you need something none of the modern tools do, because with thousands of plugins, someone has already built it — the price is a dated UI and plugin management that is genuinely painful; pin a plugin update window in your calendar. Argo CD is the default for Kubernetes delivery: declarative GitOps, automated drift detection, and a first-rate web UI showing exactly what diverged from Git. And act (MIT, 71,634 stars) is the tool most developers should meet first — it runs your GitHub Actions workflow files locally in Docker, on 256 MB, so you stop debugging CI by pushing 14 commits titled "fix ci".

GitOps tools don't build anything

The recurring misconception: installing Argo CD and expecting it to run tests. It will not — it deploys what your CI produced and reconciles cluster state with Git. A complete Kubernetes pipeline is still two systems, CI to build images and Argo CD to roll them out; teams who miss this end up bolting build scripts into places they do not belong.

What I'd do

Forge-integrated CI for builds and tests, act locally so pushes stop being experiments, and nothing else until Kubernetes enters the picture — at which point add Argo CD for delivery and keep the build side exactly where it was.