Push to a real VPS, private networks, local S3 buckets and an MCP server

Push a sandbox onto a real VPS — vpsbox push dev-1 --to root@203.0.113.10 replicates the work you did locally onto a real server: 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 cannot lock you out of your server.

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.

Your machine relays the copy — the sandbox and the VPS never need to reach each other; every byte flows ssh → your machine → ssh. Migrations also survive architecture changes (Apple Silicon sandbox → Intel VPS) because packages are installed from the destination's own apt archive and docker images are pulled on the destination rather than copied.

Both flows in the desktop app — every server has a "Push to VPS" action that previews the full migration plan before the push button appears, and the toolbar's "Import from VPS" checks the server first and shows what it found — its OS, the data to copy, and the sandbox size it will get — before any VM is created. Both run with live stage-by-stage progress and a tail of the real output; closing the window keeps the job running under Activity, and a finished import jumps straight to the new server. SSH keys are picked with a native file dialog, and the last-used server is remembered.

Private networks between your servers — vpsbox workspace create alpha allocates a private network, and vpsbox workspace add alpha db puts a server on it with a stable address of its own. Members reach each other by name — psql -h db, curl http://api:3000 — instead of by an address that changes every time the server restarts.

Workspaces keep groups apart — Servers on different workspaces cannot reach each other, so you can run a staging group and a production group side by side without them seeing each other. vpsbox workspace show alpha --check pings every member from another one and shows you what actually works, rather than only what was configured.

Survives a restart — Private addresses are written into the server's network configuration and the isolation rules are reloaded at boot, so a workspace is still there after you stop and start a server. vpsbox workspace sync repairs any member that was switched off while things changed.

S3 buckets on your own machine — vpsbox bucket create backups gives you a real S3-compatible endpoint locally, no cloud account and no bill. Buckets live on your machine rather than inside a sandbox, so they outlive the server that wrote to them — which is what finally makes "back up the database, wipe the server, restore it" something you can rehearse before doing it for real.

Sandboxes come pre-wired — vpsbox bucket attach teaches a sandbox how to reach the store and drops credentials where every S3 client already looks for them, so nothing inside the box needs a flag or a config file: pg_dump mydb | s3 cp - s3://backups/mydb.sql just works. Both path-style and bucket.buckets.vpsbox.local subdomain addressing resolve, so SDKs that insist on either one behave.

Shared across sandboxes — Every sandbox talks to the same store, so backing up from one box and restoring into another is a thing you can practise too.

Careful with the one thing snapshots can't undo — Deleting a bucket that still holds objects is refused unless you pass --force. Stopping the store keeps your buckets and their contents on disk, and reuses the same credentials on the next start so already-attached sandboxes keep working.

Let AI agents manage your sandboxes — Turn on the MCP server in the new Settings screen and Claude Code, Codex, Cursor, Gemini CLI, VS Code, Windsurf, or OpenCode can list, create, start, stop, snapshot, and resize your sandboxes, deploy platforms and apps into them, read their logs, and run commands inside them. Settings shows the exact install command or config block for each client, with your token already filled in, and can open the client's config file for you.

You decide how much an agent can do — Every client connects with its own token, and each token gets an access level: Read, Operate, Deploy, or Danger. Only Danger can run shell commands or destroy anything, and a token can be limited to particular sandboxes. Revoking a token cuts that client off immediately.

See every call an agent made — The MCP Activity tab records each tool call with the token, sandbox, arguments, outcome, and timing, with secrets masked. Long-running work an agent starts — creating a sandbox, deploying Coolify — also shows up under Activity alongside everything else, with live progress.

Stays on your machine — The server listens on 127.0.0.1 only, refuses requests from web pages, and runs only while VPSBox is open.

Work on several servers at once — ⌘-click (Ctrl-click on Windows and Linux) or Shift-click servers in the sidebar, or turn on the new select button next to "+", to pick a group, then start, stop, resize, or delete them together. When resizing a group, a field you leave empty keeps each server's own value, the sheet previews exactly what changes on each server, and a disk size smaller than one a server already has is refused before anything runs. Each server gets its own job under Activity, so one failure doesn't hide the rest.