Krova Bare Metal: Why Your Own Hypervisor Matters

Running untrusted code from AI agents, CI jobs, or user uploads on shared hypervisors is a liability. The kernel is shared. A container escape reaches your host and every other project on the same machine. Owned bare metal servers with your own hypervisors solve this. Most teams never consider it because cloud providers lock you into their margins and abstractions. When you control the infrastructure and manage the hypervisor, isolation becomes genuine, costs drop dramatically, and you keep the systems you built.

TL;DR:

• Owned servers eliminate hyperscaler markups and give you direct control over isolation boundaries.
• Controlled infrastructure lets you deploy lightweight microVMs with per-minute billing instead of monthly overages.
• Running AI agent sandboxes on physical servers means each agent gets its own kernel in milliseconds, with zero blast radius if it fails.
• Copy-on-write forking technologies create new VMs in ~0.8ms, making ephemeral workloads economical.
• Self-managed servers require operational overhead; managed platforms remove that without sacrificing control.

What Is Bare Metal Server Infrastructure?

A Bare Metal server is hardware you own or lease directly, without a hypervisor layer between you and the machine. You install your own hypervisor (Proxmox VE, Hyper-V, KVM, or managed platforms), partition the resources, and deploy workloads with full kernel isolation. Unlike public cloud providers who run your VM on shared infrastructure and charge monthly subscriptions, owned servers give you ownership of the resource pool and flexibility in billing and tenant isolation.

The key difference: you control the hypervisor. Instead of renting a "slice" of AWS or DigitalOcean's infrastructure at their markup, you carve up your own hardware. That ownership eliminates the middleman tax on compute, and your security model is not dependent on trusting a hyperscaler's container orchestration or compliance practices.

For teams running AI agents or untrusted code, this matters. You get to decide: does every workload get its own full VM (strong isolation, slower), or do you use lightweight microVMs that boot in milliseconds (fast and safe)?

Running AI Agent Sandboxes on Owned Infrastructure

AI coding agents are productive but dangerous. They install packages, execute scripts, modify files, and run builds without human approval. In February 2026, the Cline VS Code extension was compromised through prompt injection, exfiltrating npm release tokens and publishing unauthorized packages to over 5 million users. If you give an agent direct access to your filesystem, credentials, and network, whether in the cloud or on Bare Metal, you are one exploit away from losing your source code and secrets.

Sandboxing the agent on owned infrastructure solves this. Each agent session runs in its own isolated container or microVM, never sharing a kernel with other projects or the host. If the agent goes rogue, deletes files, or executes malicious code, the blast radius is contained to that one disposable sandbox. Power it off. Start fresh. No cleanup required.

The engineering tradeoff is isolation speed versus isolation strength. Containers like Docker boot instantly but share the host kernel. One container escape and an attacker reaches your host. MicroVMs like Firecracker, used by AWS Lambda and Fargate, boot in milliseconds and run their own kernel behind hardware-enforced memory boundaries. Owned Bare Metal servers with hypervisors let you pick: Incus containers for development (fast, acceptable isolation), or microVMs for production (slower to start, genuinely safe).

Coi (Code on Incus) demonstrates this pattern. One command (coi shell) drops you into an isolated Linux container with your project mounted and Docker available inside. The agent runs as if on a real server but cannot touch your machine or credentials. Incus is a system container runtime, not an application container. Full OS, systemd, root, but still fast and ephemeral.

For production: microVMs are safer. Each agent gets its own kernel, filesystem, and root access inside an isolated sandbox. Firecracker on owned servers handles this well. Instances start in milliseconds and cost pennies per session because you pay only for the minutes they run.

MicroVM Isolation With Copy-on-Write Speed

The reason Bare Metal microVMs are economical is copy-on-write forking. Instead of booting a fresh VM from disk every time, you snapshot a pre-configured template VM and fork new instances from that snapshot using memory-mapped copy-on-write. Each fork is a separate hardware-isolated KVM VM, a real VM, not a container, but it springs into existence in ~0.8ms and uses only ~265KB of memory per sandbox until it writes data.

Zeroboot demonstrates this at scale: sub-millisecond VM sandboxes using Firecracker and copy-on-write forking. Compared to alternatives like E2B (sub-200ms cold starts), Daytona (sub-60ms), and microsandbox (~200ms), Zeroboot's 0.8ms startup means you can spawn thousands of agent sessions per day without the latency penalty of traditional VM provisioning.

On owned servers with microVMs, every millisecond saved translates directly to cost. If your agent sandbox boots in 0.8ms instead of 150ms, you spin up 187 times more sandboxes in the same minute. Running untrusted code no longer feels expensive.

