# Untrusted code never touches your kernel 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. gVisor (runsc)Kernel-boundary sandboxingFail-closed by defaultChecksum-verified ## What gVisor isolation actually means 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, with the same fail-closed behavior described above. ## From preview to release, a hard ceiling for every container class 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. ### Delegated inner-runner sessions 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. ### Infinite Coder isolated command execution 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. ### Test-run executor 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. ### Job runner (matrix & validation jobs) 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. ### Preview outer runner 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. ### Preview candidate app 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. ### DAST scanner (ZAP) 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. ## A preview is not just another container 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. - A signed identity: each preview-runner container carries an HMAC-SHA256 signature over its project, container name, instance ID, created-at, and expiry, verified before the orchestrator will trust or reuse it. An ambiguous or duplicate identity hard-fails instead of guessing the newest running container. - Network isolation: the inner Docker daemon’s bridge network is pinned to an address pool that never overlaps CrewWork’s own service networks, so a preview cannot reach platform infrastructure by coincidence. - Active egress blocking: the runner entrypoint installs iptables and ip6tables DOCKER-USER DROP rules naming the protected internal ranges, so a preview container is actively refused if it tries to reach them, not merely absent from a routing table. ## Test execution is verified network-isolated 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 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](https://crewwork.ai/quality/) for the full 10-language test engine this protects. ## The build pipeline is sandboxed too 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 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. ## Isolation is layered, not singular Kernel-boundary sandboxing is the foundation. Two more layers close off attack classes that sandboxing alone does not address. ### Hardened XML parsing 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. ### TLS 1.2/1.3 ingress with HSTS 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](https://crewwork.ai/security/) for the complete model. ## Related reading Runtime isolation is one layer of a larger system. These pages cover the rest. [ ### Security The broader security model this page fits into: fail-closed write scope, encrypted secrets, and network isolation. ](https://crewwork.ai/security/)[ ### Testing & Quality Gates The test engine and the aggregate quality gate that run inside these same sandboxed containers. ](https://crewwork.ai/quality/)[ ### Platform How Platform Self-Repair puts these sandboxes to work end to end, from triage to a draft pull request. ](https://crewwork.ai/platform/)[ ### Architecture The full system architecture, including where the Container Orchestrator and preview runner sit. ](https://crewwork.ai/architecture/) ## Bring your next piece of work. Discuss what you want to build, repair, or improve, along with your deployment needs and access to CrewWork. [Discuss your project](https://crewwork.ai/about/#access) [Truth & Trust Engineering](https://crewwork.ai/trust-engineering/) Or [view the architecture](https://crewwork.ai/architecture/) for the full technical picture. --- Canonical page: https://crewwork.ai/isolation/