필사 모드: CI/CD Platforms 2026 Deep Dive — GitHub Actions, GitLab CI, CircleCI, Buildkite, Dagger, Earthly, Drone, Argo CD, Flux

Prologue — CI/CD Is Politics Again

A scene you see in 2026 at almost every company: the platform team announces "company-wide standard is GitHub Actions"; the data team pushes back with "our monorepo is faster on Buildkite"; the SRE team chimes in with "but deploys go through Argo CD." What ends up shipping is a layered architecture — builds on GitHub Actions, agents on self-hosted runners, cache on Turborepo Remote Cache, deploys on Argo CD, progressive rollout on Flagger.

That is the reality of CI/CD in 2026. **The fantasy that a single tool does everything is dead**, and instead we make a per-team decision: "which combination fits us?" And that decision is not just technical — it is a function of **cost, security, speed, and platform politics**.

This post draws the full map of CI/CD platforms in 2026. The SaaS Big Four (GitHub Actions, GitLab CI, CircleCI, Buildkite), the container-native new wave (Dagger, Earthly, Drone, Harness), GitOps (Argo CD, Flux, Flagger), K8s-native (Tekton, OpenShift Pipelines), and Terraform CI/CD (Spacelift, Atlantis, Pulumi Deployments) — with each tool's position, cost, and break-even point.

Chapter 1 · The Full Map — A 2026 Taxonomy

First, the big picture. The single term "CI/CD" covers too much. A common 2026 taxonomy:

| Layer | Role | Representative Tools |

| --- | --- | --- |

| SaaS CI Big Four | Git push to build/test | GitHub Actions, GitLab CI, CircleCI, Buildkite |

| Container-native CI | Every step expressed as a container | Dagger, Earthly, Drone, Harness CI, Codefresh |

| K8s-native CI | Pipelines that live inside K8s | Tekton, OpenShift Pipelines, Argo Workflows |

| CD / GitOps | Git as source of truth, sync to K8s | Argo CD, Flux, Flagger |

| Terraform CI/CD | Safe application of infra changes | Spacelift, Atlantis, Terragrunt, env0 |

| Cloud-managed | Vendor-tied integrated packages | AWS CodePipeline, Azure Pipelines, Google Cloud Build/Deploy |

| Enterprise classics | On-prem, complexity, plugins | Jenkins, TeamCity, Bamboo, GoCD |

| Execution infra | Runners and caches | BuildJet, Depot, Blacksmith, Turborepo Cache |

The key insight: **across layers it is composition, not competition**. GitHub Actions and Argo CD are not rivals. Dagger and Tekton compete for the same slot. Comparisons only make sense inside the same layer.

Chapter 2 · GitHub Actions — Why It Became the Default

Over 70% of new projects in 2026 start with GitHub Actions (JetBrains DevEcosystem 2025 estimate). The reason is simple — the code lives on GitHub, small workflows fit in one yaml file, and the marketplace has over 20,000 actions stacked up.

Patterns that solidified by 2026:

- **Larger runners** — 4, 8, 16, 32, 64 vCPU runners provided directly by GitHub. ARM64 runners (Cobalt 100 based) and Apple Silicon runners (M2, M3) are now GA.

- **Reusable workflows + composite actions** — extract internal-standard pipelines as reusable workflows; bundle small step groups as composite actions.

- **OIDC for cloud** — exchange ID tokens for AWS/GCP/Azure access instead of long-lived credentials. Effectively the default since 2024.

- **Immutable releases / Artifact attestations** — `actions/attest-build-provenance` makes SLSA Level 3 nearly automatic.

- **Self-hosted runners** — cost, security, and hardware needs have brought self-hosting back. A dedicated chapter follows.

Traps that catch teams:

- Using user input directly inside template expressions enables command injection. The safe pattern is to receive it via `env:` and then use it.

- The `pull_request_target` trigger has access to secrets, but checking out the PR code as-is is dangerous. Block this with policy.

- Free per-minute quota gets exhausted quickly. Private repos accumulate per-minute charges fast, so calculate the self-host break-even point ahead of time.

