Unikraft

Agents' tools run on Unikraft rather than coming from it. The docs cover hosting MCP servers as microVMs that wake when an agent calls them, webhook receivers and API gateways, and connecting workloads to hyperscaler services such as S3, and a customer story describes keeping credentials outside the VM. No catalog of connectors, OAuth actions or credential brokering of Unikraft's own is documented, so the read and write integrations are the customer's code.

Sourceunikraft.com/docs/use-cases/mcp-serversread 2026-09-22

Unikraft schedules and scales microVMs (autoscale, load balancing, forking a live VM for parallel sub-agents) but does not sequence, branch, retry or route an agent's steps. That logic lives in the customer's code. No workflow logic mixing deterministic nodes with agent steps is documented as a Unikraft mechanism. Scheduling infrastructure across metros is compute placement rather than workflow orchestration.

Sourceunikraft.com/llms-full.txtread 2026-09-22

Unikraft runs the customer's workloads, including databases and MCP servers, but does not maintain a retrieval structure over the customer's content that an agent queries. Volumes and databases hosted on it are the customer's storage, not a Unikraft index a query returns. No sources the product indexes, refreshes or permissions are documented.

Sourceunikraft.com/llms-full.txtread 2026-09-22

No approval step, consent checkpoint or escalation to a person is documented for work running on Unikraft. The closest features are the network shield and relay, an Enterprise feature that routes an instance's traffic through a relay VM, and delete locks that stop instances being removed. Both are isolation and protection the developer configures, not a point where a person reviews an agent's action. Nothing documented shows where approvals can be inserted.

Sourceunikraft.com/docs/features/network-shieldread 2026-09-22

The company states SOC 2 Type II (Security criteria, audit period July 2024 to July 2025), HIPAA compliance with BAAs available, and an independent penetration test by DEFION Security in May 2026 that found no exploitable cross-VM, hypervisor, filesystem or host-agent issues. Controls customers use sit beside it. Every workload is its own Firecracker-based microVM with per-tenant filesystem boundaries, delete locks protect instances from removal, and on Enterprise a network shield and relay route an instance's traffic through a relay VM.

No SSO, roles or identity provider support is documented, and the stated audit period ended in July 2025.

Sourceunikraft.com/llms-full.txtread 2026-09-22

Logs and metrics follow the instance rather than the agent. Every user gets full stdout and stderr logs, paying customers get Prometheus metrics, and a metrics API reports CPU time, memory, network I/O, connection counts and scale-to-zero wake latency per instance. That covers export to monitoring systems. Inspecting prompts, tool calls, retrieved knowledge and outputs step by step is left to the customer's own code, and no audit log separate from runtime or retention by plan is documented.

Sourceunikraft.com/docs/platform/metricsread 2026-09-22

A workload's state carries across sessions. Instances snapshot and resume in milliseconds with their state intact, a live VM and its children fork in about ten milliseconds, managed volumes persist data, and paid plans add snapshot history and rollback. The agent's code reads that restored state to carry on.

A volume is storage the code reads, and restored process state belongs to the machine: the buyer can resume, roll back or delete it but cannot review or edit it as memory. No memory layer with a stated scope and lifetime is documented. A browser session ROM carrying its own cookies and profile is a saved login, not agent memory.

Sourceunikraft.com/docs/features/snapshotsread 2026-09-22

Unikraft Cloud runs in named metros the customer selects (Dallas, Frankfurt, San Francisco, Singapore and Washington DC by default, listed per account). Its fact sheet documents hosted, dedicated hosted, on-premises and BYOC deployment on bare metal or on AWS EC2, GCP Compute Engine or Azure VMs, plus a Kubernetes integration that adds Unikraft Cloud as a node in EKS, GKE, AKS or the customer's own cluster.

Sourceunikraft.com/docs/platform/metrosread 2026-09-22

Templates here are snapshots of the customer's own warmed up workload that new instances boot from, not ready made starting points from the vendor. The vendor's use case pages (sandboxes, headless browsers, MCP servers, remote desktops) describe patterns rather than shipping working agents or templates a buyer adopts. No production-ready templates or role-specific agents are documented.

Sourceunikraft.com/docs/features/on-demand-templatesread 2026-09-22

Incoming connections wake work without the customer's code starting it. An instance scaled to zero consumes nothing until the next connection arrives, when the platform boots or resumes it in milliseconds and answers, so an MCP server wakes when an agent calls it and a webhook receiver wakes on the incoming event. A tutorial covers scale-to-zero triggers. No scheduler is documented.

Sourceunikraft.com/docs/features/scale-to-zeroread 2026-09-22

Any Dockerfile workload runs here, and nothing about language models is documented. No model selection, routing, provider keys or guidance for connecting the customer's own models is documented, and the one GPU mention is rendering for headful browsers. Nor does the platform impose a model of its own.

Sourceunikraft.com/llms-full.txtread 2026-09-22

From outside, a documented platform REST API (instances, templates, volumes, services, metrics) drives Unikraft Cloud, alongside the unikraft CLI with a raw API passthrough, a Kraftfile specification, and Kubernetes and Karpenter integrations. No SDK or MCP server of Unikraft's own is documented, and some newer features (plugins, network shield) are API only for now.

Sourceunikraft.com/docs/llms.txtread 2026-09-22

Tests get somewhere to run, but agents are not tested. The build and test environments use case and forking give the customer disposable, parallel VMs, but no fixtures, scoring, quality gates or comparison of agent runs are documented as Unikraft features.

Sourceunikraft.com/docs/llms.txtread 2026-09-22

Browser and desktop agents get their machines here. Every browser session can run in its own disposable headless or headful microVM with GPU rendering, booted from a snapshotted template, and whole desktop sessions snapshot after login and resume on connect. Browser-agent companies run on it. The platform is browser-agnostic, so the customer brings the browser and drives it with its own tooling, and no Unikraft API for screenshots, clicks or typing is documented. What Unikraft supplies is the environment for operating web interfaces and desktops, not the control.

Sourceunikraft.com/docs/use-cases/headless-browsersread 2026-09-22