microsrv:~$
RUEN
Console

microsrv

use case · AI sandboxes

A persistent sandbox for AI agents.

Most AI sandboxes are short-lived containers, which makes them unsuitable for long-running services, browser automation, caches, and agents that resume work later. A microsrv VM is a complete Linux environment with root access, a volume, a private network, and SSH. Live migration keeps it running when the underlying host is reclaimed.

Open consoleSee pricing
ssh · agent sandbox
$ ssh -A agent-17@msrv.spacemicrosrv: connection to agent-17 establishedubuntu@agent-17:~$ curl -s https://api.openai.com/v1/models | head -c 80{"object":"list","data":[…]} ubuntu@agent-17:~$ systemctl status my-worker● my-worker.service — active (running)ubuntu@agent-17:~$

Isolation for each agent run

Give each agent run its own VM. A compromised or faulty agent cannot reach your laptop or other workloads, and you can delete the VM when the job is complete.

  • Private network

    eBPF-isolated networks keep sandboxes separated from each other and from production. You can reach a sandbox through the WireGuard gateway from your work laptop.

  • No public IP required

    Outbound NAT for model APIs and tools; inbound connections only through the SSH gateway and HTTPS gateway.

  • Disposable

    Create a VM for each task and delete it when finished. Its volume and identity remain consistent while the job runs.

Outbound access without public ingress

Agents need to call model APIs, download packages, and browse the web. microsrv provides outbound NAT; inbound SSH and HTTPS go through the SSH gateway and HTTPS gateway.

  • Model APIs

    Reach OpenAI, Anthropic, and other HTTPS APIs from inside the sandbox.

  • Builds and browsers

    CI-style workers, scrapers, and browser automation fit the same private-outbound pattern.

  • Stable SSH

    Control the VM from your code or laptop with ssh -A <vmId>@msrv.space.

Persistent environments for multi-step agents

Volumes, processes, and network identity remain intact when a host is reclaimed. Recovered VMs resume their work instead of starting in a new container.

  • Live migration

    Memory and running processes move before the host is shut down.

  • Replicated storage

    Caches, checkouts, and agent state remain on the volume across recoveries.

  • Lower cost

    About 25% below major cloud rates for comparable capacity.

> capabilities

Built for agent fleets

Use the same VMs you would access over SSH yourself, without a proprietary container configuration.

  • Real Linux

    Use root access, systemd, apt, and long-running services rather than a single-command sandbox.

  • Dedicated vCPUs

    Dedicated vCPUs are exclusive to the VM for predictable agent throughput.

  • Optional HTTPS gateway

    Publish HTTPS services at <vmId>.msrv.space when needed; keep other sandboxes private.

  • cloud-init support

    Automate tool and credential setup during the first boot of every new sandbox.

  • Multi-VM groups

    Place related workers on one private network for service-to-service traffic.

  • Ops-friendly SSH

    Inspect, debug, and intervene over the same SSH gateway your automation uses.

Give each agent a complete Linux environment.

Persistent Linux VMs with SSH, outbound access, and live migration, priced for dynamic fleets.

Open consoleAsk a question