GitHub GitLab
< Back to Blogs
September 22, 2025

Why GitHub's Latest Node Deprecation Validates Our Concourse Bet

GitHub just announced Node 20 deprecation, forcing teams to migrate to Node 24 by 2026. The absurdity? Teams resort to using actions/checkout@main instead of versioned tags because the API hasn’t changed - just Node versions going “out of maintenance.”

We’ve Been There

We’ve lived through the CI/CD migrations. Jenkins to Travis. Travis to CircleCI. CircleCI to GitHub Actions. Each promised to be “the last CI/CD platform you’ll need.” Each eventually forced rewrites.

That’s why we built CentralCI on Concourse. Our competitors chase the latest SaaS trends. We deliver infrastructure that doesn’t break on someone else’s schedule.

The Real Cost of “Free” CI/CD

GitHub Actions is code execution as a service. Why should anyone care whether the Node runner has a security vulnerability in an ephemeral build environment?

This isn’t about security. It’s about forcing unnecessary work on thousands of teams. They’re skipping Node 22 entirely, jumping to Node 24 - creating zero LTS overlap between GitHub Actions and platforms like Netlify (maxed at Node 22) or Vercel. Not planning, chaos.

Reproducible Builds: A Lost Art

One key goal of any build system: come back to a project after several years and have the build work out of the box. GitHub Actions violates this principle.

Avoiding proprietary hosted services and JavaScript-based build systems is becoming essential for long-term project maintainability. Many projects aren’t touched by developers for a year or more - not because they’re broken or stale, but because they’re stable tools that don’t need changing. Yet with GitHub Actions, these projects break not from code rot, but from forced platform changes.

Build Systems vs. Automation: A Critical Distinction

GitHub Actions conflates two fundamentally different use cases. When building software, you need stability and reproducibility - security vulnerabilities in the build toolchain are encoded into artifacts but shouldn’t prevent generation. When automating processes with external access to sensitive data, security updates matter.

GitHub treats these as identical, forcing security theater on build processes that just need to compile code reliably. Concourse respects this distinction. Your build pipelines are isolated, reproducible, and stable. Update when you want, not when forced.

Our Philosophy: Your Pipeline, Your Control

GitHub’s Node 20 deprecation perfectly illustrates why we exist. Their users now must:

  • Update every custom action to Node 24
  • Deal with dropped OS support (goodbye macOS 13.4, ARM32)
  • Test compatibility across their entire pipeline ecosystem
  • Hope the marketplace actions they depend on get updated

Our CentralCI customers? Their pipelines keep running. No emergency meetings. No frantic Slack messages. No weekend maintenance windows.

What We Built Different

Container-native from day one: Every task runs in an explicit Docker container. No mysterious runtime changes, no forced deprecations. The container that works today works forever.

True GitOps: Your pipelines are code, versioned and reviewed like code. Not buried in .github/workflows, but first-class infrastructure artifacts managed by your platform team.

Debugging that respects developers: With fly intercept, your engineers can jump into any failed build, with all inputs preserved. Compare that to scrolling through GitHub Actions logs, praying for clues.

The Business Case

Our enterprise customers chose CentralCI because they understood the hidden costs of “free” CI/CD:

  • Engineering hours lost to forced migrations
  • Security risks from third-party actions
  • Unpredictable costs from usage spikes
  • Compliance nightmares with code leaving your infrastructure

With CentralCI’s Concourse platform, they get:

  • Fixed costs: Your infrastructure, your rules
  • Compliance-ready: Code never leaves your network
  • Predictable roadmap: Upgrade when you choose, not when forced
  • Real support: When something breaks, you talk to us, not a forum

Growing While Others Scramble

Node 20 was the latest LTS version just two years ago. Many dependencies weren’t even compatible with it initially. By the time projects could migrate, they had maybe a year before the next deprecation cycle. Not maintenance - planned obsolescence.

We’re not anti-innovation. We’re pro-engineering. Every decision at CentralCI comes down to one question: Does this help teams ship better software, or does it create busywork?

GitHub’s Node 20 deprecation? Busywork. Concourse’s container model? Actual value.

We built CentralCI for teams tired of rewriting CI/CD configs every two years. If you’re ready for infrastructure that works for you, not against you, let’s talk.