Design an Online Development Box

Design an online development box: a remote workspace where a developer can edit files, run development tools, and reconnect to the same project from a client.

Constraints & Assumptions

• The source names an online devbox system-design task without supplying a detailed product specification.
• Practice scope: authenticated users create workspaces from an approved environment image and project source, connect through a browser or compatible editor, run terminal commands, stop the workspace, and resume later with project files preserved.
• Treat code executed inside a workspace as untrusted relative to other users and the platform's control plane.
• No concurrent-user count, startup target, hardware profile, availability target, or geographic requirement is supplied. Identify how these would influence the design instead of inventing numeric targets.
• Collaboration by multiple simultaneous editors, specialized hardware, and arbitrary public service hosting are optional extensions rather than core requirements.

Clarifying Questions to Ask

• Which files and installed tools must persist across a stop, restart, or machine failure?
• Does a workspace need root-like privileges, custom containers, outbound network access, or credentials for private repositories?
• What does stopping mean for running processes, unsaved editor buffers, and active connections?
• Are fast cold starts more important than minimizing idle compute cost?
• Must reconnecting clients reach the same running process, or is restoring files into a fresh runtime sufficient?

Part 1 — Create and Connect to a Workspace

Describe the control plane, runtime placement, connection routing, and workspace records. Walk through creation from an image and project source to an authenticated editor or terminal connection.

What This Part Should Cover

• Workspace identity, desired state, owner authorization, and runtime identity.
• An asynchronous provisioning lifecycle with idempotent retries.
• Routing a connection to the current authorized runtime without exposing platform credentials.

Part 2 — Isolate Execution and Preserve Work

Explain tenant isolation, resource and network controls, secret delivery, persistent project storage, and recovery after runtime failure.

What This Part Should Cover

• A trust boundary suitable for untrusted development code.
• Separation of persistent project files from disposable runtime state.
• The difference between durable file recovery and resuming arbitrary process memory.

Part 3 — Stop, Resume, and Operate Efficiently

Explain idle stopping, image or environment changes, node failures, and the trade-off between startup speed and idle cost.

What This Part Should Cover

• Lifecycle transitions that do not allow an old runtime and a replacement to corrupt one workspace.
• Warm capacity or prebuilt environments without cross-user data leakage.
• Observability for provisioning failures, connection failures, storage problems, and resource abuse.