Stop Using CI as Your Deployment Platform

Why build pipelines and release delivery should be separated — and how independent CD gives teams more control, resilience, and auditability

For years, teams have treated CI platforms as the default place to do everything: build, test, package, deploy, promote, and sometimes even roll back.

At first, it feels efficient.

Your source code is already in GitHub or GitLab. Your pipeline definitions live next to your code. Your runners are already there. So why not push deployment and release orchestration into the same system too?

Because convenience at the beginning often becomes coupling at scale.

And once CI becomes your release platform, every operational weakness in that platform starts affecting not just your builds — but your ability to ship.

GitHub Actions is included as part of GitHub’s platform and private repositories receive a limited monthly quota of GitHub-hosted minutes depending on plan; extra usage is billed. GitHub also documents that self-hosted runners still connect back to GitHub to receive jobs and updates, which means the control plane remains dependent on GitHub availability.

CI is not the same thing as CD

CI and CD are related, but they are not the same responsibility.

Continuous Integration is about validating change:

• build the code
• run tests
• produce artifacts
• confirm that a commit is healthy

Continuous Delivery and deployment are about controlled change propagation:

• selecting a release candidate
• deciding where it goes
• defining approval flow
• promoting through environments
• enforcing role-based control
• capturing audit history
• handling rollback safely

That distinction matters. A build pipeline answers: “Can we produce a deployable artifact?”

A release platform answers: “Who deployed which version, where, when, why, and what happened next?”

Those are different questions. They deserve different systems.

The hidden cost of using CI for releases

Using GitHub Actions or GitLab pipelines for deployments is not “wrong.” In fact, it is often the fastest way to get started.
But the trade-off appears later. Once deployment logic lives inside CI, several problems start to pile up.

1. Your release process becomes coupled to your source platform

If your CI platform is degraded, your release process is degraded too.

That is not theoretical.

GitHub’s official incident history shows multiple incidents where core development and delivery workflows were affected together.

For example, on July 28–29, 2025, GitHub reported degraded performance affecting Issues, API Requests, and Pull Requests.

On August 21, 2025, GitHub reported delays and failures starting GitHub Actions jobs.

Its incident history also includes a broader incident on November 27, 2023 affecting Pull Requests, Issues, Webhooks, and Actions at the same time.

When your builds, approvals, and production releases all depend on the same platform, one outage can freeze both development and delivery.

If you need to ship a hotfix during an outage, or even during partial degradation, “everything in one place” suddenly stops looking like an advantage.

It becomes a single operational dependency.

2. CI pipelines are great at execution, but awkward at release governance

Pipelines are good at running jobs. They are less natural as systems of record for release intent and release control.

Yes, you can build approvals into workflows.
Yes, you can model environment promotion with YAML.
Yes, you can encode rollback logic in scripts.

But that does not mean CI is the best place to own those concerns.

Over time, teams start asking questions like:

• Which exact version was approved for staging?
• Who approved production?
• Was QA sign-off captured before the promotion?
• What was the previous successful version?
• Can we roll back automatically if deployment health fails?
• Can we see one clean audit trail for release actions across environments? At that point, deployment stops being “just another job.”

It becomes an operational workflow.

3. Release logic becomes too tightly bound to repository events

A lot of CI-driven deployment patterns are still built around repository triggers:

• push to branch
• merge to main
• create tag
• create release That works for simple teams. But mature release processes are rarely that simple.

Sometimes you want to:

• build once, deploy many times
• promote the same immutable artifact from staging to production
• separate the person who prepared the release from the person who approved it
• require QA verification before production
• allow operations to deploy without re-running builds
• roll back to the last known good release without touching source code

That is where “pipeline as deployment engine” starts to fight the way real teams operate.

GitLab is excellent — and this is not an anti-GitLab argument

GitLab deserves a lot of respect.

It is a strong product, especially for teams that want one integrated DevSecOps platform. GitLab supports both SaaS and self-managed deployments, and its documentation explicitly positions GitLab CI/CD as a system for building, testing, deploying, and monitoring iterative code changes. GitLab Runner can also be self-managed in your own infrastructure.

I like GitLab a lot. ❤️

And if your team is happy with GitLab pipelines for deployment, that may be the right choice for you. But even with GitLab, the same architectural question still exists:

*Should the system that validates code changes also be the system that governs release movement across environments?
*
For some teams, the answer is yes.

For others — especially teams that care about controlled promotion, auditable approvals, operational separation, and deployment resilience — the answer becomes no.

A better model: CI builds the artifact, CD owns the release

This is the model we believe in with Orbnetes.

Keep CI where it belongs:

• GitHub Actions
• GitLab CI
• Jenkins

• whatever your team already uses to build and test
  Let CI do one job well:

• compile

• test

• package

• publish a versioned artifact
  Then hand off release orchestration to a separate, independent CD service.
  That separation changes everything.
  Now your deployment platform is no longer just “a few jobs in YAML.”
  It becomes an actual release control layer.

What independence gives you

With Orbnetes, the goal is simple:

*CI produces versions. Orbnetes decides how those versions move through environments.
*
Instead of hiding release decisions inside pipeline files, the release flow becomes explicit.

