Releases & On-Call

Build once, deploy to your own network, stay accountable

CrewWork builds a versioned OCI release artifact from your project and ships it to any host on your own LAN, through a narrow agent that only ever calls out. No inbound connectivity to the target host is required, and a deployment failure pages the right person automatically instead of waiting for someone to notice.

Outbound-only mTLS agentgVisor-isolated buildsAutomatic failure escalation

LAN Releases

A deployment path that never asks your network to open a port

CrewWork builds a linux/amd64 or linux/arm64 OCI release artifact for your project and stores it in an opt-in, intranet-only registry. You install a small release agent container on whichever host should run it, your own workstation, a rack server, a home lab box, anything reachable on your LAN. The agent never listens for inbound requests. It polls out over mutual TLS, claims the next queued deploy, and carries it out against that host’s own Docker socket.

This is a separate pipeline from HotFix and Infinite Coder delivery, which land project code changes on isolated local delivery branches (push disabled by default). LAN releases pick up after that: they take a built artifact and get it running on infrastructure you control. Every deploy request moves through a fixed set of states so you always know exactly where it stands.

Landing on the Releases surface without picking a project shows a fleet view: every project you have deployment access to, its environment counts, the latest artifact with SBOM, VEX, and attestation status, and current deployment posture. The workbench’s Releases surface offers self-service deploys: pick a signed artifact and an environment, deploy it, and watch health history, alongside host enrollment and environment setup. Rollback stays a deliberate, human-triggered action, never automatic. Initial provisioning (release CA setup, per-host agent certificates, registry credentials) remains an operator command-line step.

Outbound-only: the release agent polls a certificate-authenticated /work endpoint over mutual TLS. Nothing inbound reaches the target host to trigger a deploy.
Locked down at the container level: read-only root filesystem, every Linux capability dropped, privilege escalation disabled, a 128-process limit, and a 256MB / 0.5 CPU resource ceiling.
Four operations only: deploy, health, rollback, and remove, executed directly against the host’s own Docker socket.
Registry-sourced: artifacts come from an opt-in private registry, enabled with a single deployment profile. Release tags derive from the exact source commit and build recipe, and image deletion is disabled, so a published artifact cannot be silently deleted or quietly swapped under the same identifier.

queued

Deploy request accepted and waiting for the release agent to claim it.

running

The release agent is executing the deploy against its host Docker socket.

healthy

The deployment passed its health checks and is the current release for that environment.

failed

Deploy or health checks failed. This is one of the three events on-call escalation watches for.

superseded

A newer deployment replaced this one as the environment’s current release.

rolled back

The environment was reverted to its prior healthy deployment.

removed

The deployment was explicitly torn down from the target host.

Build Isolation

The build itself runs sandboxed, not just the deploy

Release images are built by a dedicated BuildKit worker that embeds its own patched buildkitd and a bundled containerd runtime, rather than sharing the host’s default container runtime. Every RUN step in your Dockerfile executes under gVisor (runsc) on an isolated bridge network with its own dedicated cgroup, so building a release artifact from repository-authored instructions gets the same kernel-level sandbox boundary as everything else CrewWork runs on your behalf. See Runtime Isolation for the full sandboxing model across previews, tests, and validation.

On-Call

A failed deployment pages someone. Automatically.

Teams define timezone-aware on-call schedules and escalation routes once, and CrewWork handles the rest whenever a release goes wrong. Escalation targets read the same organization and team roles described in Organizations & Teams, so paging “team leads” or “organization admins” always reflects who actually holds that role right now.

Teams manage rotations and escalation routes directly in the workbench’s Organization surface, on its On-call tab, as well as through the API.

A schedule is a rotation: an ordered list of participants, a rotation start time, and a shift length. Whoever is on shift is computed from elapsed time, not a manually updated calendar.
An escalation route is a named path made of ordered steps, each with a delay and a target: the person on call, the team leads, or the organization admins.
Three events trigger escalation automatically: a failed deploy, an unhealthy deployment, and a failed rollback. No one has to notice a failed deploy and page someone manually.
Notifications are persisted to a durable outbox and delivered as per-user webhooks, rechecking live project, team, and route authority immediately before each external send. Each person sets their own delivery URL from Settings, with loopback, credential-bearing, and local-network targets rejected automatically.
Removing someone from a team automatically reindexes or disables the rotations and routes that named them, so an escalation step never silently pages someone who has already left.

Local-First, End to End

What your teams build gets a deployment path too

CrewWork itself already runs single-host and local-first, so the natural next question is where the software it helps you build actually goes. LAN releases answer that without asking you to open your network to the outside: the release agent only ever calls out, and the artifact only ever moves to hosts you choose. How much confidence you have in what is inside that artifact is a separate, related question, one covered by the coverage, security, and code-health signals on Testing & Quality Gates. See Compare for how this fits the rest of CrewWork’s deployment model.

Compare deployment model

Proof, not promises

See exactly how CrewWork keeps a model honest, explore the architecture, or reach out to talk it through.

Get in Touch Truth & Trust Engineering

Or view the architecture for the full technical picture.