How to build a persistent computer for coding agents
A practical guide to remote computers for coding agents: sizing a VM, setting up SSH and tmux, and understanding what survives disconnects, restarts, and sleep.
How to build a persistent computer for coding agents
You launch an agent on your laptop with everything ready to go: the repository, dependencies, credentials, and terminal. Then the laptop goes to sleep, the connection drops, or you switch to another computer. What should still be there when you return?
At first, this might seem like one feature: persistence. In practice, it involves several parts. Files can stay on disk after every process has stopped. A terminal session might survive an SSH disconnect, while the agent conversation inside it is lost after a restart. A VM can stop and start again with its disk intact, but anything held only in memory is gone. Some agents have their own way to save and resume conversations, separate from the terminal around them.
A remote computer for coding agents is a set of these pieces working together. Here is what you have to assemble, what each piece does, and where its promise ends.
First decide what kind of work should persist
There are two common jobs that get described with the same phrase, “run an agent in the cloud.”
One is a remote development computer. It holds a project and a toolchain you use over time. You might leave an agent working in a terminal, close your laptop, then return from a different device. The machine is your development environment, with an agent running on it.
The other is a disposable task environment. It is created for a job, runs an agent against a repository, and returns a branch, patch, or other result. Once the result is saved, the environment can be thrown away. It does not need to preserve a personal terminal or the same installed tools between unrelated tasks.
No single setup works for every job. A long Android build, an agent you want to check from your phone, and a one-off code review have different requirements. Start by writing down which work should continue after you leave, and which work should start clean each time.
Build the remote computer one layer at a time
1. Size the machine for the project
“Run a coding agent” is not a useful machine specification. The model may run remotely, while the computer still has to check out the repository, run the agent’s tools, install dependencies, compile code, and run tests.
Start with the actual workload. A small script and a TypeScript service have different needs from an Android build with an emulator. Several agents compiling separate projects at once need more memory, CPU, and disk than one agent editing a small codebase. CPU architecture matters too: a tool that supports Linux may not publish a compatible binary or container image for every architecture.
The official requirements give useful examples, not a universal answer. Anthropic lists 4 GB or more of RAM for Claude Code. Android Studio lists 8 GB minimum for Studio alone and 16 GB for Studio with the emulator, with 32 GB or more recommended. It also estimates roughly 4 GB of RAM for each running Android Virtual Device. The project and the emulator can require far more resources than the agent itself. (Claude Code setup, Android Studio system requirements)
For a real sizing decision, run the build you care about. Record the repository, command, CPU and memory, whether the build cache is warm, and how long it takes. A VM size is a promise about a workload only when someone has tested that workload on it.
When do you need to make this choice? Always. If you manage the VM, choose the size directly. If a service chooses it for you, check the published resources and test whether the work fits.
2. Install the operating system, agent, and project tools
The remote host needs an operating system the agent supports. Then you install the coding agent, authenticate it with the provider or account you use, and check that it can run from the remote shell. A browser login that works on your laptop may need a separate setup path on a headless server.
After that comes the project’s toolchain: language runtime, compiler, SDK, package manager, system libraries, databases, and any container tooling. A project that needs the Android SDK needs those components even if its coding agent is already installed. The list changes when the project changes.
This is why a remote computer is convenient, but not maintenance-free. You need a repeatable setup for a second machine or a rebuild. A bootstrap script or a machine template can record packages, shell configuration, and install steps. Keep credentials out of that source repository; store them in an appropriate secrets manager or account mechanism.
The experience report I Moved Development to a Remote VM. Coding Agents Made Me Stay gives a concrete example of the setup being replaced. Its author worked across PHP, Node, Bun, Python, Docker, databases, and CLI tools, then moved that environment to one VM. The article describes a bootstrap repository for packages and dotfiles, secrets stored separately, and daily VM backups. Those are the author's choices, but they show what “my environment is on the server” includes beyond cloning a repository.
When do you need to install project tools? Every time the project requires tools that the base machine does not include. A general computer can be ready; it cannot know which compiler, SDK, database, or project-specific dependency you need until you choose them.
3. Give the laptop a secure way in
SSH gives you a remote shell. In the simplest setup, you create a Linux VM, make an account, install or enable an SSH server, set up authentication, and connect from your laptop. You also need to decide whether SSH is reachable from the public internet or only from a private network. (OpenSSH manual)
Tailscale is one optional way to put the laptop and server on a private network. You install its client on both devices and enroll them in the same tailnet. If you use Tailscale SSH, the destination must enable it and the tailnet policy must allow the connection. The network rule and the SSH rule are separate checks. (Tailscale Linux installation, Tailscale SSH)
This setup takes real work. You need to install and authenticate the clients, enroll devices, set access policies, check connectivity, and make sure the host account has only the permissions it needs. Network access answers “can this device reach the host?” Host permissions answer “what can this user or agent do after login?” They are related but separate decisions.
The LogCTL account describes a simple version of this workflow on a new laptop: install the operating system, install and authenticate Tailscale, SSH into the development VM, and start working. The author reports that returning to an already prepared development machine took around ten minutes, much of which was remembering an unfamiliar Windows interface. That is one person's experience, not a setup-time guarantee. (LogCTL's remote VM setup)
Do you need Tailscale? No. You need a secure way to reach the host. Tailscale is useful if you want private device-to-device networking and identity-based access rules; SSH can also be configured without it.
4. Keep the agent alive when the client disconnects
An SSH connection is not a persistent workspace. If an agent runs in a foreground shell tied to that connection, the shell may end when the connection goes away. To detach and reconnect, the session must live on the server, separate from the laptop's terminal window.
A common setup uses tmux. SSH to the VM, start a named session, and launch the agent inside it:
ssh developer@devbox
cd ~/projects/my-app
tmux new -s my-app
claude
Press Ctrl-b, then d, to detach while leaving the session on the remote machine. Later, SSH back in and run tmux attach -t my-app. The tmux documentation says that detached sessions and their programs can be reattached from the same or another terminal. This works because the tmux server and agent process run on the remote host; the laptop is only the client. (tmux Getting Started)
Herdr is another session manager with a client and a background server. Its docs say that panes and agents keep running when the client detaches; the remote attach mode keeps the panes on the remote host and sends terminal state to the local UI. That means installing a compatible session server on the VM as well as setting up SSH. (Herdr persistence and remote access)
The account in the LogCTL article describes keeping one tmux session per project. The author starts Claude in a session, detaches, closes the laptop, then later reconnects over SSH and attaches to the same session. This is the simplest version of the value proposition: the project’s working state is on the remote machine, so the device in front of you can change. (LogCTL's session workflow)
When do you need a session manager? When a task must keep running after the terminal client disconnects. If your only requirement is to keep the files and installed tools for a later session, a session manager may not be necessary.
5. Decide what should happen after the session server or VM restarts
Detaching from a session and restarting its server are different events. A detached agent process can keep running as long as the host and session server stay alive. If the session server stops, its pane processes can stop with it.
Some tools save enough metadata to recreate the terminal layout after restart. That is useful, but it does not bring back the old process from memory. Herdr documents the distinction: after a full server stop, it can restore the saved session shape, while pane processes are stopped; scrollback replay and an agent's native resume support have their own rules. The word “restore” can therefore mean “reopen the same panes,” “replay old output,” or “continue the agent conversation.” Those are different outcomes. (Herdr session state and restore)
A VM reboot is another boundary. The filesystem may still contain the repository and installed tools, but processes that existed only in memory end. If a web server or agent gateway should start at boot, configure and enable a systemd service. Its Restart= policy can start a new process after certain failures; enabling the service controls whether it starts with the machine. Neither setting reconstructs the old process's RAM or automatically resumes an interactive agent conversation. (systemd service behavior, systemd unit behavior)
For an interactive coding agent, restarting the process may require using that agent's own conversation restore feature. That depends on the agent and how it stores session identifiers and conversation state. A terminal multiplexer cannot invent that state if the agent did not save it.
6. Choose a disk and backup policy
“The VM is persistent” often means that files on its disk stay there. It does not necessarily mean that every kind of data stays through every operation.
Cloud providers distinguish the VM's disk from temporary instance storage, and stop, hibernate, reboot, snapshot, and delete can all have different effects. AWS, for example, documents that stopping and starting an EC2 instance preserves EBS volumes but loses instance-store data; hibernation separately saves RAM to the root EBS volume; termination can delete the root volume depending on its DeleteOnTermination setting. Those are AWS-specific mechanics, but they illustrate why the provider's lifecycle documentation matters. (EC2 instance lifecycle)
A backup is separate from durable storage. A disk can be persistent and still be lost through deletion, corruption, a bad script, or a mistake. AWS recommends regular EBS snapshots or an automatic backup policy; operators also need to know how to restore them. (Amazon EBS snapshots)
For development work, keep the project history in Git and make the machine reproducible. Back up machine-only state that would be painful to rebuild, and test a restore before you need one. A disk snapshot captures disk state; it does not normally include a running VM's memory or preserve a process in flight. Hibernation is a distinct feature when a provider supports it. The LogCTL author describes using GitHub for project history, a private repository for machine setup, a password manager for secrets, and daily VM backups for current working state. That layered approach reduces the chance that “persistent” turns into “one machine nobody knows how to replace.” (Amazon EBS snapshots, LogCTL on reproducibility and backups)
7. Plan updates, credentials, and isolation
An always-available machine needs an owner. Someone must apply operating-system and agent updates, check disk space, review logs, rotate credentials, and decide who can log in. Automatic updates can also restart services, so decide whether a reboot can interrupt ongoing work and whether important processes should come back automatically.
The security question changes if the host runs code from people or repositories you do not fully trust. A personal development VM is often configured for convenience and may hold tokens, SSH keys, caches, and private source. A CI runner executes repository-defined jobs and can run arbitrary code. GitLab warns that non-ephemeral self-managed runners shared across projects can expose the host, other projects' code, and secrets. GitHub's self-hosted runner guidance recommends ephemeral runners for autoscaling setups. Those warnings apply to CI and untrusted jobs; they do not mean every personal development computer must be disposable. (GitLab Runner security, GitHub self-hosted runners)
Code with Dan's VPS account shows what this operational layer looks like when one machine grows into a broader agent server. The author reports a 16 shared-vCPU ARM64 VPS, 32 GB advertised RAM, 320 GB advertised storage, and Ubuntu 24.04. It hosts several agents, bots, databases, containers, and web apps. Keeping a gateway alive after SSH disconnect meant installing a systemd service, fixing service-user permissions, and testing that it survived restarts. He also calls out the lack of a GPU and ARM compatibility as constraints. Those numbers describe his setup, not the machine every agent needs. (Code with Dan's VPS build)
What each kind of persistence means
“Sleep” can mean that the laptop goes to sleep, the guest OS suspends, the cloud provider hibernates the VM, or the provider stops it to release compute. These are different operations. Ask which one a service means, and check the provider's behavior before treating it as a promise.
Use these tables as a checklist. They describe common behavior, with named product examples where useful. Your provider and session manager may differ.
| Event | Files and tools | Running process | URL and access |
|---|---|---|---|
| Close a browser tab | Usually unchanged if the remote machine remains on | Can keep running on the remote host | The address can still work if the machine and service remain available. GitHub Codespaces says closing its browser tab does not stop the codespace. |
| Laptop sleeps | Remote files are unaffected | A process on an independent remote host can continue | The service can remain reachable to other clients; the sleeping laptop cannot use it until it wakes. |
| Disconnect SSH | Unchanged | A foreground command may be interrupted; a detached process can continue | Host address is unaffected. Login still depends on network and account policy. |
| Detach from tmux or Herdr | Unchanged | Continues while the remote session server stays alive | The application's address is independent of the terminal client, though its service process must keep running. |
| Stop the session server | Unchanged on disk | Pane processes may stop | The host address may remain, but an application process inside a stopped pane will not answer. |
| Reboot the guest OS | Disk contents remain when stored on durable VM storage | Processes in RAM end; enabled services can start as new processes | The name may remain configured, but the application can be unavailable until the host and service start. Check address and boot behavior. |
| Suspend or hibernate the VM | Depends on the mechanism | A true suspend may retain RAM; hibernation saves and restores memory when supported. Do not assume a product's “sleep” means either. | The address may resolve while the machine cannot answer. Wake behavior and address retention are provider-specific. |
| Stop and start a cloud VM | Provider-specific; durable volumes may remain while temporary storage is lost | RAM and live processes do not continue through an ordinary stop/start | Public or assigned IP behavior varies. Confirm whether the name still points to the machine after it starts. |
| Snapshot and restore | The snapshot captures disk state from its creation point | A disk snapshot does not preserve live processes in RAM unless the provider offers a separate memory/checkpoint feature | The restored VM may need a new address or DNS update. A snapshot does not by itself prove the old URL is still routed to it. |
| Fork a machine | Depends on whether the fork copies or shares the filesystem | A fork should not be assumed to copy a live process | Name, URL, and sharing rules depend on the product. Shed's definition says a fork copies the running machine's filesystem intact; it does not specify process or address behavior. |
| Delete the VM | Disk removal or retention depends on provider policy and backups | Processes end | The address may be removed or released. Recovery needs retained data and a restore path. |
Terminal state and agent conversation need a separate check:
| Event | Terminal layout and contents | Agent conversation |
|---|---|---|
| Close a browser tab | The web UI disappears. A remote session may remain available when the page is reopened. | Continues only if the agent process continues on the host. |
| Laptop sleeps | The local display and connection are unavailable until wake. | Continues if the agent runs independently on the remote host. |
| Disconnect SSH | The local terminal disappears. A remote multiplexer can preserve its live panes for reattachment. | Continues only if the agent process is detached or otherwise survives the disconnect. |
| Detach from tmux or Herdr | The live panes and their current output remain available in the session. | The live conversation continues inside the still-running agent process. |
| Stop the session server | Some tools can save and restore a pane layout; live pane processes stop. Visible screen contents or scrollback may or may not be replayed. | The agent may support native resume, but the session manager cannot recreate unsaved conversation state. |
| Reboot the guest OS | The former live terminal process is gone. A tool may recreate a layout after boot. | Resume depends on the agent's own saved conversation data and restart support. |
| Suspend or hibernate the VM | The terminal may resume if the provider preserves guest memory; hibernation support and restore behavior vary. | The live process may resume from saved memory if the provider supports it; otherwise use agent-native recovery. |
| Stop/start the VM | The former live terminal process is gone after an ordinary stop/start. Session layout may be rebuilt after boot. | Resume depends on the agent's saved conversation data and restart support. |
| Snapshot and restore | Disk-backed configuration may be restored; live terminal buffers are not part of an ordinary disk snapshot. | Conversation files may be present on disk, but a live session is not restored from a disk snapshot. |
| Fork the machine | The product may copy or share disk files; terminal layout and live output are not necessarily copied. | Do not assume a fork includes the live agent process or a resumable conversation. |
| Delete the machine | Terminal processes and live output are gone. Recovery depends on retained backups. | The live conversation ends; recovery depends on saved conversation data and backups. |
GitHub Codespaces is a useful example of a product that documents these boundaries directly. Closing its browser tab does not stop the remote codespace. Stopping it does stop running processes, but saved file changes remain; terminal history is preserved while the visible terminal contents are not. A stopped codespace still incurs storage charges, and deletion is a separate action. Those are Codespaces rules, not general cloud rules, but the distinctions are useful questions to ask any provider. (GitHub Codespaces lifecycle)
The URL is another piece of state. A domain can keep pointing at a machine while the machine sleeps, and a healthy machine can answer on SSH while the web process is stopped. Ask whether the address is stable through a reboot, stop/start, fork, and restore, and what a request gets while the machine is asleep.
The questions to ask about any remote coding environment are therefore specific:
- Do files and installed tools survive a stop and restart?
- Does closing the browser or SSH client stop the machine or only the connection?
- Which processes keep running after a client disconnect?
- What returns after a session server restart or VM reboot?
- Does the agent have a way to resume its own conversation?
- Does the machine's URL stay assigned through sleep, reboot, fork, and restore, and does it wake the machine?
- What does delete remove, and what can a backup restore?
What people actually build
The public examples point to three related but different uses for a remote machine.
The first is a development environment you can reach from any device. The LogCTL author started with a familiar frustration: rebuilding the same language runtimes, databases, editor tools, and shell setup on every computer. A remote VM changed the laptop into a client. The agent made that setup more useful because its process and the project's working state could remain on the VM between visits.
The second is an always-on personal server for agents and services. Code with Dan describes a VPS that runs several agent runtimes alongside bots, databases, containers, and web apps. That kind of machine offers more freedom than a narrow per-task environment, but it creates a larger maintenance and permissions surface. The article's systemd work is a good reminder: “reachable over SSH” does not mean a service is supervised, starts after boot, or has the right permissions.
The third is a managed way to work on a remote host. Superset's comparison guide lays out options such as VS Code Remote SSH, SSH plus tmux, managed cloud agents, and its own host service. It is a vendor-authored guide, but the choice it describes is real: use your own machine and assemble the layers, use an environment tied to a repository or task, or use a client that manages access to a host for you. Its central distinction is also useful: remote control of an agent on your sleeping laptop does not make that agent independent of the laptop. (Superset remote-agent guide)
These setups are not interchangeable. The right one depends on whether you want an environment to persist across projects, a clean computer per task, or a long-running host with services and several agents. The word “persistent” alone does not answer that.
Which setup fits?
- Stay local if you work from one computer, can leave it running when needed, and do not need to reach the same environment from another device.
- Use a remote VM or VPS if you want one Linux development computer for many projects and are willing to configure access, toolchains, updates, backups, and recovery.
- Use a disposable task environment if each job can start clean and hand back a branch, patch, or artifact. You trade a continuing personal workspace for isolation and repeatability.
- Use a managed computer service if you want a machine created with access and an agent already in place. Check what project setup, credentials, lifecycle behavior, and recovery still require your attention.
The choice is about what you want to own: a laptop environment, a server, a fresh machine for each task, or a computer whose setup is handled for you.
What Shed gives you out of the box
Shed starts with a virtual machine. The machine arrives with a domain, HTTPS, SSH, and a coding agent already running inside it. The intended product is a computer for the agent and the person working with it, rather than a repository-specific environment that has to be assembled before a machine exists.
See the Shed computer model and the Shed page for coding agents for the product overview.
The product is designed to let you build a machine from a prompt, save a machine as a template, fork a running machine with its filesystem intact, and group multiple machines so they can be addressed and operated together. Those are machine operations: create, reuse, copy, and organize computers. They are different from keeping one terminal pane alive after a client disconnects.
Machines are private. You share one by naming a person, who signs in as themselves; the URL alone does not grant access. Shed describes pricing as one flat-priced pool of machines, metered by CPU time, with idle machines costing nothing. That statement is about billing. It does not, by itself, say whether an idle machine sleeps, whether a running process survives a restart, or what state returns after waking.
The domain and HTTPS address are part of the machine's setup, but an address and a live application are separate things. Before relying on any remote computer, check whether its address remains assigned through sleep, reboot, fork, and restore, and whether a request wakes a sleeping machine.
You still choose the project-specific dependencies and toolchain, and connect the coding agent to the provider or account you use. Shed's machine-level operations cover creating, reusing, copying, and organizing computers. For any remote computer, including one from Shed, you should also understand how its address behaves through sleep, reboot, fork, and restore; what happens to agent and terminal state after a reboot; and what backup and deletion policies apply. “Persistent” is not a promise that every kind of state survives every event.
The useful comparison is the work each side owns. With a self-managed VPS, you choose the machine, install and authenticate the agent, configure access, set up session recovery, and operate updates and backups. Shed's defined offer starts with the VM, its address, SSH, the coding agent, private sharing, and machine-level operations. The project toolchain and the lifecycle details still need their own clear answers.
That is the computer an agent can use. The next question is not whether it is persistent in the abstract. It is which parts of its state survive each event, and what Shed does when that event happens.