A team member selects:

• the repository or release source
• the version to deploy
• the target environment That creates a release request. Another team member, with the appropriate role, can approve it. The release is then deployed to the next stage — for example, staging. QA can verify the result and mark it as accepted. Only then can the same release be promoted further, such as into production.

That gives you something many teams are missing today:
*a controlled release process instead of an automated shell script with side effects.
*

Control does not mean slowdown

This is where a lot of teams get nervous.

They hear “approval,” “portal,” “roles,” and “audit trail,” and assume the result will be bureaucracy.

But the goal is not to slow engineers down.

The goal is to remove ambiguity.

A good CD system should make releases:

• visible
• reproducible
• role-aware
• auditable
• easy to promote
• easy to roll back The best release process is not the one with the fewest clicks. It is the one that still makes sense at 2 a.m. during a production incident.

Rollback should be a policy, not an improvisation

One of the biggest weaknesses in CI-driven deployments is rollback maturity.

In many organizations, rollback still means:

• find the old tag
• re-run an old workflow
• hope the environment still matches
• manually reconstruct secrets or parameters
• pray the old pipeline still works That is not rollback. That is archaeology. A release platform should understand rollback as a first-class concept.

In Orbnetes, rollback policy can be defined around the last successful version, so if a deployment fails, the system can recover in a controlled and predictable way.

That is the difference between “we have scripts” and “we have operational design.”

Lightweight agents matter more than people think

Another overlooked issue in deployment systems is agent complexity.

The more heavyweight the runtime model is, the more fragile the overall deployment path becomes.

Orbnetes uses very lightweight agents — around 2 MB — which changes the operational profile significantly.

That matters because lightweight agents are easier to:

• distribute
• update
• run in constrained environments
• reason about
• troubleshoot This is not only about download size. It is about reducing moving parts. Teams often underestimate how much deployment instability is introduced by the deployment tooling itself.

A simpler agent model usually means a more stable deployment surface.

Simple YAML is still the right interface
YAML is not going away. And that is fine.

The problem is not YAML itself — it is where the YAML lives and what responsibilities it owns.

Orbnetes keeps the deployment definition simple. Recipes and blueprints can live in Git or locally, depending on how a team wants to manage them.

name: simple-release-deploy
description: Backup + deploy selected release file
inputs:
  target_env:
    type: string
    required: true
jobs:
  backup:
    tags: [linux]
    steps:
      - name: backup
        shell: bash
        run: |
          echo "Backup before deploy (env=${{ inputs.target_env }})"
  deploy:
    needs: [backup]
    tags: [linux]
    steps:
      - name: deploy-release-file
        shell: bash
        run: |
          echo "Deploying file: $ORBN_RELEASE_FILE"

That means teams still get the benefits engineers like:

• versioned definitions
• repeatable configuration
• human-readable deployment rules
• infrastructure-friendly workflows But without forcing the entire release lifecycle to be trapped inside the CI system that built the artifact.

Auditability is not a “compliance feature”

A lot of engineering teams hear “audit trail” and think:

“that is for enterprise buyers, not for us.” I think that is the wrong mindset. Auditability is not only about compliance. It is about operational memory. When something goes wrong, you want immediate answers:

• who deployed this?
• what version was deployed?
• which approval path was used?
• what environment changed first?
• was this promoted or freshly deployed?
• what was the previous successful version?
• That is not bureaucracy. That is how teams debug delivery itself.

Separation of duties is a feature, not a burden

One of the strongest reasons to separate CI from CD is role clarity.
The person who merges code is not always the person who should deploy to production.
The person who validates staging is not always the person who approves prod.
The team that owns release governance is not always the team that owns build pipelines.

When all of that is compressed into one CI platform, permission models often become messy:

• too much access for too many people
• deployment tied to repo write permissions
• operational control hidden in workflow files

• release actions mixed with normal developer automation
  A dedicated CD layer gives you a cleaner model:

• who can request

• who can approve

• who can deploy

• who can observe

• who can audit
  That is not just safer. It is easier to operate.

The architecture shift teams need to make

The key mindset change is this:

*CI should answer whether software is ready to be released.
*
*CD should answer how release actually happens.
*
Those are not the same responsibility. Once teams accept that, the architecture becomes cleaner:

• GitHub / GitLab / Jenkins → build, test, package
• Artifact storage → immutable release versions
• Orbnetes → release selection, approval, promotion, rollback, audit, environment delivery That separation gives teams a more resilient software delivery model. Your source platform can do what it does best. Your release platform can do what it does best. And most importantly, your ability to deploy is no longer completely hostage to the same system that hosts your pull requests and build triggers.

Final thought

CI platforms are excellent engineering tools.

GitHub Actions is powerful. GitLab CI is powerful. Jenkins is still deeply useful in many environments.

This is not about replacing CI.

It is about stopping the habit of turning CI into the place where every deployment, approval, rollback, and production release decision must live.

At small scale, that coupling feels efficient. At larger scale, it becomes operational debt.

Build in CI.
Release through CD.
Keep them connected — but not fused.

That is the idea behind Orbnetes.

And I think more teams are going to move in this direction over the next few years.

Thanks!