Why Pipemesh
Merging is no longer the slow part. With agents landing pull requests, a main branch moves many times an hour, and every merge wants to reach production.
Most tools were built for a slower pace: one run per merge, and a person holding the picture in their head. At ten merges an hour nobody can, and what's in staging? what's my change stuck behind? is the fix live? become a hunt through run lists.
Pipemesh is a CI/CD control plane built for that pace: one live view of every change moving toward production, promotion by rules you can trust, and work that runs where you already run it.
Watch one live. demo-showcase merges a change every half minute, around the clock. Revisions flow through build, staging and production, a region fails now and then, and the fix supersedes it.
Two kinds of workload
Deploying a service and releasing an artifact are different processes. Every CI system picks one shape and bends the other into it. Pipemesh ships both, in one repository and one definition.
Workflows are immutable runs, one per trigger, as in GitHub Actions and GitLab CI. They suit releasing artifacts (libraries, images, nightly builds), where the run is the audit record. They also suit pull request checks: one verdict per head.
They don't suit deploying services. Nothing persists between runs, so no run can say what's in staging now. Run-based tools bolt on a deploy tool, or force the deploy into a workflow, one job per environment with manual gates.
Pipelines keep that state. Each commit on the default branch becomes a revision that promotes job by job, and every job remembers the revision it last ran. A change is "in staging" the moment the staging job records it. Watch one go through:
| Use case | Kind | Why |
|---|---|---|
| Deploying a service through staging → production | pipeline | one deployment truth, gates, supersede |
| Releasing a library, CLI, or SDK on a tag | workflow | the run is the immutable release record |
| Building and publishing base images on a schedule | workflow | each run is one auditable publish |
| PR checks | workflow | one verdict per PR head |
| Nightly or scheduled test sweeps | workflow | independent, comparable runs |
The two work together:
- A pipeline job can run a workflow from the same repository, wait
for it and inherit what it built (
job_type: workflow). - A pipeline consumes what released workflows produce, pinned by digest.
- A monorepo's pipeline dispatches revisions to a child pipeline per
service, each on its own timeline (
job_type: pipeline).
See The definition.
Keeping control when changes flow
Fifty revisions in flight should read as clearly as one. Here's how.
Revisions travel together. One line of revisions, not a run per merge. When three agents merge in a minute, you see how far each got and which is current at every deploy. A newer revision supersedes an older one waiting at a slow or failed stage, and nothing is lost.
Below, ten merges land seconds apart. A broken build and a failing region each hold their last good revision, and the newest good one ships.
Skips you can trust. A job skips only when its fingerprint (its definition, the files it reads, what it consumes) matches its last successful run. Path filters compare with the previous commit: if a backend-and-client change fails in the client build, the next backend-only commit ships a backend whose client never built. In Pipemesh the client still differs from its last build, so the skip is refused and the deploy waits.
Green means approved. A revision moves on only when every job it needs has run it, or proved it identical to what it last ran. A failed build holds everything downstream, even a docs-only commit on top (it contains the broken code), while independent deliverables still flow.
Artifacts flow with the revision. Jobs pass artifacts by digest with
produces: and consumes:, in a pipeline or across a workflow job. A
deploy runs only when its artifact is new to it, so the same bytes
rebuilt deploy nothing. A rollback redeploys what shipped, not a rebuild.
Gates and rollbacks live in the pipeline. A maintainer can disable promotions into a job, with a reason, and the board shows what it holds and why. A rollback re-deploys a revision the job already shipped, with its artifacts, and gates the job until someone lets newer ones in.
Monorepos and many repositories. A monorepo keeps one definition and one mainline. A dispatch job per service sends each revision to that service's child pipeline when its inputs changed, judged by the build tool's own fingerprint (Bazel, Nx and Turborepo each have a component) or by the service's files.
A pipeline can also declare other repositories: each revision pins a commit of each, a push to any starts one, and artifacts cross between them. See Turborepo, Nx, Bazel and several repositories.
Run it anywhere. Jobs run on hosted runners, on your own runners, or as your existing GitHub Actions workflows: a pipeline job dispatches one, shows its jobs as tasks, and settles on its verdict. Keep the workflows you have, and move a job when you want. Jobs that need cloud credentials get a short-lived identity token, not a stored key.
One snapshot, for people and agents. Is the fix in production yet? shouldn't mean matching commits across your CI, deploy and inventory tools. For an agent, that's guessing.
In Pipemesh it's one API call: what was built, which revision each environment runs, what's queued, what a gate holds and why, and what changed since. It's recorded, not inferred: a revision shows in staging because the staging job recorded running it.
How it compares
| Pipemesh | Run-based CI (GitHub Actions, GitLab CI/CD) | Deploy tools (Argo CD, Spinnaker) | |
|---|---|---|---|
| What does a merge create? | a revision that moves through one long-lived pipeline (or a workflow run, for checks and releases) | a new, separate run | a sync of whatever it's pointed at |
| What's in staging right now? | each job records the revision it holds: one view, one API call | piece it together from the run list or an environments page | known, for what the tool itself deploys |
| Ten merges in a few minutes? | one line of revisions; the newest supersedes the ones queued behind it; a failure holds only its own lane | ten runs; find which later one carried your change | not its concern: it deploys what it's given |
| When can a job skip? | when its inputs match its own last successful run, so a change that failed to build is never skipped past | when path filters see no change since the previous commit, even if that commit's build failed | not applicable |
| How do artifacts move between jobs? | declared with produces: and consumes:, pinned by digest, across repositories |
uploaded and downloaded by name, within one run | pulled from a registry |
| Does an unchanged artifact redeploy? | no: same digest, the deploy skips on its own | yes, unless you write a digest check yourself | no: it syncs only when the desired state changes |
| How do you hold or roll back a deploy? | hold promotions into a job with a reason; roll back to the artifacts a revision shipped | environment protection rules; rolling back means re-running an old run | built in |
| Where do jobs run? | hosted runners, your own runners, or your GitHub Actions | the vendor's runners, or self-hosted ones | your cluster |
| Which monorepo services build? | the ones the build tool's own fingerprint says changed (Bazel, Nx, Turborepo) | the ones path filters match | not applicable |
Where others are stronger:
- GitHub Actions and GitLab have the marketplaces, editors and defaults, and most teams' working workflows. That's why a Pipemesh job can run on those workflows rather than replace them.
- A deploy tool that reconciles a cluster knows the cluster's real state; a pipeline doesn't. Pipemesh shows what the pipeline deployed, which can be wrong after a change made outside it.
- Bazel, Nx and Turborepo know their build graphs better than any CI layer, so Pipemesh asks them rather than guessing.
One definition
Everything a repository runs is declared in pipemesh.yaml at its
root, under one reserved key, pipemesh:: the pipeline under
pipelines:, releases and checks under workflows:, each with its
triggers. The rest of the file is yours.
The catalog lists every enabled repository. Each workload gets a URL and a run history, and each pipeline a live board. Start with Getting started and The definition.