Loading...
Runtime Isolation
Every preview, test run, validation job, delegated inner-runner session, and self-repair candidate executes inside gVisor (runsc): a userspace kernel that puts a full syscall-interception boundary between anything CrewWork runs on your behalf and the host operating system. Container creation fails closed if the pinned gVisor runtime is unavailable, so untrusted work never silently falls back to the host’s ordinary runtime.
The Primer
gVisor is a userspace kernel. Instead of letting a container talk to the host Linux kernel directly, gVisor’s sentry process intercepts every system call and re-implements the parts of the Linux kernel surface an application needs, entirely in user space, through its own runtime, runsc. A container running under runsc still looks like an ordinary container from the outside, but there is now a full kernel-boundary sandbox between anything running inside it and the real operating system underneath. If untrusted or AI-generated code were to find a kernel-level exploit, it hits gVisor’s reimplementation of that surface first, not your host kernel.
CrewWork pins gVisor release-20260727.0, checksum-verified separately for x86_64 and arm64, installed by a host installer script that registers runsc as an additional Docker runtime rather than replacing Docker’s default. Trusted platform services and GPU-backed containers are unaffected and keep running on the host kernel. Only the containers that touch untrusted, generated, or candidate code opt into gVisor. Container creation for those workloads fails closed if the pinned runtime is unavailable, rather than silently falling back to the host’s ordinary runtime.
Coverage & Resource Caps
Every place CrewWork executes code it did not write itself, or code it generated but has not yet earned your trust, runs behind the same kernel boundary: preview containers, test runs, validation and matrix jobs, delegated inner-runner sessions, self-repair candidates validated from an isolated worktree that never touches your live checkout, and release image builds.
gVisor sets the kernel boundary. CPU, memory, and process-count limits set the blast radius inside it. Caps vary by role, from a single CPU and 256 processes for a short-lived scanner up to 2 CPUs and 4 GB for a full delegated inner-runner session, and every one of them is enforced by Docker’s own cgroup limits on top of the gVisor boundary.
2 CPUs · 4 GB · 1,024 processes
This ceiling is fixed rather than a tunable default. Every session container for the delegated inner-runner execution backend launches with runtime="runsc" and this exact cap.
2 CPUs · 2 GB · 1,024 processes (default)
The process ceiling is configurable per deployment, with a floor of 16, so a runaway fork storm still gets stopped even at the smallest setting.
2 CPUs · 2 GB · 1,024 processes (default)
Applies to every invocation across the test engine. See Testing & Quality Gates for the full language-stack breakdown.
2 CPUs · 2 GB · 512 processes (default)
Stages a workspace snapshot from the calling container, then runs unit, integration, static-analysis, and security checks inside its own sandbox.
2 CPUs · 4 GB · 512 processes (default)
The privileged supervisor that hosts a private Docker daemon for the candidate app. It keeps the host cgroup namespace on purpose, so its pinned runsc can bound the inner sandbox; candidate code itself never leaves that inner sandbox.
1.5 CPUs · 2 GB · 256 processes (default)
The generated application itself. Every Linux capability is dropped except the four needed to chown files, bind low ports, and drop privileges after startup.
1 CPU · 1,536 MB · 256 processes
Runs read-only as a non-root user, on an ephemeral network scoped to the exact preview app under test, then torn down.
Preview Network Identity
A preview environment runs generated, unreviewed application code, and it typically exposes a public-facing port. That combination gets three layers of protection on top of the gVisor boundary itself, so a compromised or malicious preview cannot reach the rest of your CrewWork deployment.
Test Execution
Test-run containers get no Docker socket and no mounted volumes. When a language stack needs dependency installation, that step runs first, briefly, on a network-enabled bridge connection against an allowlisted package index. Once dependencies are staged, the container is disconnected from every network, and that disconnection is programmatically verified before your actual test command ever runs. If verification fails, the run raises a network_isolation_failed error and stops, instead of silently executing your tests with network access they should not have. See Testing & Quality Gates for the full 10-language test engine this protects.
Release Builds
Release and candidate OCI image builds do not run through the host’s ordinary container build path. CrewWork ships a custom buildkit-runsc image: a patched BuildKit and containerd, version-pinned, bundled with the same checksum-verified gVisor runsc binary used everywhere else. That means the build process for release and candidate container images executes inside the identical gVisor sandbox boundary as runtime workloads, not the host’s default runtime. The isolation guarantee covers how release images are built, not only how they run afterward.
Defense in Depth
Kernel-boundary sandboxing is the foundation. Two more layers close off attack classes that sandboxing alone does not address.
Untrusted XML, including scanner report output and indexed project content, passes through a single hardened boundary built on defusedxml, with DTDs, external entities, and entity expansion all forbidden. Malformed or unsafe XML raises a typed error instead of silently resolving an external entity, closing off the classic XXE attack class.
Production ingress terminates TLS 1.2 and TLS 1.3 with HSTS enabled, behind one canonical Nginx route and header authority. Unrecognized hosts fail closed to an HTTP-to-HTTPS redirect, and the certificate is a browser-trusted Let’s Encrypt certificate rather than a self-signed one.
These sit alongside the rest of the platform’s security posture: fail-closed write scope, encrypted secrets, and prompt-injection neutralization. See Security for the complete model.
See exactly how CrewWork keeps a model honest, explore the architecture, or reach out to talk it through.
Or view the architecture for the full technical picture.