Skip to content
Published on

CI/CD Platforms in 2026 — GitHub Actions / GitLab CI / CircleCI / Buildkite / BuildJet / Earthly / Dagger Deep-Dive Comparison

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Prologue — why look at CI/CD again in 2026

Around 2022, if you asked a Korean or Japanese engineering team "which CI do you use," the answer was simple. Startups: GitHub Actions. Mid-size and up: Jenkins. Mobile: Bitrise. IaC: Atlantis or homegrown scripts. The same question in 2026 produces longer answers. "We're on GitHub Actions, but runners switched to BuildJet, Docker builds are on Depot, and our monorepo build cache goes to BuildBuddy." Larger orgs reply: "Main pipeline on Buildkite, parts of the data pipeline on Argo Workflows, Terraform broken out to Spacelift."

That sprawl isn't an accident. Three trends collided.

  1. Runners became the bottleneck. AI-generated code 2-3x-ed PR throughput, tests got heavier, and GitHub's default runners cannot keep up. A whole "faster runner" market — BuildJet, Depot, Namespace — emerged.
  2. The build pipeline itself moved to containers and code. The escape from YAML-matrix hell found shape in Earthly and Dagger. The same pipeline runs locally, on CI, and on another CI.
  3. Kubernetes swallowed data and ML workloads. Argo Workflows and Tekton stretched CI into data engineering. The line between CI and workflow orchestration blurred.

This post organizes 20+ CI/CD tools as of May 2026 against the same axes. The question is not "which one is best" but "which conditions match which tool." Prices and features change quickly; we focus on structural differences.

When models converge, the harness makes the difference — what we said about AI coding tools applies to CI too. When runners converge, build cache, concurrency, and observability make the difference.

Chapter 1 · The 2026 CI/CD map — four buckets

You cannot compare 20+ tools at once. We split them into four buckets first, then zoom in.

A. Managed SaaS CI (hosted runners included) GitHub Actions, GitLab CI/CD, CircleCI, Travis CI (declining), Cirrus CI. The SaaS vendor owns runners, control plane, and billing. Setup is fast; the cost curve gets steep. The de facto standard in this bucket is GitHub Actions.

B. Self-hosted / hybrid CI Buildkite, Jenkins, Drone, Cirrus (partial). The control plane is SaaS or self-hosted, but runners live on your infra (EC2, GKE, on-prem). Pick this when security, cost, or hardware control matters.

C. k8s-native / pipeline compute Argo Workflows, Tekton, Namespace, parts of Drone. First-class support for running CI on Kubernetes. Boundaries with data, ML, and infra workflows are fuzzy.

D. Domain-specific Mobile — Bitrise, Codemagic. IaC — Spacelift, Garnix, Cycloid. Monorepo build cache — Bazel + Buildbarn / BuildBuddy / EngFlow. Dependency updates — Renovate, Dependabot, Mend.

Crossing those buckets is the "acceleration layer": BuildJet, Depot, Namespace run alongside GitHub Actions and swap only the runner. This is the single biggest shift in the 2024-2026 market.

Finally, do not forget the build system vs CI system split. Bazel, Earthly, and Dagger are closer to build systems; GitHub Actions, Jenkins, and Buildkite are orchestrators. The two layers do not replace each other — they coexist. GitHub Actions triggers a Bazel build that EngFlow caches.

Chapter 2 · GitHub Actions — the de facto standard

Surface and strengths Drop .github/workflows/ci.yml in your repo and you are done. As of May 2026, the overwhelming majority of OSS repos run here. The marketplace has tens of thousands of actions, and the canonical building blocks (actions/checkout, actions/setup-node, actions/upload-artifact) are well settled. Matrix builds, reusable workflows, composite actions, OIDC for cloud credentials — almost every core feature is available even on the free plan.

Pricing Public repos: free. Private repos: 2,000 minutes/month free, then per-minute. Linux at 0.008 USD/min, macOS at 0.08 USD/min, Windows at 0.016 USD/min are the 2026 sticker prices. Larger runners (16 vCPU and up) scale linearly. What actually scares people is macOS — running mobile builds on hosted macOS easily produces a four-figure monthly bill.

Weaknesses

  1. Default runners are slow. ubuntu-latest is 2 vCPU, 7 GB RAM. Painful in a monorepo. That gap created the BuildJet / Depot / Namespace market.
  2. YAML hell. Big pipelines do not fully fit even into reusable workflows. Once expressions like ${{ matrix.os }} stack up, debugging hurts — a typo in an expression often only surfaces mid-build.
  3. Secret leaks. A misused composite action that splatted secrets.* into logs was reported multiple times in 2024-2025. The strong recommendation is to migrate to OIDC.