The catch: copy-on-write forking requires physical servers or deep hypervisor access. You cannot do this on AWS EC2 or a shared VPS. You need a platform that owns the infrastructure and has implemented the kernel-level fork machinery. That is why teams either self-manage servers with KVM/Firecracker (operational overhead, full control) or use a managed platform that abstracts away the ops layer while keeping the isolation model and cost efficiency.

Cost Efficiency Without Hyperscaler Margins

Public cloud providers add a markup on compute. AWS Lightsail, DigitalOcean, Vultr, and Linode buy physical servers from hosters like Hetzner or Equinix, install a hypervisor, and resell slices at a margin. That margin is built into every hour you run an instance, even when idle.

Owned servers cut that markup. Per-minute billing (not monthly subscriptions) means compute charges stop the instant you power off. No paying for idle overhead.

The math is straightforward. A 2 vCPU / 4 GB RAM / 80 GB disk instance running 24/7 costs roughly $80/month on DigitalOcean. On owned physical servers, the same spec might cost $25–$30/month. Over a year, that is $600–$660 saved for one instance. Scale that across a team running multiple AI agent sandboxes, CI runners, and dev environments, and owned infrastructure pays for itself.

The deeper win is cost efficiency at scale. Because physical servers remove hyperscaler margins, you can afford to treat instances as ephemeral. Spin up a sandbox for one agent task, run it for 30 seconds, power it off. On a monthly-billed platform, you waste $80. Owned servers with per-minute billing make the economics of disposable sandboxes viable.

Building Sandboxes: Incus, Firecracker, and Self-Managed Options

Three paths to sandboxing exist, each with different trade-offs.

Self-managed servers with KVM and Firecracker. You lease a bare metal server from Hetzner or similar, install KVM, run Firecracker workloads, and manage the stack yourself. You own the infrastructure and keep all the margin. You also own the operational burden: kernel patching, networking, firewalling, resource monitoring, and disaster recovery. This path suits teams with deep ops expertise and long-term infrastructure commitments. Standard Applied Intelligence Labs built sail, a CLI for provisioning servers and managing agentic workflows on Firecracker. A dedicated server at Hetzner costs $50–$100/month. A Mac Mini M4 Pro costs $1,500–$2,000 per engineer. The math works if you amortize infrastructure across multiple team members.

Managed platforms. A provider operates physical servers on your behalf, handling the hypervisor, networking, snapshots, and backups. You provision sandboxes via CLI or API, pay per-minute or per-month, and skip the ops overhead. You get owned infrastructure economics without running your own hypervisor. This path suits startups and teams who want isolation and cost efficiency without building a DevOps function.

Incus containers (lightweight system containers). Incus is the production-ready fork of LXD, offering full-OS containers with systemd, Docker, and root access but faster startup and lower overhead than full VMs. Incus containers share the host kernel, so isolation is weaker than microVMs, but they are fast (millisecond startup), easy to manage, and sufficient for development sandboxes where users are not actively adversarial. If you run trusted internal code or low-risk dev workflows, Incus on Bare Metal is cheaper and simpler than microVMs.

Each path trades off operational complexity, isolation strength, and cost. Pick based on your risk model: development environments tolerate shared-kernel containers; production AI agents need microVM isolation; long-term projects justify self-managed servers; short-term projects benefit from managed platforms.

FAQ

What Is the Difference Between Physical Servers and a Cloud VM?

A cloud VM like EC2 or DigitalOcean runs on a hyperscaler's shared physical server, and you pay a monthly subscription even if idle. Owned servers are hardware you lease directly, where you control the hypervisor and billing. This infrastructure removes the hyperscaler's markup and lets you use per-minute billing for ephemeral workloads.

Why Do AI Agent Sandboxes Need Owned Infrastructure?

AI agents require strong isolation: each agent must not access another agent's files, credentials, or environment. Shared hypervisors and container runtimes create escape risk. Owned servers with hypervisors let you give each agent its own kernel and disposable sandbox. If the agent fails or misbehaves, you power off one isolated instance with no impact on the host or other projects.

How Fast Do microVMs Boot on Owned Servers?

Firecracker microVMs with copy-on-write forking boot in ~0.8ms. Traditional VM provisioning takes 30–60 seconds. This speed is only possible on owned servers because you control the hypervisor and snapshot technology. On shared cloud platforms, you cannot achieve sub-millisecond startup.

Do I Need to Self-Manage Physical Servers?

No. Managed platforms operate physical servers and provide a CLI, API, and dashboard to provision isolated workloads. You get owned infrastructure economics and strong isolation without running a hypervisor yourself. Self-managed servers are an option only if you want to amortize infrastructure costs across a large team or have specialized security requirements.