Run agents on
your infrastructure.

Run VMYard on hosts your team operates, alongside the application and tools your agents already use. Choose where their workspaces live, how much capacity they receive, and how saved work is retained.

Plan your deployment See how it fits your stack

Run VMYard on a Linux host you operate, alongside your agent application.

Product illustration

Choose where
the work runs.

VMYard is software your team runs on Linux hosts with hardware virtualization. The session's files and saved state live on those hosts. Your team chooses the storage, network access, and operating policies around them.

Which hosts can run VMYard?

The current real-VM deployment scope is Linux x86_64 with KVM, using Firecracker or Cloud Hypervisor. Cloud VMs need usable nested virtualization. Host administration requires privileged access. Docker offers a development path, including on macOS, with a different isolation model.

Add hosts when
the workload grows.

A single host can run multiple independent sessions. Across several hosts, the fleet controller places new work where there is capacity and leaves headroom for saved sessions to return.

Your team sets the available resource budget and adds machines as demand grows. VMYard manages sessions within that capacity; it does not purchase or provision infrastructure.

Your application decides.
VMYard runs the session.

Where VMYard fits in your stack
VMYard provides	Your team operates
Separate workspaces and command execution	Agent logic, tools, and guest images
Session placement and resource limits	Hosts, capacity, patches, and monitoring
Session ownership and controlled runtime access	User permissions and business approvals
Save, restore, and recovery-copy operations	Storage protection, retention, and recovery policy

The offering is customer-operated software. Your existing infrastructure and application teams remain responsible for the service around it.

Budget for saved work,
as well as active work.

Snapshot sleep releases CPU and memory while retaining session state on disk. Account for that storage, recovery copies on other hosts, and the capacity needed when work returns.

What affects storage and recovery planning?

Snapshot size reflects saved memory and guest disks. Restore requires compatible runtime, kernel, and CPU characteristics. Cross-host copies require guest networking to be disabled. Your team supplies storage encryption and decides when to refresh or retire copies.

Prove the fit with
one complete task.

Choose a task that uses your real tools and data access. Run it on a suitable host, save it at a natural waiting point, and bring it back. That exercise gives both application and infrastructure teams a shared basis for deciding how VMYard fits.

Map VMYard to
your environment.

Capture the hosts, toolchain, connectivity, and saved state your workload needs in a deployment brief.

Build your evaluation brief

Run agents onyour infrastructure.

Map VMYard toyour environment.

Run agents on
your infrastructure.

Map VMYard to
your environment.