Self-hosted runners When GitHub-hosted capacity runs out, you bring up ARC (Actions Runner Controller — auto-scaling runners on Kubernetes). Standard answer for teams that need access to internal data center or VPC resources.

One-liner

Free start, dominant ecosystem, OIDC — the default starting point for almost every team, but plan to swap to BuildJet / Depot / Namespace the moment runners become the bottleneck.

Chapter 3 · GitLab CI/CD — integrated DevOps

Surface and strengths GitLab pitched itself as a "Single Application for DevOps" from day one. SCM, issues, CI, CR, artifact registry, SAST, DAST, and environment tracking sit on one screen. Define stages, jobs, and rules in .gitlab-ci.yml and you are done. DAG (Directed Acyclic Graph) pipelines, child pipelines, multi-project pipelines, and dynamic child pipelines are all mature. In a large monorepo, expressiveness often beats GitHub Actions.

Pricing and self-hosting SaaS starts at 400 free minutes/month, Premium at 29 USD/user/month, Ultimate at 99 USD/user/month. But the real strength is on-premise. GitLab Community Edition is free and Enterprise Edition is licensed. The pattern of large Korean enterprises and Japanese SIers running GitLab inside their data centers is still rock solid in 2026.

Weaknesses

  1. SaaS hosted runners tend to cost more than GitHub's. Mixing in self-hosted runners is standard.
  2. UI is heavy. Premium/Ultimate security features (SAST result screens, etc.) are nicely done, but the everyday PR review flow feels snappier on GitHub.
  3. The CI marketplace is not nearly as rich as GitHub Actions. The CI/CD Catalog cleaned up a lot in 2024-2025, but the ecosystem size still does not compare.

When to pick GitLab You want SCM, CI, security scanning, and the artifact registry under one vendor — and on-prem is a hard requirement. Conservative Japanese enterprises and the Korean financial sector still run heavy GitLab CE/EE.

Chapter 4 · CircleCI — the older paid leader

Surface and strengths Before GitHub Actions, CircleCI was the standard SaaS CI. In 2026 it is still the strong paid SaaS CI. Orbs (reusable components), powerful matrices, large machine sizes, GPU runners, and test splitting are all mature. ARM/x86, Docker/machine/macOS — you pick freely.

Pricing Credit-based. Free at 6,000 credits/week; Performance at 15 USD/month plus usage; Scale is negotiated. The same job runs 50-100% more expensive than GitHub Actions, but shorter wall-clock builds can offset or beat the headline price thanks to faster machines and test splitting.

Weaknesses

  1. GitHub integration trails GitHub Actions. Small flows like "show results in PR comments" carry friction.
  2. OSS-unfriendly. Free tier exists, but cannot compete with GitHub Actions' "fully free for public repos."
  3. Outage memory. The January 2023 secrets breach left a scar — every customer had to rotate tokens.

When to pick CircleCI You already run it, your test splitting and orb investment is deep, so you stay. New adoption: evaluate GitHub Actions and GitLab first; only choose CircleCI when there is a specific reason.

Chapter 5 · Buildkite — the self-hosted runner model

Surface and strengths Buildkite's core idea: "Control plane is SaaS, runners live on your infra." Define steps in .buildkite/pipeline.yml; the SaaS control plane manages the queue; agents that you bring up pick up jobs. AWS, GCP, on-prem — it all works the same.

Why people pick it

  1. Keep data off external SaaS while still using a managed UI. Build logs stay on your infra; only metadata goes to Buildkite.
  2. Optimized for heavy builds. Large machines, GPUs, ARM, big disks — bring them up on your own infra at will.
  3. Seat-based pricing. Scales with users, not usage. Teams running many heavy builds end up much cheaper than on GitHub Actions or CircleCI.

Notable users Shopify, Pinterest, Airbnb, Lyft — large monorepo, mid-to-large engineering orgs. In Japan, Mercari is known to run parts of its backend pipelines on Buildkite.

Weaknesses

  1. You need your own infra. AWS/GCP costs and ops overhead come with the territory.
  2. Smaller marketplace than GitHub Actions. Plugins exist but the catalog is thinner.
  3. Plain UI. If you want flashy dashboards, look elsewhere.

One-liner

