The build pipeline

When you run git push managed <branch>, managed.dev turns your repository into a running site through a fixed, auditable pipeline: detect what the repo is, build it in an isolated sandbox, content-address and sign the resulting artifact, then roll that artifact onto the target environment. You never touch Docker, a registry, or a deploy key — those are platform internals, and the whole sequence runs on a dedicated builders pool that is kept off your site hosts.

This page walks the pipeline end to end. For how the target environment is chosen from your branch name, see branch routes; for what each detected profile builds and serves, see runtimes & site profiles.

The four stages

1. Detect. managed.dev inspects the pushed commit and resolves a site profile — bedrock, vanilla, or static today. Detection keys off the repository shape (a composer.json with the Bedrock layout, a WordPress tree, or a static-output directory). The chosen profile decides which build steps run and how the result is served. See runtimes & site profiles for the full matrix.

2. Build. The profile’s build runs in an isolated, egress-restricted sandbox. The sandbox has no open path to the internet; package managers reach their registries through a managed build proxy with a CONNECT allowlist (npm, Composer/Packagist, PyPI, and the like). This is what lets composer install and npm ci work without giving build code arbitrary outbound network access.

3. Sign. The build output is content-addressed — its identity is the hash of its bytes, so an identical input always yields the same artifact id — and then cryptographically signed. The signature is checked again at rollout, so only artifacts this platform built can ever be deployed.

4. Roll. The signed artifact is rolled onto the target environment — production, staging, or a preview — resolved from your branch via branch routes. The previous release is retained, so a rollback is a pointer move, not a rebuild.

What happens on a push

Terminal

acme-store — git push managed

~/acme-store ❯ git push managed feature/checkout
managed.dev  ▸ detected profile: bedrock (composer.json)
managed.dev  ▸ building in sandbox (composer install, asset build)
managed.dev  ▸ artifact sha256:9f2c… signed
managed.dev  ▸ rolling onto preview environment
managed.dev  ✓ deploy completehttps://acme-store-feature-checkout-a1b2c3.preview.managed.dev

Dashboard

The build detail view in the app.managed.dev dashboard for a single push, showing the four stages — detect, build, sign, roll — as a vertical timeline with per-stage status, the resolved profile (bedrock), the content-addressed artifact hash, and a tail of streaming build log lines.

Build logs stream live

Build output is streamed over server-sent events while the build runs, so you watch composer install or an asset bundle scroll in real time rather than polling for a final blob. The dashboard tails the same stream the public API exposes: a build is a job, and a job carries a links.stream you can GET as SSE.

Watch a build from the API

A deploy returns a job. Tail it with GET /v1/jobs/{id}/stream to follow build and rollout to completion, or ETag-poll GET /v1/jobs/{id} from CI. See async jobs.

Targets: live, staging, preview, ignore

The branch you push decides where the artifact lands. Your default branch (for example main) maps to production; other branches map to staging, preview, or ignore through branch routes. An ignore route means the push is accepted but no environment is built — useful for branches like dependabot/* that you don’t want to spend a build on.

Target	Typical branch	Result
live (production)	main	Built and rolled onto production.
staging	staging, release/*	Built and rolled onto the shared staging environment.
preview	feature branches	Built and rolled onto an isolated, per-branch preview environment with its own URL.
ignore	dependabot/* and similar	Push accepted; no build, no environment.

Why you never see Docker

Customers don’t manage images, registries, or deploy keys because the platform owns all three. The build proxy, the content-addressed artifact store, and the signing keys are operated for you; the only contract you depend on is git push in, running site out. That separation is also a security boundary: build code runs egress-restricted and unprivileged, and the signature gate means a rollout can only ever apply an artifact the platform itself produced.

Where builds run

Builds always execute on a dedicated builders pool, never on the hosts serving your traffic. A noisy or slow build can’t degrade a live site, and a site host is never asked to run untrusted build steps.

Next steps

Runtimes & site profilesWhat bedrock, vanilla, and static each build — and how detection chooses.

Branch routesMap branch names to production, staging, preview, or ignore.

Promote & roll backPromote a reviewed branch to production, or roll back to a prior release.

Async jobs (API)Builds are jobs — tail them over SSE or ETag long-poll from CI.