Chapter 3 · GitLab CI/CD 17.x — A Full-Stack DevSecOps Bundle

GitLab 17.x (released late 2024) positions CI/CD not as a mere workflow runner but as **a full-stack DevSecOps bundle**.

- A single `.gitlab-ci.yml` expresses build, test, SAST, DAST, container scanning, license check, and deploy.

- GitLab Runner — supports Docker, Kubernetes, Shell, SSH executors.

- **Auto DevOps** — convention-based automatic pipelines. Strong cost-performance for startups.

- **GitLab Duo** — AI-powered code review, test generation, vulnerability explanation. In 2026, Duo Workflow moved from beta to GA.

- **Continuous Vulnerability Scanning (CVS)** — periodically re-scans the main branch to catch newly disclosed CVEs.

- **Compute minutes** — minute-based metering on SaaS plans. Unlimited on self-managed but infra costs apply.

If GitHub Actions wins on "Git + workflow simplicity," GitLab CI wins on "integration of a full stack in one vendor." That is why GitLab self-managed share remains high in regulated industries (finance, public sector, healthcare).

Chapter 4 · CircleCI 2.x — Orbs and Parallel Execution

CircleCI lost share after GitHub Actions arrived, but is **still strong in monorepos and multi-language projects**.

- **Orbs** — reusable yaml bundles. Over 3,000 in the marketplace.

- **Parallelism + Test Splitting** — automatically splits a job across N containers and balances by historical test time.

- **Matrix builds** — express language, OS, DB combinations as a grid quickly.

- **CircleCI Sphere (TestGPT)** — AI features for failed-test root cause analysis and fix suggestion.

- **Self-hosted runners** — for secure environments. GPU runners are now GA.

The common reason for staying on CircleCI is "**parallel execution of large test suites works best here**." The downside is that it can feel like overkill for small workflows compared to GitHub Actions.

Chapter 5 · Buildkite — Agents on Your Own Infrastructure

Buildkite's model is different from GitHub Actions. **The control plane (web UI, pipeline definition, log aggregation) runs on Buildkite's SaaS, while agents (the actual build executors) run on your infrastructure.** It is a BYO (Bring Your Own) compute model.

Why this matters:

- Builds run inside your VPC, with safe access to internal resources (DBs, internal registries).

- No per-minute pricing — you pay for the agents you operate.

- It is fast on huge monorepos — caches and Docker layers stay on your infra.

Popular with large-monorepo teams like Shopify, Airbnb, and Pinterest. The downside is that **operating agents itself becomes work** — autoscalers, cache policies, hardware management.

Chapter 6 · Dagger — The New "Programmable CI" Category

Dagger, the project Docker co-founder Solomon Hykes started, established itself quickly through 2024 and 2025. The core idea is simple — **write CI pipelines in code, not yaml**.

- SDKs in Go, TypeScript, Python, PHP, Java.

- Every step runs **inside a container** — what runs on your laptop runs in CI. The end of "works on my machine."

- BuildKit-based — fast caching and parallelism.

- **Dagger Cloud** — SaaS trace, timeline, and cache-hit visualization.

- Runs on top of GitHub Actions, GitLab CI, and Jenkins — it does not replace existing CI but is invoked from inside it.

Dagger's real appeal is "escape from yaml hell." Complex branching and matrix combinations get painful to express in yaml, but a Go or TypeScript function gets you IDE autocomplete, type checks, and unit testability.

Chapter 7 · Earthly — Monorepo-Friendly BuildKit

Earthly attacks the same problem from a different angle. You write build steps declaratively in a single file called **Earthfile**, while the engine underneath uses BuildKit for container-step execution.

- Syntax is close to Dockerfile — low onboarding cost.

- Cache, parallelism, and monorepo-friendliness — express dependencies as `+target`.

- Same commands locally and in CI — reproducibility.

- Earthly Satellites — managed BuildKit runner (SaaS).

Dagger and Earthly compete in the same space but with different philosophies. **Dagger says "write code"**; **Earthly says "write something Dockerfile-like, but more powerful."** Choose by team taste.

