Sessions are durable.
Computers are disposable.

envend is a gateway that vends computers. An agent harness asks it for a machine — over MCP, or from a terminal — and gets a full Linux box with root, a network and a disk. The files land on your own machine as an ordinary directory; commands run over ssh in the box; nothing about it is ever published to the internet unless you say so, one port at a time. It is en-VEND: a vending machine for computers.

The problem

An agent session and the computer it works on are different things, and almost everything builds them as one. So the harness either runs commands on your laptop, where a bad rm is real and a broken toolchain is yours to fix, or it gets a vendor's box that is narrow enough to be safe and too narrow to install a package in. Either way the computer and the session are welded together, and you cannot change one without losing the other.

What envend is

envend is a stateful gateway between a harness and whoever is renting you computers. It is harness-agnostic: it speaks MCP over HTTP, and it also gives you ssh and a real filesystem mount, so anything with a shell tool and a file editor needs nothing new to work in a sandbox. It is provider-agnostic: a connector declares what its backend can do in a small closed vocabulary, and every sentence the gateway says about a machine is built from that vocabulary rather than from a vendor's name. It is deliberately incurious about what you run: it makes the machine, connects you to it, and executes the commands your profile gave it. And it holds the policy a raw provider API has no way to hold — how long a machine has been idle, when to stop it, when to wake it, and when an agent has asked for it to be left alone.

How it works

The interactive version of this — every part, every wire, and five scenarios that light up the ones they use — is at /topology, served by the same gateway. It is drawn 1740 pixels wide and does not survive being squeezed into a frame on a phone, so this page carries a diagram that reflows and links to the real one.

The gateway asks a provider for a machine and bakes three keys into it at create. The machine boots envd, our static agent, as pid 1; envd opens one tunnel and, behind it, runs an SSH server, an NFS file server and a small control API. Your envend CLI holds the matching key and dials the sandbox directly — the gateway is not on that wire, it only handed each end its key. The gateway keeps a second tunnel of its own, which is what serves a shared port, a file link and the sandbox's own control calls.

What you get

A real mount

envend mount <name> puts the sandbox's /work on your machine at ~/envend/<name>/work over NFS. Your harness reads, searches and edits with the tools it already has. Files show as owned by you on your side and by the workspace user inside the box, so a checkout is editable in both places with no chown anywhere.

A real shell

envend ssh <name>, or plain ssh <name> once envend mount has written the host block. Interactive commands, scp, rsync, port forwarding — everything an exec API is bad at.

Sharing, on demand

A sandbox has no public port, ever. envend share <name> 4000 serves that one port at https://<sandbox>-4000.envend.dev through the gateway's own tunnel; envend unshare takes it away instantly, for everyone. envend link does the same for one file.

Identity without secrets

A sandbox stores no long-lived credential. It declares who it may be — an AWS role, a Doppler identity, a list of GitHub repositories — and envd mints short-lived tokens from the gateway's OIDC issuer behind the interfaces aws, doppler and git already use.

Sleep and wake

The gateway stops machines nobody is using and wakes them on the next command, ssh connection, mount or shared-URL request. /work comes back untouched. envend hold keeps one awake while a long detached job runs.

Any image

Name node:22, postgres:17 or your own private build. The gateway pulls it, appends one layer holding envd, takes the entrypoint and pushes the result — the image's own command becomes a supervised service. Nothing else about it changes.

Works with

Harnesses. Anything that speaks MCP over streamable HTTP: Claude Code, an SDK agent, an editor, a cron job. It registers one URL and gains thirteen tools. Anything with a Bash tool can skip MCP entirely and use envend and ssh.

Providers. Fly Machines and exe.dev are connected and running today. A third connector for AWS EC2 is written and unit-tested against a stubbed HTTP layer but has never been run against a real account — it is hypothetical, and it exists mostly to find the places the gateway was secretly shaped like Fly.

Devcontainers. They run inside the VM, unchanged. A profile's create hook brings one up with the ordinary devcontainer CLI, and every command after that goes through devcontainer exec. envend does not know what a devcontainer is; the profile does.

The boundary

envend makes the VM and connects you to it. What runs inside is yours. There is no template language, no build system and no repository model: a workspace is a directory and three shell strings — create, which runs once per disk, start, which runs on every boot, and exec, a prefix every later command is put through — plus the user to run them all as. Empty means nothing runs. envend does not know what a repository is, what a container is, or what "up" means for your project; it knows those strings and it runs them, and when one fails its exit code and its stderr are the answer you get.

Get started

The CLI is one static binary. Build it from the repo, or take one from a release — darwin and linux, amd64 and arm64.

cd cli && go build -o envend .

envend login https://gateway.envend.dev --token-stdin   # token on stdin, never argv
envend up omega                                         # create one from a profile; prints its name
envend mount omega-k4zt                                 # /work lands at ~/envend/omega-k4zt/work
envend ssh omega-k4zt -- mix test                       # run anything, in the sandbox

To give a harness the same thing over MCP, register the gateway's /mcp endpoint with your bearer token. For Claude Code:

claude mcp add --transport http -s user envend \
  https://gateway.envend.dev/mcp \
  --header "Authorization: Bearer $ENVEND_API_TOKEN"

Then read working from a harness, or start with the concepts.

How is this different from…

GitHub Codespaces

Codespaces gives a person a cloud dev environment, on GitHub's machines, on GitHub's image contract. envend gives an agent's harness a machine on whichever backend you connected, leaves the harness on your laptop, and adds the pieces a session needs rather than an editor needs: a mount, a revocable share, and workload identity.

DevPod

The closest in shape — a client that creates dev containers across many providers, and a good tool. It is aimed at an IDE session. envend is aimed at a harness: sandboxes are meant to be thrown away rather than kept, the gateway is stateful and owns idleness and wake, and the MCP surface means the agent can vend its own computer without you in the loop.

Coder

A self-hosted platform for long-lived developer workspaces, defined in Terraform and usually reached through a browser IDE. envend has no template language — the whole declaration is four strings — no browser IDE, and a much smaller promise: one gateway, one binary, machines you expect to destroy the same day.

E2B, Modal and other sandbox SDKs

Those are excellent at what envend's connectors do: create a machine and run code in it, through one vendor's SDK. envend sits a layer up. It talks to backends through one contract, so the choice of vendor is a field on a create call, and it adds what an exec API does not have — a mounted filesystem, real ssh, sharing you can revoke, and OIDC identity. Today the connected backends are Fly and exe.dev.

Running the harness inside a container

This works, and it is what most people do. The cost is that your harness, your editor state, your credentials and your context all move into the box, and the box has to be rebuilt whenever any of that changes. envend moves only the computer. Your devcontainer still runs — it runs inside the VM, unchanged.