The best answer for mid-to-large teams who can operate their own infra. The "data is ours, ops is yours" model.

Chapter 6 · BuildJet / Depot / Namespace — faster runners and faster builds

These three live in the same category with slight variations. The common theme: acceleration layers that keep GitHub Actions and swap in faster compute.

BuildJet Replaces GitHub-hosted Linux/ARM runners with 2x CPU, more memory, larger disks. Apply by setting runs-on: buildjet-4vcpu-ubuntu-2204. Marketing claims roughly 50% of GitHub Actions' price for comparable specs. Linux-first; macOS is limited. Good when a one-line swap is all you want.

Depot Specialized for container builds. Swap docker build for depot build and you get BuildKit + remote cache + simultaneous ARM/x86 builds for free. Teams that build multi-arch images often report 5-10x speedups. It also offers GitHub Actions runners — just change the label to depot-ubuntu-22.04. Between 2024 and 2025 it became the de facto standard in the "Docker build offload" category.

Namespace Pitches itself as "Kubernetes-native CI." Define the build environment as code (rules.toml, Devbox, and so on); the Namespace control plane spins up isolated VMs or containers inside the cloud and runs the workload. You can use it as GitHub Actions runners or via its own CLI. The selling point is reproducible build environments — yesterday's runner behaves like today's.

When to adopt an acceleration layer

  • Average build time crosses 10 minutes and per-PR cost starts to hurt
  • macOS runner bills start to scare you (Depot macOS, BuildJet macOS)
  • ARM multi-arch builds are now standard

Adoption itself takes five minutes — change runs-on:. If you can do the ROI math, it is almost always a win in this market.

Chapter 7 · Earthly — Earthfile, container-based

Idea "Dockerfile only builds; Makefile only orchestrates. You need both." Earthly created the Earthfile syntax so build plus CI workflow sits in one file. Every step runs in a container, the cache is automatic, and outputs flow to the host or to other containers.

Core value — the same pipeline runs locally and on CI Type earthly +test on your laptop and you get the same outcome CI does. The "passes locally, fails on CI" rate drops dramatically. This is what every review consistently calls out.

Shape

# Earthfile
VERSION 0.8
FROM golang:1.22
WORKDIR /app

deps:
    COPY go.mod go.sum ./
    RUN go mod download

build:
    FROM +deps
    COPY . .
    RUN go build -o /out/server ./cmd/server
    SAVE ARTIFACT /out/server AS LOCAL build/server

test:
    FROM +deps
    COPY . .
    RUN go test ./...

earthly +build runs the target above in a cache-friendly way. The cache is BuildKit-backed.

Earthly Cloud and Satellites Earthly Cloud offers hosted build cache and runners. Satellites — hosted build machines — run shared cache that has been reported as 5-10x faster than GitHub Actions on large monorepos. Some pricing changed in 2025, so verify before adopting.

Weaknesses

  1. New syntax has a learning cost. Easy if you already know Dockerfile, but forcing it on a whole team is a real ask.
  2. For small projects already happy on GitHub Actions, ROI is weak. Big monorepos and complex builds are where it shines.

Chapter 8 · Dagger — programmable pipelines (Solomon Hykes)

Who built it Solomon Hykes — Docker co-founder. After leaving Docker he started Dagger. The thesis is sharp: "CI pipelines should be code, not YAML."

Idea Write pipelines in Go, Python, TypeScript, or Java. Calling the SDK hands work to the Dagger engine (BuildKit-based), which runs steps inside containers and returns results. The same code runs locally, on GitHub Actions, on GitLab CI, and on Jenkins.

// example — TypeScript SDK
import { connect } from "@dagger.io/dagger"

connect(async (client) => {
  const src = client.host().directory(".")
  const node = client.container().from("node:20").withDirectory("/app", src).withWorkdir("/app")
  await node.withExec(["npm", "ci"]).withExec(["npm", "test"]).sync()
})

Why people love this

  1. Testable pipelines. Unit tests on the pipeline code itself.
  2. CI vendor independence. Call the same function from GitHub Actions, Jenkins, or your laptop. Escape vendor lock-in.
  3. Composable modules. Share build blocks through the Dagger Cloud module system.

Weaknesses

  1. Learning curve. Higher than YAML pipelines. Even "just build" requires SDK, language, and module decisions.
  2. Ecosystem is not GitHub Actions Marketplace-sized. Dagger modules grow, but the comparison is hard.
  3. Vendor model is shifting. Dagger Cloud is settling into paid SaaS, so the cost structure outside the OSS engine is in flux.

