CONCEPT Cited by 1 source
Remote development environment¶
Definition¶
A remote development environment is an architectural setup where the developer's editor UI runs on one machine (typically a laptop) but code execution, language services, file operations, and terminals run on a different machine (a remote host — VM, container, cluster node, or micro-VM). The two halves are connected by a transport (most commonly SSH, sometimes custom tunnels or WebSockets over HTTPS).
The remote side may be chosen for any of:
- Access to hardware the laptop lacks (GPUs, large RAM, specific architectures)
- Reproducibility (clean-slate sandbox per project)
- Blast-radius containment (keep risky operations off the dev laptop — see concepts/agentic-development-loop)
- Network locality to a dataset or a service
- Consistency across a team (shared dev-environment image)
Two architectural answers¶
The same user-visible feature — "edit files on a remote box from the editor on my laptop" — admits two architectural answers that differ by orders of magnitude in blast radius and deployment complexity. This is the load-bearing wiki axis, established by Fly.io's 2025-02-07 critique of VSCode Remote (Source: sources/2025-02-07-flyio-vscodes-ssh-agent-is-bananas):
| Axis | Agent-deployment (e.g. VSCode Remote) | Live-off-the-land (e.g. Emacs Tramp) |
|---|---|---|
| Runtime shipped to remote | Yes — full language runtime (Node.js) + agent | No — uses existing shell + utilities |
| Persistence on remote | Persistent agent across reconnects | None — stateless |
| Transport | RPC (e.g. WebSocket) over SSH port-forward | Interactive Bourne shell over SSH |
| Capability surface | FS + PTY + RPC + self-persistence | Whatever the shell can do |
| Compromise blast radius | Persistent — process survives reconnect | Session-scoped — dies with the shell |
| Deployment step | Bash stager + download + unpack + launch | None |
Canonical instances on the wiki:
- Agent-deployment: VSCode Remote-SSH.
- Live-off-the-land: Emacs Tramp.
Motivating 2025-era use case: the agentic loop¶
In 2025 the dominant new reason to want a remote-development-environment is not convenience for humans but running LLM-driven coding agents on a sandbox. Fly.io's framing:
"A thing you'd really like to be able to do: run a closed-loop agent-y ('agentic'? is that what we say now) configuration for an LLM, on a clean-slate Linux instance that spins up instantly and that can't screw you over in any way." (Source: sources/2025-02-07-flyio-vscodes-ssh-agent-is-bananas)
This is the agentic development loop in disguise — LLM generates code → execution scaffolding runs it → errors feed back → LLM iterates. The architectural requirement is that the execution environment be disposable, fast-booting, and bounded in blast radius, which is the architectural brief for Fly Machines (and for the broader disposable-VM-for-agentic-loop pattern).
Seen in¶
- sources/2025-02-07-flyio-vscodes-ssh-agent-is-bananas — introduces the architectural axis (agent-deployment vs live-off-the-land), names the 2025 motivating use-case (agentic LLM loop on a disposable sandbox), and uses VSCode Remote-SSH + Emacs Tramp as the two anchor instances.
Related¶
- systems/vscode-remote-ssh — canonical agent-deployment instance.
- systems/emacs-tramp — canonical live-off-the-land instance.
- systems/openssh — the transport both models most commonly ride.
- concepts/live-off-the-land — the opposite architectural posture.
- concepts/agentic-development-loop — 2025-era motivating use-case.
- patterns/stager-downloads-agent-for-remote-control — the agent-deployment architectural pattern.
- patterns/disposable-vm-for-agentic-loop — the sandboxing answer.