The biggest change by 2026 isn't that one CI/CD platform has decisively won—it's that teams have become much more selective about what they automate. Most mid-sized engineering organizations (roughly 20–200 engineers) are optimizing for three things:
- Fast feedback (PRs under ~10 minutes)
- Reliable deployments (easy rollbacks, progressive delivery)
- Low maintenance overhead
For that profile, I'd recommend this stack:
| Layer | Recommendation | Why |
|---|
| Source control | GitHub | Still the ecosystem leader |
| CI | GitHub Actions | Mature, ubiquitous, excellent integrations |
| Build acceleration | Remote cache (e.g. Turborepo, Nx Cloud, Bazel remote cache) | Bigger productivity gain than changing CI providers |
| Containers | Docker + BuildKit | Standard everywhere |
| Registry | GitHub Container Registry or cloud registry | Keep it simple |
| CD | Argo CD (Kubernetes) or cloud-native deploy service | GitOps has become mainstream |
| Secrets | Cloud secret manager or Vault | Avoid GitHub Secrets for everything |
| Observability | OpenTelemetry + Grafana/Datadog/Honeycomb | Deploy confidence matters more than CI features |
GitHub Actions: still the default?
Yes.
A few years ago people expected newer platforms to displace it, but GitHub Actions kept improving while maintaining huge ecosystem advantages:
- every OSS project supports it
- excellent reusable workflows
- strong OIDC support (no long-lived cloud credentials)
- solid matrix builds
- self-hosted runners if needed
- massive marketplace
For most teams, the bottleneck isn't Actions itself.
The bottlenecks are usually:
- slow test suites
- inefficient Docker builds
- no build caching
- poor deployment strategy
Fixing those often cuts CI time by 50–80%.
When I'd choose something else
Buildkite
Still probably my favorite for larger engineering organizations.
Pros:
- fantastic self-hosted runners
- scales very well
- pipelines as code
- great visibility
Ideal for:
- 100+ engineers
- expensive builds
- GPU jobs
- custom infrastructure
Depot
Has become surprisingly popular because remote builders are fast.
Especially good if Docker builds dominate your CI time.
Many teams now run:
GitHub Actions
↓
Depot Build
↓
Container Registry
instead of building on GitHub runners.
CircleCI
Less common than it used to be.
Still perfectly capable, but many GitHub-first companies have migrated away because Actions closed most of the feature gap.
GitLab CI
Excellent if your company already uses GitLab.
Otherwise I wouldn't adopt GitLab solely for CI anymore.
Cloud-native CI
Google Cloud Build
AWS CodeBuild
Azure Pipelines
These make sense when you're deeply invested in one cloud ecosystem and want tighter IAM integration, but I wouldn't recommend them as the default for a typical SaaS company.
CD is where more innovation happened
CI has become somewhat commoditized.
Deployment tooling evolved much more.
Common modern flow:
PR
↓
GitHub Actions
Lint
Tests
Security scan
Build image
↓
Push image
↓
Update deployment manifest
↓
Argo CD detects change
↓
Deploy
↓
Health checks
↓
Automatic rollback if unhealthy
This separation of CI and CD has proven very robust.
Things worth investing in instead of changing CI providers
If I inherited a mid-sized engineering org today, I'd spend effort on:
- Remote build cache
Huge improvement.
Especially for:
- Nx
- Turborepo
- Bazel
- Gradle
- Rust
- Go
- Test splitting
Instead of:
30-minute test job
Run:
10 parallel jobs
≈4 minutes
- Incremental builds
Only build packages that changed.
Monorepo tooling has gotten very good.
- Preview environments
Every PR gets:
my-feature.preview.company.com
This dramatically improves product review and QA.
- OIDC authentication
Instead of storing cloud credentials in CI:
GitHub
↓
OIDC
↓
Temporary AWS/GCP/Azure credentials
This is now considered a best practice.
- Deployment safety
Instead of "deploy everything":
- canary
- blue/green
- feature flags
- automatic rollback
- health verification
These tend to improve reliability more than shaving another minute off CI.
A balanced 2026 setup
For a mid-sized team, I'd keep it straightforward:
GitHub
↓
GitHub Actions
↓
Remote cache (Nx/Turborepo/Bazel as appropriate)
↓
Docker BuildKit
↓
Container Registry
↓
Argo CD (or your cloud's deployment service)
↓
Kubernetes / Cloud
↓
OpenTelemetry
↓
Grafana / Datadog
This stack is well understood, avoids unnecessary complexity, and scales from a handful of developers to hundreds with incremental improvements rather than a wholesale platform migration.
If your team is already happy with GitHub, I wouldn't move away from GitHub Actions unless you have a specific pain point—such as very large self-hosted fleets, GPU-heavy workloads, or exceptionally expensive builds. In those cases, pairing GitHub Actions with specialized build infrastructure (rather than replacing it entirely) is often the most pragmatic approach.
