> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensorlake.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Use a sandbox as your dev environment
> Get a portable cloud development workstation — SSH in from any machine, idle-suspend when you're not using it, resume by name with state intact.
A Tensorlake sandbox is not only an execution surface for agents — it is also a real development environment you can SSH into from any machine. Open it in VS Code or any Remote-SSH client, work normally, walk away when you're done. The sandbox idle-suspends on its own and stops charging. Resume tomorrow under the same name and your shell history, installed packages, in-progress branches, running `tmux` sessions, and `~/.vscode-server` are exactly where you left them.
Compared to a long-running VM or a traditional cloud-dev product:
* **Portable identity, not portable hardware.** You connect to the same sandbox id from any machine. Which region or host the underlying VM lives on is the platform's problem.
* **Suspend-on-idle, not always-on.** Named sandboxes auto-suspend after `timeout_secs` of no proxy traffic, so you only pay while you are actively connected.
* **Resume preserves state.** Filesystem, memory, and running processes all survive suspend. The sandbox id never changes, so your `~/.ssh/config` entry keeps working forever.
## Prerequisites
* The [`tl` CLI](/sandboxes/introduction) installed and logged in (`tl login`).
* An ed25519 (or RSA) SSH keypair on your laptop. Generate one with `ssh-keygen -t ed25519` if you don't have one.
## One-time setup: register your SSH key
```bash theme={null}
tl sbx ssh keys add --name laptop ~/.ssh/id_ed25519.pub
tl sbx ssh keys ls
```
The key is associated with your Tensorlake user across every project — you only do this once per laptop. See [SSH and PTY Sessions](/sandboxes/pty-sessions#one-time-setup) for the `TENSORLAKE_API_KEY` gotcha and other auth details.
## Create your sandbox
Create a **named** sandbox so it can be suspended and resumed:
```bash theme={null}
tl sbx create my-dev --cpus 2 --memory 4096 --disk_mb 25600
```
Pick CPUs, memory, and disk that fit your workload — language servers, builds, and test runs are usually the limiter on CPU/memory, while toolchains, container images, and dataset checkouts are what fill the disk. `--disk_mb` is the root filesystem size in MiB; the allowed range is 10240–102400 (10–100 GiB). The name (`my-dev`) is how you'll refer to the sandbox in `tl sbx suspend/resume` commands.
Grab the SSH config block:
```bash theme={null}
tl sbx describe my-dev
```
Copy the `SSH Config:` block into `~/.ssh/config`. The sandbox id inside that block is stable across suspend/resume, so you only need to do this once.
Already have a project image with your toolchain pre-installed (Node, Python, CUDA, your repo's `apt` deps)? Pass `--image my-image` so every new sandbox starts pre-configured. See [Sandbox Images](/sandboxes/images).
### Pick a timeout
Named sandboxes idle-suspend after `timeout_secs` of no proxy traffic — default `600` seconds (10 minutes). While you are SSH'd in, that clock is paused, so 10 minutes is usually fine. If you want a longer idle window before suspend — e.g. so a brief network blip doesn't suspend the sandbox out from under you — bump it:
```bash theme={null}
tl sbx create my-dev --cpus 2 --memory 4096 --disk_mb 25600 --timeout 3600
```
`--timeout 0` requests the plan maximum (24 hours on On-Demand). See [Timeout](/sandboxes/lifecycle#timeout) for precise semantics and plan limits.
## Add an SSH config entry
`tl sbx describe my-dev` prints an `SSH Config:` block you can paste directly into `~/.ssh/config`.
You can also write the equivalent entry manually:
```sshconfig theme={null}
Host my-dev
HostName sandbox.tensorlake.ai
User
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
ServerAliveInterval 30
ServerAliveCountMax 3
```
The `Host` alias (`my-dev`) is just a local label — pick whatever you like. The `User` must be the sandbox id; this is what the gateway routes on.
`ServerAliveInterval` keeps the connection healthy across short network gaps. `IdentitiesOnly yes` makes sure your client only offers the registered key (important if you have several keys in your agent).
Test it:
```bash theme={null}
ssh my-dev
# tl-user@tl-sbx:~$
```
## Open it in VS Code
1. Install the **Remote - SSH** extension (`ms-vscode-remote.remote-ssh`).
2. Run **Remote-SSH: Connect to Host…** and pick `my-dev`.
3. **File → Open Folder** → `/home/tl-user/workspace`. That path is writable by the default `tl-user` account and persisted across snapshots; `/workspace` is not `tl-user`-writable in the default image, and `/tmp/*` is writable but excluded from snapshots.
4. First connect takes \~30 seconds while VS Code installs its server inside the sandbox under `~/.vscode-server`. That directory lives under `/home/tl-user`, so it persists across suspend/resume — subsequent connects are much faster.
JetBrains Gateway, Cursor, and any other Remote-SSH client work the same way.
## Day to day
Work normally — `git clone`, install deps, run your stack. Two things to keep in mind:
* **Long-running jobs vs. SSH disconnect.** When your SSH session ends and no other proxy traffic is in flight, the idle clock starts and the sandbox eventually suspends. Suspend preserves running processes, so a `tmux` job resumes when you do — but it does *not* make progress while the sandbox is suspended. For unattended work that needs to keep running, raise `--timeout`, keep a client connected, or use [background processes](/sandboxes/commands) (which are designed for fire-and-forget work).
* **Suspend explicitly when you're done.** `tl sbx suspend my-dev` stops the meter immediately, rather than waiting for the idle timeout to fire.
Resume tomorrow:
```bash theme={null}
tl sbx resume my-dev
ssh my-dev
```
The sandbox id never changes across suspend/resume, so your `~/.ssh/config` entry and any VS Code Remote-SSH bookmark keep working — there is nothing to update on your laptop, even after weeks of suspend.
## Next steps
Port forwarding, `scp`/`rsync`, PTY API, and troubleshooting.
Suspend, resume, timeout semantics, and snapshots.
Bake pre-installed dependencies and tools into a reusable image.
Outbound access controls, exposed ports, and tunnels.