Chapter 8 · Drone 2.x and Harness CI — Under the Harness Umbrella

Drone was an early champion of container-native CI and was acquired by Harness in 2020. Today it lives in two forks.

- **Drone 2.x (OSS)** — yaml-based, per-container execution, lightweight. Strong for self-hosting.

- **Harness CI (managed)** — SaaS that layers AI features (test regression prediction, failure RCA, drift detection) on top of Drone.

Harness's killer feature is **AI Test Intelligence** — it analyzes code changes against historical test results and automatically picks which tests to run per PR. Case reports of 30~70% test-time reductions on large monorepos are common.

Chapter 9 · Argo CD — GitOps for Kubernetes

If CI is the build, CD is the deploy. In 2026, for CD on Kubernetes, the de facto standard is **Argo CD**.

- **GitOps principles** — Git is the source of truth. Cluster state follows the manifests in Git.

- **ApplicationSet** — automatically propagate the same chart across many clusters and environments.

- **Argo CD Image Updater** — detects new image tags and auto-updates Git.

- **Argo Rollouts** — Canary, Blue-Green, progressive rollouts.

- **Argo Workflows** — workflow engine on K8s (also used as CI adjunct).

The strength is **every change is a Git commit** — audit, rollback, and reproduction are easy. The weakness is **K8s lock-in** — does not fit VMs or serverless directly.

Chapter 10 · Flux CD and Flagger — Another Flavor of GitOps

Flux does similar work to Argo CD but with a different philosophy.

- **Flux is a bundle of controllers** — Source, Kustomize, Helm, Notification, and Image Automation are each their own controller.

- **Argo CD is UI-centric and app-centric; Flux is CRD-centric and platform-centric.**

- **Flagger** — Flux's progressive delivery tool, in the same slot as Argo Rollouts.

Flux's appeals: a CNCF graduated project, backed by SUSE and Microsoft, and strong composability. Argo CD is GUI-friendly and app-catalog-friendly; Flux is platform-builder-friendly.

Chapter 11 · Jenkins 2.x, Jenkins X, Tekton — Classics and K8s-Native

Jenkins does not die — at least not in the enterprise.

- **Jenkins 2.x** — declarative pipelines, Blue Ocean UI, 20,000+ plugins.

- **Jenkins X** — K8s-native Jenkins. Effectively a separate project now.

- **AWS Jenkins on EKS** — managed Jenkins option.

Jenkins's strengths are **plugin ecosystem depth and on-prem heritage**. Its weaknesses are **single-master SPOF, plugin security burden, and lack of a modern UI**.

**Tekton** is the standards candidate for K8s-native CI. Define Task, Pipeline, and PipelineRun as CRDs; Red Hat OpenShift Pipelines is the Tekton-based enterprise package. **Natural for teams already running K8s**.

Chapter 12 · Spacelift, Atlantis, Pulumi Deployments — Terraform CI/CD

The CI/CD for infrastructure code (Terraform, OpenTofu, Pulumi) is its own category. You can run it on a generic CI, but building a safe flow of state, plan, and apply is hard.

- **Atlantis (OSS)** — workflow driven by `atlantis plan` and `atlantis apply` comments inside a PR. Self-hosted.

- **Spacelift** — the SaaS version of Atlantis plus policy-as-code. OPA integration.

- **env0** — managed Terraform cloud + RBAC + cost estimation.

- **Terragrunt** — a DRY tool for Terraform itself, often used alongside in CI flows.

- **Pulumi Deployments** — Pulumi-specific managed executor and scheduler.

**Key rule: do not run `terraform apply` on a generic CI.** Let one tool own state locking, concurrency, approvals, and drift detection.

Chapter 13 · Other Managed CIs — Codefresh, GoCD, Octopus, TeamCity, Bitbucket

Tools that fit better for specific situations.

- **Codefresh** — managed CI specialized for K8s and GitOps. Bundles Argo CD as a SaaS.

- **Octopus Deploy** — strong for Windows and enterprise deploys. Variable substitution and environment management are detailed.

