████████ ██████ ██████ ██ ██ ██ ██ ██ ██████ ████████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██████
Frequently asked questions about shellbox.dev.
Yes. Our SSH server supports the sntrup761x25519-sha512@openssh.com hybrid key exchange — a combination of the post-quantum NTRU Prime algorithm and classical X25519. OpenSSH 9.0+ clients (April 2022 onwards) negotiate this automatically. No configuration needed on your end.
We publish SSHFP DNS records secured with DNSSEC. This lets your SSH client verify our server's identity cryptographically through DNS, instead of asking you to trust on first use. Add this to your ~/.ssh/config:
Host shellbox.dev
VerifyHostKeyDNS yesThen connect normally: ssh shellbox.dev help. No fingerprint prompt.
Generate one:
$ ssh-keygen -t ed25519Press Enter to accept defaults. Then:
$ ssh shellbox.dev helpYour SSH key is your identity. No signup, no email, no password.
No. The first time you connect, your account is created automatically from your SSH key fingerprint. No registration, no email, no password required.
Your box pauses. All processes, shell history, and files are preserved in a memory snapshot. Reconnect and everything resumes exactly where you left off. Billing drops to the idle rate ($0.5/month per x1 slot) while paused.
If you want a box to keep running after disconnect (e.g. for a background job), toggle keepalive: ssh shellbox.dev keepalive <name>
Wakeup mode automatically starts your box when an HTTP request arrives at its URL, and stops it after 5 minutes of no TCP activity. This is ideal for web services that don't need to run 24/7 — you only pay while the box is handling traffic.
Enable it with: ssh shellbox.dev wakeup <name>. The first HTTP request after idle will block until the box is ready, then all subsequent requests proceed normally.
Cron mode periodically wakes your box on a schedule, sends a POST request to http://localhost:80/cron on your box, lets it run for a fixed duration, then stops it. This is ideal for scheduled tasks like data processing, backups, or report generation — you only pay while the box is running.
Enable it with: ssh shellbox.dev cron <name> <interval_min> [runtime_min]. For example, cron mybox 60 5 wakes your box every 60 minutes, runs for 5 minutes, then stops. If you SSH into a box during a cron run, it won't be stopped until you disconnect.
Yes. Add --json to most commands to get structured JSON output instead of human-formatted text:
$ ssh shellbox.dev list --json
$ ssh shellbox.dev show mybox --json
$ ssh shellbox.dev billing --jsonErrors still print as text to stderr with a non-zero exit code. Check the exit code first, then parse stdout as JSON.
For the exact schema of each command's JSON output:
$ ssh shellbox.dev help --jsonFields are only added over time, never removed or renamed. Safe to depend on any field you see today.
Yes. If you run a coding agent (Claude Code, Codex, etc.) inside a keepalive box, you can have it stop the box when the task is complete. This clears keepalive and stops billing for running time.
First, generate an SSH key inside the box and add it to your account:
$ ssh shellbox.dev keepalive mybox
$ ssh mybox@shellbox.dev
root@mybox:~# ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519
root@mybox:~# cat ~/.ssh/id_ed25519.pubCopy the public key output, then from your local machine:
$ ssh shellbox.dev key add <paste-public-key>Now the agent inside the box can authenticate as you. Start a tmux or zellij session, launch your agent, and disconnect:
root@mybox:~# tmux
root@mybox:~# claude # or your agent of choiceInstruct the agent to run this command when the task is complete:
ssh shellbox.dev stop myboxThis is the same stop command you'd run yourself. It force-stops the box, clears the keepalive flag, and pauses billing. Your work is preserved in a snapshot — reconnect anytime to pick up where the agent left off.
Alternative: You can copy your existing private key into the box instead (scp ~/.ssh/id_ed25519 mybox@shellbox.dev:/root/.ssh/), though generating a dedicated key is more secure since it can be revoked independently.
Yes. Full SFTP support means VS Code Remote SSH, Zed, and any IDE with SSH remote capabilities work out of the box. Point your IDE at <name>@shellbox.dev and you're in.
shellbox supports normal OpenSSH port forwarding. Use the same flags you'd use with any other SSH server.
Local forwarding — expose a port from your box on your local machine:
$ ssh -L 8080:localhost:80 mybox@shellbox.devThen open http://localhost:8080 on your machine to reach port 80 inside the box.
Remote forwarding — expose a local service to the box:
$ ssh -R 3000:localhost:3000 mybox@shellbox.devThat makes your local port 3000 reachable from the box at localhost:3000.
SOCKS proxy — route traffic through the box:
$ ssh -D 1080 mybox@shellbox.devConfigure your browser or tools to use localhost:1080 as a SOCKS5 proxy.
Useful quality-of-life flags: -N to skip opening a shell, and -f to send the SSH client to the background after authentication.
$ ssh -fN -L 8080:localhost:80 mybox@shellbox.devYou can also make forwards persistent in ~/.ssh/config:
Host mybox
HostName shellbox.dev
User mybox
LocalForward 8080 localhost:80Each box gets a public URL like https://dev1-a1b2c3d4.shellbox.dev with automatic TLS. HTTP requests to this URL are proxied to port 80 on your box.
Each box gets an email address like dev1-a1b2c3d4@in.shellbox.dev. Inbound mail reception is handled by Cloudflare (outside this repo/app), which forwards incoming mail as an HTTP POST request to /email on your box's HTTPS endpoint.
Standard SCP and SFTP:
$ scp file.txt dev1@shellbox.dev:/root/
$ scp dev1@shellbox.dev:/root/file.txt ./
$ sftp dev1@shellbox.devCurrent OCI support is intentionally narrow in v1. Supported images should be:
linux/amd64apt-get available so shellbox can inject SSH and guest runtime packagesA good starting point is something like docker.io/library/ubuntu:24.04, docker.io/library/debian:bookworm-slim, or any Ubuntu-derived image that still includes package manager support.
Today, minimal images from other distributions, images for other CPU architectures, private registries, and images without the expected userspace tools may fail preparation.
No. shellbox turns a Docker/OCI image into the root filesystem of a normal microVM. It does not run Docker itself inside the product workflow.
That means Docker/container runtime semantics such as CMD, ENTRYPOINT, EXPOSE, health checks, and container namespaces are not preserved as Docker behavior. You SSH into a VM and run whatever processes you want inside it.
The usual workflow is:
$ ssh shellbox.dev image prepare docker.io/library/debian:bookworm-slim
$ ssh shellbox.dev create-from-oci mybox docker.io/library/debian:bookworm-slim
$ ssh mybox@shellbox.devSeveral options, from quickest to most permanent:
SSH agent forwarding — forward your local GitHub SSH key without copying it into the box:
$ ssh -A mybox@shellbox.dev
root@mybox:~# git clone git@github.com:user/repo.gitAdd ForwardAgent yes to your ~/.ssh/config under Host shellbox.dev to make it permanent. Your private key never leaves your machine.
HTTPS with a personal access token — no SSH keys needed:
root@mybox:~# git clone https://github.com/user/repo.git
Username: your-username
Password: ghp_xxxxxxxxxxxx # paste a personal access tokenGenerate a token at github.com/settings/tokens. To avoid re-entering it: git config --global credential.helper store
GitHub CLI — interactive login with device code flow:
root@mybox:~# apt install -y gh
root@mybox:~# gh auth loginGenerate a key on the box — for a dedicated deploy key:
root@mybox:~# ssh-keygen -t ed25519
root@mybox:~# cat ~/.ssh/id_ed25519.pubAdd the public key to your GitHub account (github.com/settings/keys) or as a deploy key on a specific repo.
Base box (x1): 2 vCPUs, 4GB RAM, 50GB SSD. Sizes scale up to x8 (16 vCPUs, 32GB RAM, 400GB SSD). Billing scales proportionally. Per account: up to 16 running slots and 64 total slots, where each box counts as its size in slots (e.g., an x4 box uses 4 slots). Network bandwidth is shared and may be throttled if it affects other users.
Box sizes are multipliers from x1 to x8 that scale vCPU, RAM, disk, and billing rates. Create a sized box with ssh shellbox.dev create mybox x2. Size is set at creation and cannot be changed — delete and recreate to resize. Duplicated boxes inherit the source box's size.
$ ssh shellbox.dev rename mybox newnameThis updates the box name instantly. The box's URL and email address will change to reflect the new name. The box can be running or stopped — renaming is safe during active SSH sessions.
No. We do not perform backups. You are responsible for your data. Use scp or sftp to back up important files. You can also duplicate a stopped box as a point-in-time copy: ssh shellbox.dev duplicate <name> <backup>
Currently in Europe (Helsinki, Finland). A US region is planned — if that matters to you, upvote or comment on the tracking issue.
Yes, two ways. You can copy your private key to your other devices, or — better — link additional SSH keys to your account: ssh shellbox.dev key add "<pubkey>". Each linked key gets full access to your boxes. Run ssh shellbox.dev key list to manage your keys.
Yes — in stock boxes. Stock boxes ship with Ubuntu 24.04 LTS and Docker pre-installed. No setup needed:
$ ssh mybox@shellbox.dev
root@mybox:~# docker run hello-worldYou can pull images, build containers, and run docker compose like you would on any Linux server.
OCI image-backed boxes (created with create-from-oci) do not include Docker. They use whatever software the source image provides. You can install Docker yourself if the image supports it.
Yes. Create your box with --ch to use Cloud Hypervisor, which passes through the host CPU virtualization capabilities. /dev/kvm is available inside the box, so you can run KVM-based workloads — including Firecracker, QEMU, or other hypervisors — inside your box.
$ ssh shellbox.dev create mybox --chNested virtualization requires the host to have it enabled (Intel VMX nested or AMD SVM npt). All current shellbox hosts support this.
The default backend (Firecracker) does not support nested virtualization but has faster snapshots. Use --ch when you need /dev/kvm inside the box.
It works fine. If you run shutdown -h now (or poweroff, halt, etc.) inside the box, the SSH connection will close and the box will stop — just like a normal disconnect. When you reconnect, the box boots fresh from disk with all your files intact. The only difference from a normal disconnect is that the in-memory snapshot is discarded (since the guest OS was halted), so running processes won't be preserved — but everything on disk is safe.
Note: If your box has keepalive (or wakeup/cron) enabled, shutting down from inside will not stop the box from Shellbox's perspective. The box will still show as "running" and bill at the running rate, since Shellbox honors the keepalive flag on disconnect. Use ssh shellbox.dev stop <name> to actually stop a keepalive box — see Can a coding agent stop my box when it's done? for how to do this from inside the box by copying your SSH key in.