Why use a whole VPS as a sandbox instead of a container?

Blast radius. A container on your own machine shares the kernel and sits next to your files, keys and network. A separate VPS is real isolation — untrusted, AI-generated code runs on a machine that has nothing of yours on it, and when the task is done the whole box is destroyed. For code you don't trust, a disposable server is the cleaner boundary.

How does the agent create and destroy the box itself?

Over our MCP server the agent calls order_vps to provision a fresh machine (paid from a prepaid crypto balance), reads its SSH access with get_vps_status, runs the code, then cancel_service with mode 'immediate' to destroy it. No human clicks anything. The immediate cancel wipes the VM and refunds the unused paid time to the balance, so the next sandbox is funded.

What happens to the money when a short-lived box is cancelled?

Immediate cancellation refunds the unused portion of the paid period to your account balance — it isn't lost. So an agent that spins a box up for ten minutes and destroys it gets most of that period back as balance to fund the next one. Combined with the prepaid model, that's a hard spend cap: the agent can only ever use what's on the balance.

Is this actually secure isolation?

It's far stronger than a local container, and honest about its bounds. Each sandbox is its own VM with its own OS, IP and disk — nothing of yours is on it, and destroying it removes everything. It is standard VPS isolation, not a hardened security-research enclave; don't run something you'd only trust to a formally verified sandbox. For the common case — running code an LLM just wrote, without risking your own machine — a disposable VPS is exactly right.

Do you ask for ID or a card?

No. Email to register, USDC or USDT to pay. No documents, no card, no KYC — which matters when an autonomous agent is the one provisioning and paying.

Ephemeral VPS sandboxes: let an AI agent spin up, run untrusted code, and destroy the box

The moment an AI agent writes code you didn't review, you have a problem: where do you run it? Not on your laptop next to your SSH keys and your files. The usual answer is a container — but a container shares your kernel and lives on your machine. There's a cleaner boundary that almost nobody uses because it used to be too slow to set up: a whole disposable VPS the agent creates, uses, and destroys on its own.

That's what this is about — and it's a pattern EQVPS is uniquely built for, because the agent can do the entire lifecycle itself over MCP.

Why a disposable VPS beats a local container

For running code you don't trust, the question is blast radius — what can it touch if it misbehaves?

A local container shares your kernel, sits on your network, and is one misconfiguration away from your host. Fine for code you wrote; risky for code an LLM just generated.
A disposable VPS is a separate machine with its own OS, its own IP, and nothing of yours on it. The untrusted code runs there. When it's done, the box is destroyed and everything on it goes with it.

The reason people didn't do this before is friction: creating and tearing down a server meant a dashboard, a card, a human. Remove that and the disposable-VPS sandbox becomes the obvious choice.

The lifecycle, owned by the agent

This is the part that only works here. Over our MCP server the agent runs the whole loop with no human:

order_vps({ product: "nano", os_id: 1 })      // fresh box, paid from prepaid balance
get_vps_status({ service_id })                // → ip, ssh_port, one-time root password
// agent SSHes in, runs the untrusted code, reads the result back
cancel_service({ service_id, type: "immediate", confirm: "<hostname>" })
//    → VM destroyed; unused paid time refunded to balance

Four calls: create, read access, run, destroy. No dashboard, nobody approving a purchase. The agent bought and ran its own server; now it disposes of it too.

The economics that make it practical

Two design choices turn this from "expensive" into "obvious":

Prepaid balance = hard spend cap. The agent pays from a balance you funded once with crypto. It can never spend more than what's there — so a runaway loop creating boxes is bounded by the balance, not your whole wallet.
Immediate cancel refunds unused time. Destroying a box mid-period returns the unused paid time to your balance (refund_amount), which funds the next sandbox. An agent that spins up a box for ten minutes gets most of that period back. Short-lived boxes stay cheap.

Together they make a throwaway-per-task sandbox economically sane, not a money pit.

Honest scope

This is VPS isolation, not a security-research enclave. Each sandbox is a full VM — much stronger than a local container, but it's standard virtualization, not a formally hardened sandbox. For running code an LLM just wrote without risking your own machine, it's exactly right; for adversarial malware analysis, use purpose-built tooling.
Provisioning takes about a minute. A fresh VM boots and SSH answers in roughly 60 seconds — quick, but not instant like a warm container. For per-task isolation that's fine; for sub-second function calls it isn't the tool.
The AUP still applies. A disposable sandbox for your own untrusted code is fine; using throwaway boxes for abuse, attacks or spam is not, and gets the account terminated.

Why here specifically

No other host lets an agent own this loop end to end: create, pay, run, destroy, refund — with no human, no card, and no KYC. Email to sign up, USDC or USDT to fund a balance, and an agent can manage a fleet of disposable sandboxes on its own. If you're building an agent that writes and runs code, this is the isolation boundary that doesn't put your machine on the line. Point it at the MCP endpoint and let it provision.