CI/CD & Pipelines.

Runs GitHub Actions workflows locally in Docker containers. act push triggers all workflows registered for the push event. The feedback loop for Actions development goes from "commit, push, wait 3 minutes" to "edit, run, see result in 15 seconds". Supports matrix builds, secrets, environment variables, and most action types. Requires Docker.

CNCF GitOps toolkit: a set of controllers that run in your cluster, watch git repositories and Helm charts, and apply changes without CI pushing credentials into the cluster. The pull model means your CD pipeline never needs cluster access — the cluster pulls its own desired state. Pairs with ArgoCD on larger teams (ArgoCD for UI-driven ops, Flux for automation-heavy pipelines). Also manages Helm releases and image update automation.

Automates the release process for Go projects: build cross-platform binaries, create archives and checksums, build and push Docker images, publish to GitHub Releases, Homebrew, Scoop, and more — all from a single .goreleaser.yaml. Tag a commit, CI runs goreleaser release, and users can brew install your-tool within minutes. Works for non-Go projects too (pre-built binary distribution).

Build system that combines Makefile targets with Dockerfile-style isolation. An Earthfile defines build targets that run in containers — reproducible on any developer's machine and in CI without "it works on my machine." Each target declares its inputs and outputs, enabling caching. Sits between raw Dockerfiles and complex CI YAML — particularly useful for polyglot repos where make is showing its age.

Builds container images for Go binaries without a Dockerfile. ko build ./cmd/server compiles the binary, picks a minimal distroless base, and pushes the image — in seconds. Images are reproducible (no timestamps, no build context noise), minimal (no shell, no package manager), and signed by default with cosign. The fastest path from Go code to a production-ready OCI image.

CI/CD engine where pipelines are code (Go, Python, TypeScript) not YAML. Each step runs in a container; the Dagger engine caches at the function level and can run locally or on any CI provider. The pitch: test your pipeline on your laptop before pushing it. The tradeoff: you trade YAML verbosity for the full power and complexity of a programming language in your CI definition. Best suited for complex pipelines that have outgrown YAML readability.