This post is for the people inside a lab who own environments: the research engineers who evaluate vendor data, design rewards, and run the QA that catches reward hacking before a model learns it. It says when denv is worth your time, how it fits a lab's setup, and what you get back, with the usual footer on what ships today.

The situation it is built for

A lab environment team in 2026 buys from a dozen or more vendors, mandates a task format (usually Harbor), and still ends up with a dozen runtimes. Each vendor ships environments the way their sandbox provider shaped them: one container, rebuilt per episode, a grader that runs inside the agent's container afterwards, network rules that differ per vendor, no snapshot of anything with state. The team's work becomes re-running the same checks per vendor: does the agent run as root, can it reach the internet, can it tamper with the grader, does the world drift between episodes, and why did last week's score move by six points when nothing in the model changed.

Three facts from the public record shape the problem:

Infrastructure alone has moved benchmark scores by six points, from memory configuration, with the authors advising that differences under three points deserve skepticism.
Cold-start variance across sandbox substrates has been measured at more than a hundred times, and worker-hours per million trajectories nearly double depending on where rollouts run.
A public test of five environment frameworks found four fail two or more of five basic grader-integrity checks out of the box.

None of those are the vendors' fault and none are yours. They are properties of the runtime under the environment, and the runtime is the one thing every vendor is free to choose differently.

When

Use denv when at least two of these are true:

You take environments from more than two vendors and want one answer to "how was this run" that does not depend on the vendor.
The environments are systems, not single containers: a database with state, a queue, an object store, services the agent operates on. Ops, SRE, data-pipeline, enterprise-SaaS replicas, support workflows.
A reward or an eval moved and nobody could say which world it ran in. You need versions with a snapshot, not an image tag.
Rollouts must stay inside your network. Vendor data, model outputs and trajectories never leave the VPC.
Your QA for reward hacking is manual per vendor and you want the file-level class of it closed by construction so the team can spend its budget on the semantic class.

If your environments are single-container coding tasks on an existing provider, denv is a marginal gain and you should say so to whoever is pitching you.

How

Inside your network. The control plane is one container with a database; the CDK stacks in the repository stand it up in a lab account in an afternoon, or it runs as a single process with SQLite for a team. Nothing in it dials out to your machines. Targets are Linux hosts you already have, with a ZFS pool for one-second forks, joined by a sidecar that opens one outbound connection.

Vendors deliver in the format you already mandate. A Harbor task directory runs on denv unchanged: harbor run -e denv.harbor:DenvEnvironment. Compose-based worlds deploy as projects with a version and a snapshot; single-image tasks become sandboxes with their working directories persisted. Inspect and OpenEnv work the same way. Vendors do not need to know denv exists; they can, and then they can show you the record before you ask.

Every environment gets the same five properties, regardless of vendor or framework: the agent is never root; the grader runs as a separate principal, after the agent is stopped, on a fork; submissions with symlinks, FIFOs, devices or sockets score zero before any grader runs; memory, pid and cpu caps on every service; egress denied and proven by a probe before each episode.

The QA loop becomes a fork loop. Take a vendor's world at version A. Fork it a hundred times for the hidden split. Fork it again for the reward-hacking probes: your scripted attackers, your hacker agents. Each fork is identical to the byte, which the snapshot's per-volume digests let you check. The verdict for each run is in the record with the digests, the egress probe, the refusals and the grader's output.

Vendor updates pass gates, not vibes. When a vendor ships version B of a world, a promote runs a fresh fork, a consistency check across datasets, N identical replays, invariants (nothing deleted, disabled or silenced), and a soak before the next stage points at it. The gate record is the environment's data sheet.

What you get back

Reproducibility you can defend. A result names the version it ran on, and the version names its digests. When a number moves, the first question has an answer.

Diligence done once, not per vendor. The five checks are enforced by the runtime and recorded per rollout. The team stops re-deriving them for each delivery and reviews records instead.

A reward-hacking surface with the easy half removed. File-level attacks are refused by construction. The hacker agents in your pipeline can spend their whole budget on the semantic ones, which are the ones that matter.

Worlds with state, at training scale. Multi-service environments with real data, forked per rollout in about a second on ZFS instead of rebuilt per episode. GPUs stop waiting on sandbox cold starts.

Vendors on one floor. A record format you can ask every vendor for, from a runtime you control.

A worked example

The next post, A week with three vendors, runs this example with the data sizes, the fork counts and the records written out.

A lab buys ops environments from three vendors: incident response on a service mesh, a data pipeline with a scheduler, and a SaaS replica with a support queue. Today each arrives on a different provider with a different grader model, and the team spends a week per delivery re-running its own checks.

With denv in the lab's VPC, each delivery is a compose file and a task directory. Deploy, warm, snapshot: version A, with digests. Run the hidden split as a hundred forks per task; the records go into the eval ledger. Run the reward-hacking probes as another hundred forks; the file-level ones are refused at collect time and show up as refused in the record, the semantic ones get the team's attention. Promote A through the gates. Train against it with the trainer the lab already uses, which reaches the environment through Harbor or OpenEnv. When the vendor ships B, the gates say whether the numbers moved because the world moved.

The week per delivery becomes a day, and the day is spent on the environment's content rather than its plumbing.

Status

Ships today. Control plane with SQLite or DynamoDB; sidecar with dir and ZFS storage; deploy with phases and rollback; snapshot with per-volume digests; fork; verify as a separate principal with special-file refusal; grade-only fast path; egress deny with probe; caps; non-root agent; Harbor, Inspect and OpenEnv adapters passing conformance; CDK stacks for an AWS account; GitHub sign-in and push-to-deploy; sandbox-provider drivers for E2B, Daytona, Prime and Modal in code, untested live.

Committed by this post. Promote gates and the data sheet; the frozen clock and egress replay; a measured fork time on a production ZFS host; a flagship ops world shipped with a task pipeline as the worked example; SOC 2 ahead of the first pilot.

The pilot offer stands: bring a world that is hard to run; we deploy it in your account, fork it, grade it, and agree a pilot if it fits.