- **GoCD (ThoughtWorks)** — value stream map visualization is the standout. Small share but loyal users.

- **TeamCity 2024.x (JetBrains)** — build chains and meta-runners are powerful. JetBrains-ecosystem friendly.

- **Bitbucket Pipelines 2026 (Atlassian)** — Bitbucket Cloud integration. A single bundle with Jira and Confluence.

- **Garden.io** — focused on local-dev to CI consistency. Strong for microservices with many environments.

Chapter 14 · Cloud-Managed CI — AWS, Azure, GCP

Cloud lock-in can be a rational pick when the integration value is high.

- **AWS CodePipeline + CodeBuild + CodeDeploy** — deep IAM, VPC, and S3 integration. Lambda, ECS, and EKS deploys are convenient. UI is simple; evolution is slow.

- **Azure DevOps Pipelines / Azure Pipelines** — Microsoft-ecosystem strength. Two modes (yaml and classic). Free minutes are relatively generous.

- **Google Cloud Build / Cloud Deploy** — deep integration with GCR/GAR, GKE, and Cloud Run. Cloud Deploy is Argo CD-style progressive rollout.

Selection rule: **if 90%+ of your stack lives in one cloud**, managed CI is rational. **If multi-cloud or hybrid is in the mix**, a cloud-neutral CI like GitHub Actions or GitLab is better.

Chapter 15 · Self-Hosted Runners — BuildJet, Namespace, Blacksmith, RunsOn, Depot, Ubicloud

A new 2026 trend. As GitHub-hosted runner per-minute pricing got expensive, **external runner SaaS that is API-compatible with GitHub Actions** formed its own category.

- **BuildJet** — fast machines for the price. An 8 vCPU runner is around half the GitHub price.

- **Namespace** — instant runners with KVM-based isolation. Fast boot is the edge.

- **Blacksmith** — runs on Hetzner bare-metal. A significant price advantage.

- **RunsOn** — auto-starts runners inside your own AWS account. EC2 spot is fair game.

- **Depot** — strong on BuildKit-based container build acceleration. Both Docker builds and GitHub Actions.

- **Ubicloud** — runners on top of an OSS cloud infra. Similar pricing to Hetzner.

Break-even intuition: with GitHub-hosted Linux at 0.008 USD/min, external runner SaaS is usually cheaper above 50,000 minutes per month. RunsOn-style runners on spot inside your own AWS account can drop to 0.001~0.003 USD/min.

Chapter 16 · Cache Infrastructure — Turborepo, Nx Cloud, Bazel, sccache, Mise

Half of CI speed is caching. Tools commonly used in 2026:

- **Turborepo Remote Cache** — standard for JS/TS monorepos. Vercel SaaS or self-host (open spec).

- **Nx Cloud** — for Nx monorepos. Distributed task execution and affected calculation.

- **Bazel Remote Cache** — Google-origin, the peak for huge monorepos. Steep learning curve.

- **sccache** — compiler cache for Rust and C++. S3 backend for team-wide sharing.

- **Mise (successor to rtx)** — runtime version management plus tool caching. Established as the asdf successor.

- **GitHub Actions Cache (built-in)** — the default, but the 10 GB/repo cap is hit quickly.

When caching works, PR build times go from 30 minutes to 4. When it breaks, the opposite happens — so cache key design and invalidation policy are normally invisible but ultimately decisive.

Chapter 17 · Container Registries — Docker Hub, GHCR, ECR, GAR, Harbor, Zot

Build outputs are usually images. Where to push them matters too.

- **Docker Hub** — free pull limits got stricter in 2026. Still the standard for hosting public images.

- **GitHub Container Registry (GHCR)** — full GitHub Actions integration. First pick for private images.

- **Amazon ECR / Public ECR** — the standard inside an AWS account. Deep integration with EKS, ECS, and Lambda.

- **Google Artifact Registry (GAR)** — successor to GCR. Single registry for Docker, npm, Maven, and Helm.

- **Harbor** — CNCF graduated. The de facto standard for on-prem and internal registries.

- **Zot** — OCI-native OSS registry. First-class Cosign and SBOM.

