01
Write canopy.pipeline.ts
Describe your build and deploy steps as real TypeScript - functions, types, and imports, not a YAML dialect with its own rules for loops and conditionals.
Canopy Pipelines
Your pipeline, written in code that runs the way code should.
Describe your build and deploy logic as real TypeScript instead of a YAML dialect. Canopy compiles it into a graph inside a hermetic sandbox, then runs every step of that graph for real, in its own isolated sandbox, as a gate your deploy has to pass.
Part of Canopy Host. See the full deployment platform →
compiledigest sha256:4a19c2… · 4 nodes
runlint → build → test → deploy
cache2 hits, 2 executed
gatepassed — legacy path continues
Early accessAllowlisted environments today
TypeScriptNo YAML to write or debug
Real gateA failing step blocks the deploy, not just a log line
SandboxedNo clock, no randomness, no network at compile time
The problem
YAML pipelines can’t be tested, refactored, or trusted the way code can.
A pipeline written in YAML has no functions, no types, and no way to run a unit test against its own logic. Teams route around that with templating, anchors, and copy-pasted steps across every repository — workarounds that create the exact complexity YAML was supposed to avoid. And because most pipeline engines execute your configuration directly, nothing stops it from calling an API, reading the clock, or branching on today’s weather — which means the same pipeline can produce a different result on two different runs, for no reason anyone can point to.
Canopy Pipelines removes that gap. Write your pipeline as TypeScript. Canopy compiles it — doesn’t execute it — inside a hermetic sandbox with a frozen clock, no randomness, and no network, into a plain graph. Only then does it run, one sandboxed step at a time.
How it works
Compile hermetically, run as a real gate.
02
Canopy compiles it to a graph
Your file runs once, inside a hardened sandbox with a frozen clock, no randomness, and no network - and produces a plain, static graph of steps and their dependencies. Nothing about that graph depends on what your code does when it runs; it depends only on what your code decided to build.
03
The graph runs, as a real gate
Each step in the graph executes for real, one at a time, in its own sandbox. If a step fails, the gate fails loudly and your deploy never reaches the legacy build path - nothing partial ships.
What you get
A pipeline definition held to the same bar as the code it builds.
Real TypeScript, not a YAML dialect
Your pipeline is a normal .ts file - use functions, shared modules, types, and your existing editor tooling. Nothing about it is a new language to learn or a subset of one to fight.
A pipeline is a graph, not a script
Writing your pipeline doesn’t run it. It produces a plain graph of steps and dependencies, which Canopy schedules, caches, and executes - the same separation a build tool like Bazel or Buck makes, applied to your deploy pipeline instead of your compiler.
Deterministic by construction, not by promise
Your pipeline file compiles inside a hardened sandbox with a frozen clock, no randomness, and no network - the same category of guarantee Bazel gets from Starlark, without inventing a new language to get it.
Every step runs in its own sandbox
No step shares a shell with another, or with the machine that scheduled it. Each one gets a declared resource limit, a declared network egress allowlist, and nothing else - the same isolation model Canopy already uses for sandboxed agent execution.
Content-addressed caching
A step that hasn’t changed - not by name, by actual content - doesn’t re-run. Rename a file without changing what it produces, and the cache still holds.
Fits inside a Canopy Host deploy, not beside it
A Canopy Pipelines graph is one gate inside the same deploy your project already runs - it doesn’t replace Canopy Connect or introduce a second deploy mechanism to keep in sync with the first.
How this fits with Canopy Connect
Adopt what you have. Author what you don’t.
Canopy Connect imports the CI you already run, unmodified, and correlates it with your deploys. Canopy Pipelines is for the pipeline logic you haven’t written yet — when the default staged build isn’t enough and you want real control over what runs, in what order, with what’s cached.
Not a replacement, a second gear
- No canopy.pipeline.ts file: your project builds and deploys exactly as it does today.
- Add one, and that environment’s deploy runs your graph as a real gate before the legacy path.
- One deploy mechanism underneath either way — nothing to keep in sync between the two.
Good to know
This is early access, not a finished product.
Canopy Pipelines is live on a small number of allowlisted environments while we finish the isolation and dependency-verification work a general release needs.
Not ready yet
- Self-serve enrollment — today, an environment is enabled by request.
- Untrusted (fork/PR) pipelines running with the same isolation as trusted ones.
- A public plugin registry for shared pipeline steps.
- Generally available pricing — talk to us about early access instead.
FAQ
Common Canopy Pipelines questions.
Is this the same as Canopy Connect?
No. Canopy Connect imports and correlates CI you already have - your existing GitHub Actions, GitLab CI, or Bitbucket Pipelines config, unmodified. Canopy Pipelines is for writing new pipeline logic yourself, in TypeScript, when you want more than the default staged build gives you.
Do I need to rewrite my existing pipeline?
No. Canopy Pipelines is opt-in. Without a canopy.pipeline.ts file in your repository, your project builds and deploys exactly as it does today.
What happens if a step in my graph fails?
The gate fails loudly and your deploy never reaches the legacy build path - not a warning buried in a log, a real stop.
Can I use npm packages in my pipeline file?
Yes, against Canopy’s own npm-compatible registry or your usual one. Verified, lockfile-checked dependency integrity for pipeline definitions is on our roadmap, not shipped yet - treat a pipeline file’s dependencies with the same care as your app’s until then.
Is this available on every plan?
Not yet. Canopy Pipelines is in early access on a small number of allowlisted environments while we finish the isolation work described above. Request early access below and we’ll get your environment allowlisted.
Get started
Want your pipeline in code, not YAML?
Canopy Pipelines is in early access — tell us about your project and we’ll get your environment allowlisted.