Who benefits Monorepos where pipeline code has grown past 1,000 lines of YAML, multi-CI environments (GitHub Actions plus Jenkins), and teams committed to "pipelines as code."

Chapter 9 · Drone / Argo Workflows / Tekton — k8s pipelines

Different tools with different shapes.

Drone Started as OSS CI → Harness acquired it in 2020 → donated to CNCF in 2024. Container-based pipelines, defined in .drone.yml, with runners in Docker, Kubernetes, or machine mode. Simplicity is the selling point. After GitHub Actions arrived its share shrank, but in-house GitOps plus lightweight CI combinations still use it.

Argo Workflows CNCF Graduated. A DAG/step workflow engine that runs on Kubernetes. Originally for ML and data workflows, but used for CI as well. Each step becomes a Kubernetes Pod; triggers come from Argo Events. Every step is a Kubernetes resource — both blessing and curse. Visibility and scalability are great; simple CI is overkill.

Tekton A CNCF project spun out of Knative. Define Pipeline, Task, PipelineRun, and TaskRun as Kubernetes CRDs. Closer to a CI building block — friendlier UIs like OpenShift Pipelines and Jenkins X sit on top of Tekton. Red Hat pushes it hard via OpenShift Pipelines.

When to pick k8s-native CI

  • You already run Kubernetes for data/ML and want CI in the same cluster
  • Builds need GPUs, large memory, or special nodes
  • Multi-tenant isolation matters for a platform team

Weaknesses Observability and debugging are heavy. Often you kubectl logs a Pod to find what failed. Too heavy for the average developer to touch daily — which is why a platform team usually owns it while application teams interact through an abstraction like GitHub Actions.

Chapter 10 · Jenkins — the giant that refuses to die

Reality check GitHub Actions becoming standard did not kill Jenkins. In 2026 Jenkins still has enormous footprint in enterprise, financial services, semiconductors, and automotive. CloudBees keeps it alive commercially, and Jenkins X (the k8s-native fork) lives in some pockets.

Why it does not die

  1. A thousand pipelines already run. Jenkinsfiles, freestyle jobs, plugin dependencies — the surface area is enormous.
  2. The plugin ecosystem is huge. 1,800+ plugins. "How to integrate with X" is almost always answered by a plugin.
  3. Proven on-prem. GitHub Actions ARC is possible, but few ops teams are as fluent with it as with Jenkins.

Pain

  1. Security — plugin CVEs land every quarter. Patching is slow.
  2. UI — the classic UI still dominates in 2025. Blue Ocean was frozen.
  3. Talent — new engineers refuse to learn Jenkinsfile.

Strategy "New projects on GitHub Actions, freeze existing Jenkins and migrate gradually" is the realistic pattern. Jenkins-to-GitHub-Actions migration guides are official GitHub documentation, which says a lot.

Chapter 11 · Spacelift / Garnix / Cycloid — Terraform / IaC CI

Why a separate category Terraform/OpenTofu/Pulumi/CDK workflows are not regular CI. Drift detection, policy-as-code, the plan/apply two-step, multi-cloud credentialing — requirements general CI does not address. So IaC-specific CI carved out its own market.

Spacelift Integrates Terraform/OpenTofu/Pulumi/CloudFormation/Ansible/Kubernetes. Stacks and Runs as concepts, OPA-based policies, drift detection, self-hosted worker pools, and AWS/GCP/Azure credentials managers. Adopted by some Korean fintech and game companies.

Garnix Nix-based CI. The selling point is build reproducibility. The Nix builder caches outputs by content address and guarantees that the same input produces the same output. Solid within the NixOS/Nix world. The Nix learning curve is real, but once internalized, build trust moves into another dimension.

Cycloid Positions itself as a "DevOps automation platform." Terraform module catalog, environment provisioning, cost visualization, permission management — all in one UI. Pitches to mid-sized companies that want to replace an in-house platform team with a small SaaS.

Alternatives

  • Terraform Cloud / HCP Terraform — HashiCorp official. After the 2024 BUSL license shift, teams uncomfortable with the politics are moving to OpenTofu plus Spacelift/Atlantis.
  • Atlantis — OSS, self-hosted. The lightest option.

Chapter 12 · Bitrise / Codemagic — mobile CI

