Practice the VPS workflow before the VPS bill

Disposable Ubuntu servers on your own machine, with real SSH, hostnames and TLS. Rehearse, break things, then push the result to the real server.

Download VPSBoxSee what’s new in 1.6
  • macOS, Windows, Linux
  • Ubuntu 24.04 VMs
  • Free
VPSBoxImport from VPSNew server

Servers

  • dev-1
  • staging-db
  • coolify-labStarting
  • old-testStopped
  • Activity

dev-1Running

Push to VPSOpen shell

OverviewDeploySnapshotsLogs

Hostname
dev-1.vpsbox.local
IP
192.168.64.12
SSH user
ubuntu
Key
~/.vpsbox/keys/dev-1

4 servers2 running1 starting1 stopped

New in 1.6

Sandboxes now reach real servers, each other, S3 and your AI agents

Version 1.6.0 shipped on October 13, 2026. Here is what it adds.

Push a sandbox onto a real VPS

$ vpsbox push dev-1 --to root@203.0.113.10

Replicates the packages you installed, your files under /root, /home, /opt, /srv and /var/www, service configs, Docker volume data, enabled services and running compose projects. The migration plan is shown and confirmed before anything is touched.

Machine identity never moves: SSH server settings, host keys, .ssh directories, network and firewall configuration all stay put, so a push can’t lock you out of your server.

Migration plan

dev-1 root@203.0.113.10

Moves

  • Packages you installed
  • Files under /root /home /opt /srv /var/www
  • Service configs
  • Docker volume data
  • Enabled services
  • Running compose projects

Stays put

  • SSH server settings
  • Host keys
  • .ssh directories
  • Network configuration
  • Firewall configuration

Nothing on the server is touched until you confirm.

CancelPush

Import a real VPS into a sandbox

$ vpsbox import root@203.0.113.10

Clones a real server into a local sandbox sized to hold what runs there. The server is only read from; nothing on it changes. Rehearse the risky upgrade, break the clone, run vpsbox undo, and only then touch the real machine.

In the app, Import from VPS checks the server first and shows its OS, the data to copy and the sandbox size it will get before any VM is created. Progress is live, stage by stage, and closing the window keeps the job running under Activity.

How push and import move data

  1. Real VPS

    root@203.0.113.10

  2. Your machine

    relays every byte

  3. Sandbox

    dev-1

The sandbox and the VPS never need to reach each other.

Architecture
Survives the change, e.g. an Apple Silicon sandbox pushed to an Intel VPS
Packages
Installed from the destination’s own apt archive
Docker images
Pulled on the destination

Private networks between your servers

Members of a workspace reach each other by name, psql -h db or curl http://api:3000, at stable addresses instead of one that changes on every restart. Servers on different workspaces can’t reach each other, so a staging group and a production group run side by side.

  • Check what worksvpsbox workspace show alpha --check pings every member from another one and shows what actually works.
  • Survives restartsvpsbox workspace sync repairs a member that was off while things changed.

alphaworkspace

betaworkspace

worker

curl http://api:3000

api

psql -h db

db

can’t reach

web

$ vpsbox workspace create alpha
$ vpsbox workspace add alpha db
$ vpsbox workspace show alpha --check
$ vpsbox workspace sync

S3 buckets on your own machine

vpsbox bucket create backups gives you a real S3-compatible endpoint locally, with no cloud account and no bill. Buckets live on your machine, not inside a sandbox, so they outlive the server that wrote to them. That makes “back up the database, wipe the server, restore it” something you can rehearse.

Terminal

  1. 1Create

    $ vpsbox bucket create backups
# a real S3-compatible endpoint, on this machine

  2. 2Attach

    $ vpsbox bucket attach
