Docs · explanation

Concepts

Projects, environments, deployments and versions, and why an environment is a system rather than a container.

denv is the environment company. This page is the vocabulary everything else uses.

An environment is a running system

A container image is a recipe. An environment is what is running: the database with its rows, the queue with its backlog, the object store with its files, and the box an agent gets a shell in, all on one network. For a coding task that may be one container. For an ops task it is five services and a few gigabytes of state, and that is the case denv was built for.

Because an environment is a system, three operations matter that a container runtime does not offer: a snapshot that captures every service's data at the same instant, a fork that gives you a new copy of the whole system with that data, and grading apart from the agent, so the thing that scores an episode never shares a process tree with the thing being scored.

The four nouns

Noun What it is How it is created
Project A repository with a kind: rl-environment or agent denv project create, or connecting a GitHub repo
Environment A running stack on one target. Every project gets alpha. A fork is an environment whose parent is a version deploy, fork
Deployment One change to an environment, run as ordered phases, each with evidence deploy, snapshot, verify, fork, rollback, promote, destroy
Version Pinned image digests plus a consistent snapshot of every volume every successful deploy or snapshot

A deployment is not a version. An environment has many deployments over its life; a version is immutable and can be forked or restored at any time. A sandbox, the word frameworks use, is an environment created for one episode, usually by forking a version.

Phases and evidence

Every deployment kind has a fixed list of phases. A deploy is resolve → place → provision → join → prepare → start → health → warm → snapshot → ingress → verdict. Each phase records evidence: which host was chosen and why, which digests were pinned, how long the writers were frozen for the snapshot, what the egress probe found. If a phase fails, the rest are skipped and the verdict reverts the environment to its previous healthy version; the deployment's status is rolled_back, and the agent never sees a half-deployed world.

The record of phases is the thing you show someone who asks how an environment was run. It is produced by the runtime, not written by hand.

Targets

An environment runs on a target the user connects. denv never owns the compute.

  • Your machines. Any Linux box running the denvd sidecar, which opens one outbound connection to the control plane and never listens on a port. With a ZFS pool, snapshots are atomic across volumes and a fork takes about a second.
  • Machines denv provisions in your cloud account, on Hetzner or AWS, with the sidecar installed by cloud-init.
  • Hosted sandbox providers such as E2B and Daytona. No sidecar; the control plane drives the provider's API with your key. These run one container per environment, and snapshot and fork are as fast as the provider makes them. The console shows a capability row per target so nothing is promised a target cannot deliver.

Protections by default

For the rl-environment kind, every environment gets the five properties a lab's environment engineer checks for, regardless of which framework runs inside:

  1. The agent is never root. A compose file whose agent service lacks a non-root user is refused at resolve.
  2. The grader runs as a separate principal, after the agent's processes are stopped, on a fork.
  3. Special files in submissions are refused: a symlink, FIFO, device or socket scores zero and the grader does not run.
  4. Memory, process and CPU caps on every service.
  5. Egress is denied, and a probe from inside the environment's network proves it before the episode.

These are properties of the environment runtime, so Harbor, Inspect, OpenEnv, verifiers, HUD and Karotte all get them without changes to the task.

The framework is yours

denv does not run an agent loop, judge a task, or train a model. Harbor, Inspect, OpenEnv, verifiers and HUD do those things, and they reach denv through one small sandbox API: create, exec, files in and out, snapshot, fork, destroy. Trainers reach it through Harbor and OpenEnv. The environment is denv's; everything above it is the user's.