Chapter 18 · Signing, SBOM, SLSA — The Three Pillars of Supply Chain Security

A space that standardized rapidly after 2024.

- **Cosign (Sigstore)** — OIDC-based keyless signing. Plays well with GitHub Actions OIDC.

- **Notary v2 / Notation** — OCI-native signing. Adopted by AWS Signer and others.

- **SBOM** — Software Bill of Materials. **SPDX** (Linux Foundation) and **CycloneDX** (OWASP) are the two main formats.

- **SLSA Levels 1~4** — supply chain integrity levels. Level 3+ is the de facto recommendation in 2026.

- **in-toto attestations** — build provenance attestations.

GitHub Actions' `actions/attest-build-provenance`, GitLab's SLSA pipeline, and Google's Binary Authorization are integrated tools that handle this bundle in one shot.

Chapter 19 · AI in CI — What Is New in 2026

How AI is entering CI.

- **CircleCI Sphere / TestGPT** — failure analysis plus fix suggestions.

- **GitLab Duo Workflow** — code review, test generation, and vulnerability explanation.

- **Harness AI Test Intelligence** — test selection based on PR code changes.

- **Datadog Test Optimization** — flaky test detection, rerun policies, and test-time regression.

- **Meta Predictive Test Selection** — internal-only model, paper published.

- **GitHub Copilot Workspace + Actions** — auto-drafting PRs, auto-fixes, auto-reviews.

AI in CI is, in one phrase, **"AI that decides what NOT to run."** Resource savings come from not running all tests on every PR, only the affected ones — and classifying that by hand is hard.

Chapter 20 · Korean Big Tech CI/CD Landscape — 2026

Common patterns at Korean big tech.

- **Coupang** — GitHub Enterprise plus GitHub Actions, self-hosted runners on internal K8s. Argo CD for EKS deploys. Bazel for monorepos.

- **NAVER Cloud DevOps** — in-house DevOps platform (NCP DevOps Pipeline). Internal standard, though some teams use GitHub Enterprise.

- **Kakao Pages CI** — GitHub Actions plus in-house K8s plus Argo CD. Many teams migrated from Spinnaker to Argo CD.

- **LINE SRE team** — moved from Drone to GitHub Actions. Cross-region global deploys use in-house tooling.

- **Baemin / Woowahan Brothers** — GitHub Actions plus AWS CodeDeploy plus Spinnaker.

- **Toss** — GitHub Enterprise plus in-house PaaS (Toss Platform). Deploys go through Argo CD plus an in-house control plane.

Common thread: **GitHub Enterprise + Actions + self-hosted runners + Argo CD** is fast becoming the standard. Jenkins survives in legacy systems; nearly no new projects pick it.

Chapter 21 · Japanese Big Tech CI/CD Landscape — 2026

Japanese big tech tends toward greater tool diversity than Korean.

- **Mercari** — GHE plus Actions as the main path. Self-hosted runners on GKE. Mix of Argo CD and Spinnaker for CD.

- **CyberAgent** — many subsidiaries make their own tool choices. Buildkite, CircleCI, and GitHub Actions coexist.

- **Rakuten DevOps** — Jenkins-to-GitLab-CI migration in progress. Regulated subsidiaries stay on GitLab self-managed.

- **DeNA** — GitHub Actions plus AWS CodePipeline plus an internal platform.

- **Pixiv** — GitHub Enterprise plus Actions plus self-hosted runners. Cache infra is in-house.

- **SmartHR** — Buildkite plus Argo CD. Aggressively uses Buildkite for monorepo build acceleration.

Notable observation: **Japanese firms tend to have a slightly higher on-prem share than Korean firms, with a higher GitLab self-managed share too**. Regulatory and security requirements are often more conservative.

Chapter 22 · Cost — Per-Minute Pricing and Self-Host Break-Even

Rough per-minute pricing in USD as of May 2026 (Linux baseline spec).

- GitHub-hosted Linux 2-core: 0.008

- GitHub-hosted Linux 8-core (Larger): 0.032