Why a separate market Mobile builds require macOS runners (iOS). Hosted macOS is expensive, and the workflow — signing keys, provisioning profiles, App Store Connect API, Firebase, internal distribution, code push — looks nothing like general CI. So mobile-specific CI survives.

Bitrise Started in 2014 in Budapest. Supports iOS and Android. The Step Library is rich, and the Workflow Editor lets you compose pipelines visually. Fastlane integration, App Store Connect integration, in-app code push — a comprehensive package. In 2024-2025 it has also pushed offerings like Bitrise CI for AI for ML builds.

Codemagic A genuine Flutter specialist. The de facto standard for Flutter builds. iOS and Android in one workflow, deployment to App Store / Play Store / Huawei / Amazon AppGallery in one go. Provides M2/M4 Mac mini runners for fast builds.

The death of App Center Microsoft App Center officially shut down on March 31, 2025. Once a major pillar of mobile CI, it was absorbed by Visual Studio App Center and ultimately retired. App Center users scattered to Bitrise, Codemagic, GitHub Actions (macOS runners), and Firebase App Distribution between 2024 and 2025.

Cost reality

  • Bitrise: Hobby free, Velocity from 50 USD/month, then usage-based.
  • Codemagic: 500 minutes/month free, then per-minute. M2 macOS at roughly 0.095 USD/min.

Hosted macOS is expensive everywhere. The number of companies running their own Mac mini Farm has grown — paired with hosting options like MacStadium, Scaleway, and Hetzner.

Chapter 13 · Bazel + Buildbarn / BuildBuddy / EngFlow — remote build cache

Why a separate space Build systems like Bazel, Buck2, and Pants cache at the action level. Same inputs, same outputs — same input hash means you just fetch the previous result. Sharing that cache across many machines cuts build times dramatically. That created the Remote Build Execution (RBE) plus Remote Cache market.

Buildbarn OSS. A free implementation that replaces Google's old buildfarm. ContentAddressableStorage, ActionCache, and ExecutionEngine are composed as modules. The OSS pick for large monorepos.

BuildBuddy SaaS plus a self-hosted option. Bazel-friendly UI, action logs, build trees, RBE. Y Combinator alums that grew fast in 2024-2025. Also building Go and Rust build acceleration on top of Bazel.

EngFlow Founded by Bazel co-creators. Enterprise focus; supports Bazel, Buck2, and Pants. Major customers include large game studios, financial services, and automotive OEMs. Expensive, contract-based pricing.

When to adopt RBE

  • Monorepo builds run dozens of actions per minute
  • Many PRs build the same actions in parallel
  • Adding build machines stops shrinking wall time (cache misses are the bottleneck)

The payoff is dramatic — 10x speedups in monorepos are common. Costs include cache storage, network, and execution machine time, but the standard ROI argument is that developer wait time costs more.

Chapter 14 · Renovate vs Dependabot vs Mend — dependency updates

Why a separate category In 2026, dependency update PRs are a meaningful share of CI traffic. Without automation, humans cannot keep up. CI is responsible not only for the build but for the bot that creates those PRs.

Dependabot First-class on GitHub. One .github/dependabot.yml file and you are done. Two modes: Security Updates (auto PRs for vulnerable deps) and Version Updates (periodic update PRs). Integrates with GitHub Advanced Security. Strengths: simple setup and GitHub UI integration.

Renovate Configuration expressiveness is overwhelming. Group several deps into one PR, automerge rules, monorepo/workspace awareness, 200+ managers (npm, pip, gradle, terraform, docker, helm, ansible-galaxy, and on), regex managers for arbitrary files. Acquired by Mend, but the OSS and self-hosted options live on.

Mend After acquiring Renovate, expanded into more enterprise territory. SCA (Software Composition Analysis), license validation, policy-based updates, and SBOM management. If Renovate is "technically strong," Mend is "organizational and policy control."

Selection guide

  • Small team on GitHub → Dependabot
  • Large team, complex monorepo, Terraform/Helm included → Renovate
  • Compliance, SBOM, license tracking required → Mend

All three trigger CI. Measure how much of your CI bill is from dependency-bot PRs — it is often surprisingly large.

Chapter 15 · Korea and Japan — Toss, Kakao, Mercari, CyberAgent

Korea — Toss Toss' SLASH conference materials show the team centered on GitHub Enterprise + GitHub Actions + ARC (self-hosted runners on Kubernetes). Build cache is in-house; deployment is via ArgoCD. App teams own their pipelines while the platform team owns ARC, secret management, and OIDC.

