Shed as a sandbox
Some machines are worth keeping and some exist for an afternoon. A sandbox is the second kind: made for one job, used hard, and deleted. It is a whole virtual machine while it lasts, so whatever runs in it runs properly.
One machine per job
Make a machine for the task, work in it, read the result at its address, and throw it away. Nothing it installs, breaks or leaves behind touches anything else you run.
Root and a real filesystem are the point. A sandbox that cannot install a dependency is a chat window with extra steps, and an agent working in one will spend its turns explaining why it could not finish.
Fork what it needs to touch
When the job has to change something that already exists, fork that machine first. The copy has the same data and the same software at its own address, and the original is never at risk.
A fork takes about a second, so one per attempt is reasonable. Failed attempts get deleted rather than undone.
Gone when it is done
An ephemeral machine keeps nothing. It starts when it is needed and leaves no disk behind, which is the right shape for work that is finished once it is finished.
Past your plan, machines are billed by the hour, so a hundred short-lived sandboxes cost the hours they ran rather than a month each.
Machines you would make
agent-4f2c: where one coding agent worksapp-try-3: a fork of app, for a third attemptscratch: a throwaway, gone when it is done
Join the waitlist
Shed is not open yet. The other two use cases are vps and production.