FAQ

The questions that come up first, answered against what the code does today. Where something is planned rather than built, it says so.

Is a sandbox reachable from the internet?

No. Not for ssh, not for the file share, not for anything you start inside it, on any backend, and there is no flag that adds one. The only public thing about a sandbox is a port you have explicitly shared or a file you have explicitly linked, and both of those are served by the gateway, on the gateway's domain, over the gateway's own tunnel. See Sharing.

What egress does a sandbox need?

One hole: outbound TCP 443 to the relay. Everything a sandbox does with the outside world on envend's behalf goes through that one connection, including everything it says to the gateway that created it. Nothing inbound. Whatever your workload needs — a package registry, an API — is a separate question.

Does my harness have to run inside the sandbox?

No, and that is rather the point. The harness stays on your machine. The sandbox's files appear on your machine as an ordinary directory, so your harness's own editing and search tools work on them; commands go over ssh to where the toolchain is.

Do devcontainers work?

Yes, unchanged, and they run inside the VM. A profile's create hook brings one up with the ordinary devcontainer CLI, and the profile's exec prefix sends every later command through devcontainer exec. envend does not know what a devcontainer is; the profile does.

Can I use my own image?

Yes, on a backend that boots OCI images. Name node:22, postgres:17 or a 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 and nothing else about the image changes. The result is cached on the base image's digest, the platform and the layer's digest, so the second sandbox from the same image is as fast as an ordinary create. On a backend that does not boot OCI images, the image argument is refused in a sentence naming the provider — before any of that work is paid for.

What happens to my files when a sandbox sleeps?

It depends on the backend, and every sandbox tells you which it is when you create it and in every listing. There are three honest answers: the whole disk persists; /work persists and the root filesystem is rebuilt from the image on every wake; or nothing persists at all. Work in /work either way — it means the same thing everywhere, and it is what the file share serves.

How does a sandbox wake up?

The next thing that wants it wakes it: an exec, an ssh connection, a mount, or a request to a shared URL. Waking is a control action — an authenticated request to the gateway, which asks the provider to start the machine — never a side effect of traffic hitting an open port. Bytes never route through the gateway on your tunnel.

Are there secrets in the sandbox?

One key, and only one: the private half of the key it dials the gateway with, on tmpfs. Everything else is minted per use and expires — AWS role credentials, Doppler tokens, GitHub installation tokens. Nothing envend writes goes to /work, because /work is the directory the sandbox exports to whoever holds the mount.

Can two people share one sandbox?

They can both mount it — but file locks are local to each machine and invisible to the other, because the NFS version in use folds four services into four ports and only one is carried over the tunnel. For one person on their own sandbox this changes nothing. For two, it is a real gap, and closing it needs a lock manager on a port of its own.

Which providers can I use?

Fly Machines and exe.dev are connected and running. AWS EC2 is written and unit-tested against a stubbed HTTP layer and has never been run against a real account — hypothetical, and deliberately so: it exists to prove the capability vocabulary is a vocabulary rather than one vendor's habits. Adding another is twelve callbacks.

What is planned but not built?

• Snapshots. Two connectors declare the capability and nothing in the gateway acts on it yet. It is declared so the vocabulary exists before the feature does, and so somebody choosing a backend can see it.
• Per-caller identity. Authentication today is one shared bearer token, not an identity. Everyone holding it is the same caller as far as the gateway is concerned. That is enough for a small trusted group; it is not enough to say who created which sandbox.
• A lock manager for the file share, which is what two people editing one mount would need.

Why is it called envend?

en-VEND. A vending machine for computers: put in a request, take out a machine, throw the machine away.