Korea — Kakao Kakao has a massive in-house GitLab estate. GitLab CI/CD is the main CI, mobile uses in-house Mac farms plus Bitrise. Some ML workloads run on Argo Workflows. Music (Melon), games, and commerce have autonomy, and CI stacks vary across subsidiaries like KakaoTalk, Daum, and KakaoBank.

Japan — Mercari Mercari runs close to 1,000 microservices. The CI stack is GitHub Actions + Buildkite + Spinnaker. Spinnaker handles deployment workflows; GitHub Actions is the main CI. Parts of monorepos reportedly use Bazel plus in-house RBE.

Japan — CyberAgent ABEMA and gaming — Kubernetes-based. CI is a mix of Argo Workflows + GitHub Actions, with build cache on BuildBuddy or in-house. Mobile is on Bitrise. Their talks set "average PR build under 5 minutes" as a KPI, which is impressive.

Common patterns

  • New work on GitHub Actions; existing investments (Jenkins, GitLab, Bamboo) stay
  • Runners shifting toward self-hosted on Kubernetes (ARC)
  • Build cache and RBE adoption grows with monorepo size
  • Security and secret management standardized on OIDC plus Vault or AWS Secrets Manager

Chapter 16 · Who should pick what — a decision tree

OSS project

  • First answer: GitHub Actions. Free for public repos, dominant marketplace.
  • If builds are heavy: start by swapping the label to BuildJet.
  • If container builds dominate: Depot.
  • If the pipeline is too complex for YAML: Earthly or Dagger.

Startup (10-50 people)

  • Main CI: GitHub Actions.
  • If mobile: Codemagic (Flutter) / Bitrise (native).
  • If lots of IaC: Spacelift or Atlantis (OSS).
  • Dependency bot: start with Dependabot, switch to Renovate when complexity hits.

Mid-size (50-300 people)

  • Main CI: GitHub Actions, or GitLab if on-prem is required.
  • Acceleration layer: BuildJet / Depot / Namespace — measure build time and cost before adopting.
  • Monorepo build: start evaluating Bazel + BuildBuddy.
  • Dependencies: Renovate.

Enterprise (300+, financial, telco, government)

  • Main CI: GitLab (on-prem) or GitHub Enterprise + ARC.
  • Freeze Jenkins assets; migrate in phases.
  • IaC: Spacelift / Terraform Cloud / OpenTofu + Atlantis.
  • RBE: EngFlow (commercial, strong support).
  • Dependencies: Mend (with compliance built in).
  • Mobile: Bitrise + your own Mac farm.

Mobile-only team

  • Flutter: Codemagic.
  • iOS/Android native: Bitrise.
  • If hosted macOS costs hurt, run your own Mac farm via MacStadium, Hetzner, or Scaleway.

Data / ML team

  • Workflow orchestration: Argo Workflows.
  • Data pipelines: Airflow or Dagster.
  • Model training CI: regular CI plus separate GPU runners (Lambda Labs, CoreWeave, and so on).

Chapter 17 · Principles that do not change

Tools change every year. We close with a few principles that do not.

  1. CI is a primary cost and time bottleneck. When 5-minute builds become 10 minutes, average PR merge time roughly doubles. Tool choice is a cost question and a cognitive-load question.
  2. Runners, builds, and cache are decomposable. Keep GitHub Actions, swap runners to BuildJet, build with Earthly, cache through BuildBuddy. Do not change everything at once — change one layer at a time.
  3. Turn on OIDC. The era of stuffing secrets into environment variables is over. OIDC token → STS → short-lived credentials is the standard.
  4. Measure CI cost. GitHub Actions billing, GitLab Usage Reports, CircleCI credits — look at least monthly. Acceleration-layer ROI starts with measurement.
  5. Watch for vendor lock-in. Tools like Dagger and Earthly let the same pipeline run across multiple CIs. The deeper you bind to one vendor, the higher the migration cost.
  6. Auto-merge dependency-bot PRs. Otherwise humans cannot keep up. Patch versions automerge on green; minor/major require manual review — these two rules are the standard.

CI is not "decide once and forget." Re-evaluate every 2-3 years, swap in small acceleration layers, and learn as you go. Big-bang migrations usually fail.

In the next post we run the acceleration layers (BuildJet, Depot, Namespace) and the build systems (Earthly, Dagger, Bazel) side by side on the same monorepo. Same code, different pipelines, measured time, cost, and failure modes.

References

Discuss on Twitter • View on GitHub