Targets

A target is a host that can take environment commands. There are two kinds.

Kind	What it is	Connection
sidecar	A machine running denvd: your own, or one denv provisioned in your cloud account.	The sidecar's outbound WebSocket. connected is true while the stream is open.
driver:<provider>	A hosted sandbox provider (e2b, daytona) driven by the control plane with your token.	None; the provider's API. connected is always true.

GET /v1/targets lists both, sidecars first, each with kind, provider (driver hosts), connected, capabilities (the sidecar's report, or the provider's static row), and, for providers, table.

Clouds and hosts

A cloud is a credential and configuration record (POST /v1/clouds, POST /v1/targets/connect). A host is a target. The mapping:

Provider	Cloud config	What it produces
manual	none	Nothing. Hosts join with a token you run on a machine.
hetzner	token (required), server_type (cpx31), location (nbg1), image (ubuntu-24.04)	Machines created on demand by the provision phase; each joins as a sidecar host with the cloud's id.
e2b	token	One driver host named e2b with status connected. Untested against the live provider.
daytona	token	One driver host named daytona. Untested against the live provider.

A driver host is created by POST /v1/targets/connect, or on demand for a cloud created through POST /v1/clouds the next time targets are listed or placement runs (EnsureDriverHosts). Each cloud has at most one driver host.

Join tokens

POST /v1/join-tokens {cloud_id?} returns a djt_… token valid for one hour, single use. A sidecar presents it in its first hello; the control plane assigns the host id and a dhs_… secret, records the host with the token's cloud id, and marks the token used. A used or expired token is refused with join: join token already used / join: join token expired. The response's command field is a paste-able install line using the control plane's own denvd download route.

Placement

For a deploy, the place phase chooses in this order:

1. The host the environment already lives on, if connected (its datasets are there).
2. The named target, when the request pins one (POST /v1/targets/{name}/sandboxes, or DeployTo): the cloud's driver host, else any connected sidecar joined through that cloud; otherwise target "<name>" (<provider>): no connected host.
3. The first connected host of the team. Connected hosts are listed sidecars first, then driver hosts, so a machine you run is preferred over a provider.
4. Nothing: provision creates a machine through the first non-manual cloud, and join waits up to 6 minutes for it. With no such cloud the deploy fails with no connected host and no cloud that can provision: connect a cloud or run denvd join on a machine.

Forks, snapshots, rollbacks, verifies, and destroys always run on the environment's own host.

Capability table

The static row returned as table for each hosted provider (internal/drivers/caps.go):

Provider	Multi-service	Snapshot	Fork	Fork time	Egress deny	Caps	GPU	Verify	Notes
e2b	no	pause (sandbox persisted)	—	n/a	provider network config	provider tier	no	no	one sandbox per environment; pause/resume keeps state, no branch
daytona	no	snapshot to image	new sandbox from snapshot	tens of seconds	limited	provider tier	partial	no	—
modal	no	filesystem + memory snapshot	restore from snapshot	seconds	block_network	per sandbox	yes	no	driver not shipped: Modal's sandbox API is Python-only
prime	no	snapshot	new sandbox from snapshot	seconds	yes	per sandbox	yes	no	driver not shipped

A sidecar host's capabilities are what it detected (see Protocol); on a ZFS pool a fork is a clone and takes about a second, on dir storage it is a copy.

What each driver does today

Both drivers are implemented against the providers' public REST APIs and tested only with recorded request shapes; neither has been run against the live provider.

Command	E2B	Daytona
env.create	POST /sandboxes with the image as templateID; a command is started in the background. Single service only.	POST /sandbox with image (falls back to snapshot), polled until started; a command is started in the background. Single service only.
env.exec	Process RPC on the sandbox's envd.	POST /toolbox/{id}/toolbox/process/execute.
env.put / env.get	One file at a time through the envd files API.	One file at a time through the toolbox files API.
env.snapshot	pause then resume; reports one dataset.	Refused: Daytona's snapshot API builds images, not snapshots of a running sandbox; …
env.fork	Refused: E2B has no fork: pause/resume continues the same sandbox and cannot branch it; use your machines or Daytona for forks	Refused: fork needs a sandbox snapshot, which is not enabled yet for Daytona
env.destroy	DELETE /sandboxes/{id}	DELETE /sandbox/{id}?force=true
verify.collect, verify.run	Refused: e2b: <kind>: not supported on e2b yet	Refused likewise.

A multi-service spec sent to a provider fails at prepare with <provider> runs one container per environment; use your machines for multi-service stacks (N services declared). Provider sandboxes report no endpoints.

Not yet available

AWS provisioning (the control plane itself deploys on AWS; customer machines on AWS are joined manually today), Modal and Prime drivers, GPU hosts, and verify on any hosted provider.