How to SSH into a cloud sandbox

Run runtime sandbox ssh <id>; the CLI makes a key, sends only its public half and logs you in as the sandbox user.

On Runtime SSH needs no open port, no key upload and no bastion host. The login travels over one WebSocket through Runtime's API, authenticated with your key, so a sandbox opens nothing to the internet and only a key that may run commands in it can connect. You land in a Firecracker microVM with its own kernel, sudo, Python 3.12, Node.js 24 and git, and a new one ran its first command 351 ms after the request at the median on 24 September 2026 (speed).

Log in

Terminalruntime sandbox ssh <id>                  # a shellruntime sandbox ssh <id> -- make test     # one command; exits with its code

<id> is the sandbox's id or its name. Without installing the CLI, write npx withruntime sandbox ssh <id>. The first time, the CLI makes an SSH key for this machine in ~/.config/runtime-cloud/ssh and sends only its public half, into the one login it opens. You log in as runtime, the user commands run as, with the same environment, the proxy settings and passwordless sudo.

A sandbox whose image has no SSH server, such as a custom image, gets one: runtime sandbox ssh installs openssh-server once and says so first.

Plain ssh, scp and rsync

Write the SSH config entry once:

Terminalruntime sandbox ssh config --installssh web.runtimescp app.tar web.runtime:rsync -a ./src/ web.runtime:/workspace/src/

Every sandbox is then the host <id>.runtime or <name>.runtime to anything that uses OpenSSH. runtime sandbox ssh config without --install prints the entry to paste yourself; its ProxyCommand is runtime sandbox ssh proxy <id>. The entry skips host key checks on purpose: each login gets a fresh host key, and the connection already goes to the sandbox you named, through Runtime's authenticated API.

A sandbox to come back to

Give it a name and an idle pause, and the same machine is there tomorrow with its files, memory and running processes:

Terminalruntime sandbox create --name dev --get-or-create --idle-pause 900runtime sandbox ssh dev

Connecting to a paused sandbox wakes it, as any command does, so the login simply takes a moment longer.

Limits

Mistakes and how Runtime handles them

• The session drops when the lease ends. An open connection does not keep a sandbox running: when its lease pauses or stops it, the login ends. Extend the lease (runtime sandbox extend <id> 3600) for a long session, or make a paid sandbox --persistent.
• Looking for an address to ssh to. There is none, and that is the point. Use runtime sandbox ssh, or the <id>.runtime host after ssh config --install.
• A read-only key. It cannot run commands, so it cannot log in either (read-only keys).
• Starting a server from the SSH shell and logging out. Start servers that must keep running with runtime sandbox spawn <id> -- <command>; it outlives the session.
• Host key warnings from other tools. The *.runtime entry turns host key checks off for these hosts only, because every login has a new host key.

SSH or a command from code?

SSH is for a person at a terminal. An agent or a script does better with sbx.exec(...) from the SDKs or runtime sandbox exec, which return the exit code and output as data, and with runtime sandbox shell <id> for a terminal without SSH at all (the CLI).

For editors, see VS Code Remote-SSH and JetBrains Gateway. To reach a port in the sandbox from your machine, see port-forward a database.

Start

Terminalnpx withruntime sandbox run --trial --keep -- true

--keep leaves the sandbox running and prints how to run more. New accounts get 50 free sandbox hours, no card; the first run prints a link to approve in your browser.

Facts on this page were checked on 25 September 2026.