- GitHub-hosted Apple Silicon: 0.16

- GitLab.com saas-linux-medium: around 0.01

- CircleCI medium: 0.005

- Buildkite: agent operating cost only (no per-minute fee)

- BuildJet 8-core: 0.012

- Blacksmith 8-core: 0.008

- RunsOn (your AWS): 0.001~0.003 with spot

Recommendations by org size:

- **Under 10,000 minutes per month**: GitHub Actions hosted is the most rational. Self-host operating cost is higher.

- **50,000 to 300,000 minutes per month**: external runner SaaS (BuildJet, Blacksmith) or RunsOn in your AWS account cuts cost by 50% or more.

- **Above 1,000,000 minutes per month**: in-house K8s runners plus cache plus registry. Requires 1 to 2 dedicated people.

True cost including cache = (per-minute cost x minutes) + (cache infra cost) + (operating time cost). Looking at per-minute alone always produces the wrong decision.

Chapter 23 · Ten Common Pitfalls

A collection of failure patterns.

1. **Leaking secrets to stdout** — masking is not a panacea. Do not pair it with `set -x`.

2. **`pull_request_target` plus external code checkout** — a classic secret-theft path.

3. **One giant monolith workflow** — yaml at 1,000 lines, all branching and matrices in one place. Debugging hell.

4. **Cache keys too broad** — one person's change breaks others' builds.

5. **Cache keys too narrow** — caches almost never hit and become useless.

6. **Using prod credentials directly inside CI** — switch to OIDC plus temporary credentials.

7. **`apply` is open to everyone** — no approval flow on Terraform or K8s deploys.

8. **Flaky tests are normalized via reruns** — without root cause fixes, trust drops to zero.

9. **No post-deploy verification** — full traffic cut over without health checks or smoke tests.

10. **Rollback is manual** — mean time to recovery becomes 10x.

Chapter 24 · Seven Criteria for Picking a Tool

To summarize, the picture comes down to these seven.

1. **Integration with your Git host** — if it is GitHub, Actions is 99% the answer.

2. **K8s footprint** — high means Argo CD/Flux plus Tekton come into play.

3. **Monorepo scale** — large monorepos pair Buildkite, Earthly, Bazel, and Nx Cloud well.

4. **Regulatory needs** — if self-managed/on-prem is required, GitLab self-managed, Jenkins, or Drone.

5. **Cloud lock-in level** — 90%+ in one cloud makes cloud-managed CI rational.

6. **Team size** — small teams pick SaaS; large teams self-host with dedicated owners.

7. **Cost model** — sum per-minute pricing, cache, and operations time together.

The essence of the choice: **not "which tool is best?" but "which combination is rational under our constraints?"** And re-evaluate that combination every 1 to 2 years — prices and tools both move fast.

Epilogue — CI/CD Is the Nervous System of Your Platform

The one-line summary: **CI/CD is not a tool choice; it is a platform design.**

CI/CD in 2026 is not the question of which tool to use, but of how to make the flow of **build to test to sign to deploy to verify to roll back** trustworthy. Whether it is GitHub Actions or GitLab CI, Argo CD or Flux, no single tool is the answer. The answer is in the fact itself that **the nervous system those tools form decides your team's decision speed**.

When a PR is pushed and a trustworthy signal returns within 5 minutes, the team operates at a different velocity. At 30 minutes, people lose context. At 1 hour, people start routing around CI. **That is why CI/CD is culture, not tooling.**

CI/CD over the next decade will hand more and more decisions to AI — what not to run, what broke, what to auto-fix. But drawing the safety boundary around those decisions remains a human job. So doing CI/CD well is **not the volume of automation but the quality of where its boundary is drawn**.

12-item checklist

1. Do PR signals return within 10 minutes?

2. Do you measure cache hit rate?

3. Have you calculated self-host vs SaaS costs?

4. Are cloud credentials issued via OIDC (no long-lived keys)?

5. Do you sign build artifacts (Cosign, etc.)?

6. Is an SBOM generated per build?

7. Is deploy declarative via GitOps (Argo/Flux)?

