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 yes

Then connect normally: ssh shellbox.dev help. No fingerprint prompt.

Use an SSH host alias and OpenSSH connection multiplexing. The alias makes commands shorter, and multiplexing reuses an existing SSH transport so repeated commands skip most of the TCP/SSH handshake.

Host sb
    HostName shellbox.dev
    VerifyHostKeyDNS yes
    ControlMaster auto
    ControlPersist 10m
    ControlPath ~/.ssh/shellbox-%C

Then you can write shorter commands:

$ ssh sb list
$ ssh sb create vm1
$ ssh vm1@sb

Multiplexing is per SSH user/host/port, so ssh sb list, ssh vm1@sb, and ssh vm2@sb each use their own control connection. If you use pooling for box logins and want to tear down the master immediately, run ssh -O exit vm1@sb. To stop the box immediately, run ssh sb stop vm1.

Generate one:

$ ssh-keygen -t ed25519

Press Enter to accept defaults. Then:

$ ssh shellbox.dev help

Your 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 enters a grace-stop window. By default, after the last SSH session disconnects, Shellbox waits 120 seconds before pausing the box. If you reconnect during that window, the box keeps running and you avoid an unnecessary stop/start cycle.

After the grace period, the 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 to stop immediately instead of waiting for the grace period, run: ssh shellbox.dev stop <name>

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 --json

Errors 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 --json

Fields 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.pub

Copy 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 choice

Instruct the agent to run this command when the task is complete:

ssh shellbox.dev stop mybox

This 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.dev

Then 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.dev

That makes your local port 3000 reachable from the box at localhost:3000.

SOCKS proxy — route traffic through the box:

$ ssh -D 1080 mybox@shellbox.dev

Configure 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.dev

You can also make forwards persistent in ~/.ssh/config:

Host mybox
    HostName shellbox.dev
    User mybox
    LocalForward 8080 localhost:80

Each 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.

Yes. You can attach custom domains to any box. Custom domains route through the same Shellbox reverse proxy as the canonical boxname-hash.shellbox.dev URL, so wakeup mode, idle tracking, and automatic TLS all work identically.

$ ssh shellbox.dev domain add mybox app.example.com

This creates a pending mapping. Next, set up a DNS record pointing your domain to the box's canonical hostname. A CNAME record is recommended for subdomains, but A/AAAA records that resolve to the Shellbox ingress are also accepted. Apex domains may need ALIAS/ANAME support from your DNS provider. DNS must be set to DNS-only (not CDN-proxied):

app.example.com CNAME mybox-a1b2c3d4.shellbox.dev

Then verify:

$ ssh shellbox.dev domain verify mybox app.example.com

Once verified, your box is reachable at https://app.example.com. TLS certificates are issued automatically. The first request after verification may take a few extra seconds while the certificate is obtained. If certificate issuance fails (e.g. rate limits or DNS propagation delay), it will be retried on subsequent requests.

Key details:

• One box can have multiple custom domains
• One domain maps to exactly one box
• Domains survive box rename — they point to the VM, not the box name
• Only verified (active) domains route traffic
• v1 supports exact hostnames only, not wildcards
• Subdomains work well with CNAME; apex domains may also work via A/AAAA/ALIAS/ANAME, depending on your DNS provider
• DNS must be DNS-only — CDN-proxied records may fail verification because they resolve to CDN IPs, not the Shellbox ingress
• Ownership is checked when you run domain verify; v1 does not continuously revalidate DNS ownership after activation
• After activation or removal, changes propagate after the short proxy cache expires (within a few seconds)

Manage domains with: domain add, domain verify, domain remove, domain list. Add --json for machine-readable output.

Yes. Every new box gets a stable public IPv6 address derived from the box's network identity. The address is shown in create, create-from-oci, show, and list, and in the corresponding --json output as public_ipv6.

The IPv6 is for direct guest access — ssh root@<ipv6>, mosh root@<ipv6>, raw TCP/UDP — while the box is running:

$ ssh root@2001:db8:1234:5678::3
$ mosh root@2001:db8:1234:5678::3

Key details:

• The IPv6 is stable for the life of the box — rename and restart do not change it
• Direct IPv6 only works while the box is running; it does not wake stopped boxes
• It is a separate access plane from the managed HTTPS ingress — custom domains and the canonical https://<box>... URL remain the right path for HTTP, wakeup, idle tracking, and TLS
• Pricing is unchanged — direct IPv6 is included, not a separate SKU
• Direct IPv6 is assigned to all new boxes

Yes. Every new box has direct IPv6, so Mosh works while the box is running. Mosh needs a direct UDP path to the guest, which the managed SSH bastion plane does not provide, so you connect straight to the box's IPv6 address:

$ mosh root@<ipv6>

Use the IPv6 shown for the box in list or show. Mosh does not participate in wakeup or idle tracking, so the box must already be running — start it first through the normal Shellbox flow (e.g. ssh mybox@shellbox.dev, then disconnect with keepalive on, or simply leave it running).

Through the managed Shellbox SSH endpoint, the SSH username selects the box name: ssh mybox@shellbox.dev connects to box mybox and logs into the guest as root. So non-root guest usernames are not available through that bastion path.

If you want normal Linux users, create them inside the box and use the box's direct IPv6 address:

root@mybox:~# adduser alice
root@mybox:~# mkdir -p /home/alice/.ssh
root@mybox:~# cp /root/.ssh/authorized_keys /home/alice/.ssh/authorized_keys
root@mybox:~# chown -R alice:alice /home/alice/.ssh

$ ssh alice@<ipv6>

Direct IPv6 works while the box is running and does not wake stopped boxes. Start it first through the Shellbox SSH flow, or keep it running with ssh shellbox.dev keepalive mybox. If you only need to become another user occasionally, you can also connect normally and run su - alice or sudo -iu alice inside the 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.dev

Current OCI support is intentionally narrow in v1. Supported images should be:

• public images
• linux/amd64
• Ubuntu-like userspaces (Ubuntu, Debian, and derivatives)
• images with apt-get available so shellbox can inject SSH and guest runtime packages

A 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.dev

Several 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.git

Add 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 token

Generate 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 login

Generate a key on the box — for a dedicated deploy key:

root@mybox:~# ssh-keygen -t ed25519
root@mybox:~# cat ~/.ssh/id_ed25519.pub

Add 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 newname

This 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. Custom domains attached to the box are not affected by rename — they point to the VM, not the box name.

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-world

You 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 --ch

Nested 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.