Lesser-Known CI/CD Tools Worth Knowing About

Last updated 2026-03-31 | SPUNK13 LLC | spunk.bet

The big platforms get all the attention, but most pipeline pain comes from three specific problems: you cannot test changes locally, builds repeat work they already did, and the pipeline is coupled to one vendor. These tools each attack one of those.

act — Run GitHub Actions Workflows Locally

The push-and-pray loop, where each pipeline fix costs a commit and a five-minute wait, is the single largest time sink in CI work. act reads your workflow file and runs the jobs in Docker containers on your machine.

act -j build                    # run one job
act -l                          # list jobs
act pull_request                # simulate a different event
act -s MY_TOKEN=xxx             # supply a secret

It is not a perfect emulation — runner images differ from the hosted ones, and service containers and matrix edge cases can behave differently — but it catches syntax errors, missing steps and bad shell logic in seconds instead of minutes.

Dagger — Pipelines as Code You Can Run Anywhere

Dagger lets you define pipeline steps as containerised functions in Go, Python, TypeScript or PHP, executed through a BuildKit engine. The same definition runs on your laptop and on any CI provider, so the platform becomes a thin trigger rather than the place your logic lives. It also caches at the operation level, so unchanged steps are skipped. The cost is a real learning curve and an extra abstraction; it earns its place when you are running multiple CI systems or planning to migrate between them.

Earthly — Dockerfile Syntax With Makefile Structure

Earthly's Earthfile reads like a Dockerfile with targets. Each target runs in a container, gets cached like a Docker layer, and produces reproducible output regardless of what is installed on the host. For polyglot monorepos where the build currently depends on which language versions a developer happens to have, this removes an entire class of "works on my machine".

Woodpecker CI — Small, Self-Hosted, Container-Native

A community fork of the original Drone, Woodpecker runs pipelines as containers defined in a YAML file and needs very little to operate — a server, an agent, and an OAuth connection to your Git host. For a team that wants CI on its own hardware without running a Kubernetes platform first, it is dramatically less machinery than the alternatives.

Caching Tools That Cut Minutes, Not Seconds

• sccache — a compiler cache for Rust, C and C++ that stores artifacts in local disk, S3, Redis or GCS, so cache hits survive across ephemeral runners. On a large Rust workspace, a warm cache routinely turns a ten-minute build into one or two.
• Turborepo / Nx — content-hash the inputs of each task in a JavaScript monorepo and skip anything unchanged, with a shared remote cache so CI benefits from what a colleague already built.
• BuildKit cache mounts — RUN --mount=type=cache,target=/root/.npm npm ci keeps the package cache across builds without baking it into a layer. This is built into modern Docker and consistently underused.

Security Steps That Take One Line

Trivy scans container images, filesystems, IaC templates and dependency manifests for known vulnerabilities and misconfigurations in a single binary — trivy image myapp:latest --severity HIGH,CRITICAL --exit-code 1 is a complete CI gate. gitleaks scans commits and history for secrets and takes about the same effort to add. Syft generates an SBOM in SPDX or CycloneDX format, which is increasingly a procurement requirement rather than an optional nicety.

The Cheapest Improvements Are Not Tools

Before adding anything: enable dependency caching keyed on your lockfile hash, run independent jobs in parallel rather than in one sequential script, and put a timeout on every job so a hung step costs five minutes instead of six hours of runner time. Pin action and image versions to a digest rather than a floating tag — a mutable tag means your pipeline can change without a commit, which is both a reproducibility problem and a supply-chain one. Those four changes typically do more for build time and reliability than any new tool in the list above.