8. Is there progressive delivery like canary or blue-green?

9. Does automatic rollback work on failure?

10. Is there a policy for isolating flaky tests?

11. Are secrets passed as env vars and kept out of stdout?

12. Is there a recurring slot to re-evaluate tools every 1 to 2 years?

Ten anti-patterns

1. The fantasy that one tool does it all — the answer is always a combination.

2. Deciding by per-minute price alone — missing cache and operations cost.

3. 1,000-line yaml workflows — branching and looping belong in code.

4. Prod deploys from inside a PR — separate them with approval flows.

5. Printing secrets in cleartext — no `set -x` in those steps.

6. Papering over flaky tests with reruns — fix the root cause.

7. Builds with no cache invalidation — broken caches live forever.

8. No post-deploy verification — smoke tests are non-negotiable.

9. Rollback only in a doc — automate it.

10. Never re-evaluating CI/CD — do it every 1 to 2 years.

Up next

Candidate topics: **a deep dive into GitOps — the real difference between Argo CD and Flux**, **monorepo build acceleration — Bazel, Buck2, Turborepo, Nx compared**, **supply-chain security in practice — Cosign, SBOM, and SLSA**.

> "CI/CD is not a tool; it is a nervous system. The speed of that nervous system sets the speed of the organization."

— CI/CD Platforms 2026, end.

References

- [GitHub Actions Documentation](https://docs.github.com/en/actions)

- [GitHub Larger Runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners)

- [GitLab CI/CD Documentation](https://docs.gitlab.com/ee/ci/)

- [GitLab Duo](https://about.gitlab.com/gitlab-duo/)

- [CircleCI Documentation](https://circleci.com/docs/)

- [CircleCI Sphere — TestGPT](https://circleci.com/blog/announcing-circleci-sphere/)

- [Buildkite Documentation](https://buildkite.com/docs)

- [Dagger — Programmable CI](https://dagger.io/)

- [Dagger GitHub — dagger/dagger](https://github.com/dagger/dagger)

- [Earthly Documentation](https://docs.earthly.dev/)

- [Drone CI](https://www.drone.io/)

- [Harness CI](https://www.harness.io/products/continuous-integration)

- [Argo CD](https://argo-cd.readthedocs.io/)

- [Flux CD](https://fluxcd.io/)

- [Flagger — progressive delivery](https://flagger.app/)

- [Tekton Pipelines](https://tekton.dev/)

- [OpenShift Pipelines](https://docs.openshift.com/pipelines/)

- [Jenkins](https://www.jenkins.io/)

- [Atlantis — Terraform PR automation](https://www.runatlantis.io/)

- [Spacelift](https://spacelift.io/)

- [Pulumi Deployments](https://www.pulumi.com/product/pulumi-deployments/)

- [AWS CodePipeline](https://aws.amazon.com/codepipeline/)

- [Azure Pipelines](https://azure.microsoft.com/en-us/products/devops/pipelines)

- [Google Cloud Build](https://cloud.google.com/build)

- [Google Cloud Deploy](https://cloud.google.com/deploy)

- [BuildJet for GitHub Actions](https://buildjet.com/for-github-actions)

- [Namespace](https://namespace.so/)

- [Blacksmith](https://blacksmith.sh/)

- [RunsOn](https://runs-on.com/)

- [Depot](https://depot.dev/)

- [Ubicloud](https://www.ubicloud.com/)

- [Turborepo Remote Cache](https://turbo.build/repo/docs/core-concepts/remote-caching)

- [Nx Cloud](https://nx.app/)

- [Bazel Remote Cache](https://bazel.build/remote/caching)

- [sccache GitHub](https://github.com/mozilla/sccache)

- [Mise](https://mise.jdx.dev/)

- [Cosign / Sigstore](https://docs.sigstore.dev/cosign/overview/)

- [SLSA framework](https://slsa.dev/)

- [SPDX](https://spdx.dev/)

- [CycloneDX](https://cyclonedx.org/)

- [Harbor — CNCF](https://goharbor.io/)

- [Zot Registry](https://zotregistry.dev/)