# credentials go where every S3 client already looks

  3. 3Back up

    root@dev-1:~# pg_dump mydb | s3 cp - s3://backups/mydb.sql

  4. 4Wipe

    # wipe the server: the bucket lives on your machine, so the dump survives

  5. 5Restore

    root@dev-1:~# s3 cp s3://backups/mydb.sql - | psql mydb
  • Both addressing styles. Path-style and bucket.buckets.vpsbox.local subdomain addressing both resolve.
  • One store for every sandbox. Every sandbox shares the same store.
  • Hard to delete by accident. Deleting a bucket that still holds objects is refused unless you pass --force.

Let AI agents manage your sandboxes

Turn on the MCP server in Settings, and these clients can list, create, start, stop, snapshot and resize sandboxes, deploy platforms and apps into them, read logs, and run commands:

  • Claude Code
  • Codex CLI
  • Cursor
  • Gemini CLI
  • VS Code
  • Windsurf
  • OpenCode

Settings shows the exact install command or config block for each client, with the token filled in.

  • One token per clientEach token has an access level and can be limited to particular sandboxes. Revoking it cuts the client off immediately.
  • Every call recordedThe MCP Activity tab records each tool call with token, sandbox, arguments, outcome and timing, secrets masked.
  • Local onlyThe server listens on 127.0.0.1 only, refuses requests from web pages, and runs only while VPSBox is open.

Claude Code token

Access level: Deploy

  1. Danger Not granted

    Also run shell commands inside sandboxes, delete snapshots, and destroy sandboxes.

  2. Deploy This token

    Also create and resize sandboxes, and deploy platforms and apps into them.

  3. Operate Included

    Also start and stop sandboxes, checkpoint them, and restore snapshots.

  4. Read Included

    List sandboxes, apps, logs, snapshots, and jobs. Changes nothing.

Also in 1.6: select several servers (⌘-click or Shift-click) and start, stop, resize or delete them together; each gets its own job under Activity.

Features

Everything else a server needs

Shipped in earlier releases.

Snapshots

Save
Named checkpoints
Roll back
In a click
Drift
What changed since the checkpoint: packages, services, listening ports and files added, removed or modified

Deploy

Platforms
One-click Coolify, Dokploy, Dokku or CapRover
Apps
Gitea, n8n, Uptime Kuma, Portainer, NocoDB, Vaultwarden, Metabase, Code Server and more
Memory
Templates that need more memory than the sandbox has are flagged first
Secrets
Passwords and keys are generated on the server

Logs

Sources
System journal, network connections, routes, Docker containers and recent Docker activity
Reading
Color-coded by category, filterable, searchable

Updates in the app

Install
Downloads the new version and installs on restart
Verified
Every download is checked against a signed checksum list; on macOS it must carry the same Developer ID
Rollback
A failed update puts the old version back

Native interface

Appearance
Follows system dark mode
Zoom
The whole app, 80–160%

Demo

Rather watch than read?

The demo video plays here without leaving the page.

How it works

Four steps from installing the app to shipping the server

  1. Prepare your machine

    The app checks for and installs Multipass and the other dependencies from one screen.

  2. Create a sandbox

    Name it and pick resources. SSH keys, cloud-init and the hostname are automatic.

  3. Work like it’s rented

    SSH in, deploy, snapshot, break it, roll back.

  4. Ship it

    Push the sandbox to your real VPS, or hand off to Server Compass for its 400+ app catalog on real fleets.

VPSBox vs Docker

VPSBox is the server. Docker runs inside it.

Docker
Packages an app
VPSBox
Fakes a rented server

Deploy tools like Coolify, Dokploy and Kamal expect a whole machine. They SSH in as root, install Docker, configure systemd and the firewall, which you can’t test inside a container. So they nest.

VPSBox VMUbuntu 24.04

  • Real IP
  • Root SSH
  • systemd
  • TLS certificate

The deploy tool

  • Coolify
  • Dokploy
  • Kamal

SSHes in as root, installs Docker, configures systemd and the firewall.

Docker containers for your apps

  • web
  • db
  • proxy

Test the VPS path before the VPS exists.

Download VPSBox
  • macOS, Windows, Linux
  • Ubuntu 24.04 VMs
  • Free