Unikernels vs Containers vs MicroVMs for Edge IoT: Isolation, Boot Time and Attack Surface

An edge gateway in a factory or substation runs software from several parties: the OEM’s protocol drivers, an analytics vendor’s model runner, a customer’s custom script. Today most of that code shares one Linux kernel through containers, which means one kernel bug can turn any tenant into the owner of the whole box. The alternatives are lighter than they used to be, but they trade different things away, and the marketing numbers rarely survive contact with a 2 GB ARM gateway.

The debate of unikernels vs containers is really a three-way question once microVMs enter. A container shares the host kernel. A microVM gives each workload its own guest kernel behind a hardware virtualization boundary. A unikernel goes further and compiles the application and only the OS components it needs into a single-purpose VM image. Each choice moves your isolation, your boot time, your attack surface and your operational burden in a different direction.

This article gives you a mechanism-level comparison, worked numbers you can redo for your own fleet, and a decision rule for edge IoT.

What this covers: the threat model at the edge, how each technology isolates workloads, what the verified boot-time and memory figures actually say, how to count attack surface, failure modes, and a decision matrix with a rollout checklist.

Context and Background

Containers became the default packaging unit for edge software because they are cheap and familiar. A container is a Linux process with namespaces (what it can see), cgroups (what it can consume) and a seccomp filter (which system calls it may make). There is no second kernel. Every container on the gateway calls into the same kernel, so the kernel’s roughly 300-plus system calls and its drivers are the shared attack surface. Docker’s documentation states that its default seccomp profile disables around 44 of those 300-plus calls, describing the result as “moderately protective while providing wide application compatibility” (Docker seccomp docs). Put differently, a default container can still reach on the order of 250 system calls.

That is acceptable when you trust everything on the node. It is not acceptable when the node hosts code from different trust domains, which is increasingly common at the edge: multi-vendor gateways, on-prem AI inference, customer-supplied plug-ins, and agent-style workloads that execute generated code. The same pressure shaped the cloud sandbox market, and we covered the three leading isolation approaches in our comparison of Firecracker, gVisor and Kata for AI agent sandboxes. The edge version of the problem differs in three ways: the hardware is small, the network is unreliable, and a physical process is attached to the other end.

That last point matters. When a control-adjacent service restarts, the plant does not pause. A cold start measured in seconds is a control-loop problem, not a convenience issue. If you run predictive control close to the machine, as in model predictive control with a digital twin, then restart latency, memory headroom and failure containment become design inputs rather than afterthoughts.

Three technology families are on the table.

Containers (runc, containerd, Podman): process isolation on a shared kernel. Fast, dense, and the weakest boundary.
MicroVMs (Firecracker, Cloud Hypervisor, QEMU microvm machine type, and Kata Containers using one of them as the VMM): a minimal virtual machine monitor presents a tiny set of virtual devices to a full guest Linux kernel. Hardware virtualization (KVM) is the boundary.
Unikernels (Unikraft, OSv, MirageOS, Nanos and others): a library operating system linked with a single application into one image that runs as a VM guest. No shell, no multi-process model, a very small image.

Note that these are not mutually exclusive layers. Unikraft images run on Firecracker, and Kata runs containers inside microVMs. The useful question is where the isolation boundary sits and what lives on each side of it.

The Core Comparison: Where the Isolation Boundary Sits

The direct answer: containers isolate with software policy inside one shared kernel, microVMs isolate with a hardware-assisted virtualization boundary and a separate guest kernel, and unikernels use the same hardware boundary but shrink the guest itself to one application plus only the OS libraries it links. Isolation strength follows the boundary, attack surface follows what is exposed across it, and boot time follows how much guest software must initialize.

Figure 1: Isolation boundaries on one edge gateway. Containers share the host kernel; microVMs and unikernels sit behind KVM with a VMM as the only host-facing component.

Figure 1 shows the same gateway three ways. In the container model, the workload’s system calls land directly in the host kernel. In the microVM model, the workload’s system calls land in the guest kernel, and only a narrow set of virtual device interactions and VM exits reach the host. In the unikernel model, the “guest kernel” and the application are the same image, so there is no user/kernel privilege boundary inside the guest at all.

Containers: policy on a shared kernel

A container escape needs a kernel vulnerability, a runtime bug or a misconfiguration (privileged mode, a mounted Docker socket, excessive capabilities). Hardening tools help: a tighter seccomp profile, dropping capabilities, user namespaces, read-only root filesystems, and mandatory access control such as AppArmor or SELinux. These reduce reachable surface, but they do not add a second kernel. The consequence is that the blast radius of a kernel bug is the whole node.

gVisor sits between the poles. It is a userspace kernel written in Go that intercepts the application’s system calls, so the host kernel sees far fewer of them. It is not hardware-level isolation, and one comparison reports a 10 to 30 percent overhead on I/O-heavy workloads from interception (reported by Edera’s comparison; treat as a vendor-adjacent estimate, not a benchmark we ran).

MicroVMs: a small VMM in front of a real guest kernel

Firecracker is the reference design. Its documentation describes a threat model in which “all vCPU threads are considered to be running malicious code as soon as they have been started,” and it contains that code with nested trust zones (Firecracker design doc). Three mechanisms matter.

First, the device model is deliberately minimal: VirtIO network, VirtIO block, VirtIO vsock, a serial console, a partial i8042 keyboard controller used to signal reset, and the guest-visible interrupt controllers and timer that KVM itself provides. There is no USB, no GPU emulation, no PCI bus full of legacy devices. Every device you do not emulate is a parser you do not have to secure.

Second, the jailer. In production Firecracker should be launched through the jailer binary, which sets up cgroups and a chroot, drops privileges, and then executes Firecracker as an unprivileged process. After that, Firecracker can only touch what a privileged party hands it.

Third, seccomp. Per the same document, filters are enabled by default, allow only the minimal set of host system calls and parameters, and are installed per thread before guest code runs. So even a guest that escapes into the VMM process lands in a process that can make very few host calls.

The cost is real: you now run a guest kernel and a guest userspace per workload, you must ship and patch those kernels, and the host needs hardware virtualization (KVM). Many low-end ARM SoCs and some industrial x86 boards expose it, but you must verify rather than assume (see the gotchas section).

Unikernels: shrink the guest, keep the boundary

A unikernel keeps the hardware boundary and removes most of what lives inside the guest. Unikraft’s security documentation states that cross-application isolation is provided by the hypervisor because each VM runs one application, that “a Unikraft production image contains no shell,” and that the modular kernel lets you remove components such as the network stack when unneeded. It also states plainly that this “does not eliminate all attack vectors” (Unikraft security docs).

Two honest limits follow. First, with no user/kernel split, a memory-safety bug in the application or a library compromises the whole guest, because everything runs at the same privilege. Mitigations such as stack protection exist upstream for x86-64 and Arm64, while position-independent executable support was listed as under review for KVM on x86-64 on the docs page at the time of writing. Second, the unikernel is only as isolated from the host as the VMM and hypervisor are. A unikernel on a weak VMM is a small guest behind a leaky door.

Why the two VM-based options are not rivals

In practice the useful pairing is a unikernel as the guest and a minimal VMM as the host-facing layer. Unikraft’s own performance page reports guest boot on Firecracker, QEMU and Solo5 and application runs on QEMU/KVM, which tells you the model is VMM-agnostic. The decision between “microVM” and “unikernel” is therefore a decision about the guest: a general-purpose Linux guest you can run anything on, or a specialized image you must rebuild per application.

Deeper Analysis: Boot Time, Memory and Attack Surface with Worked Numbers

Boot time and attack surface are the two numbers vendors quote most and define least. Both need a definition before they can be compared.

What “boot time” means, and what has been measured

Firecracker’s specification states a target of 125 ms or less from receiving the InstanceStart API call to the start of the guest’s /sbin/init, measured with the serial console disabled and a minimal kernel and root filesystem. It also states a VMM memory overhead of 5 MiB or less, measured with a 1 vCPU, 128 MiB guest, and notes that VMM start-up to API-socket availability takes within 8 CPU-milliseconds, with wall-clock between 6 and 60 ms and typically around 12 ms (Firecracker SPECIFICATION.md). Those are design targets under a stated configuration on AWS bare-metal instances, not guarantees on a gateway SoC with an eMMC card.

Unikraft’s performance page gives a different class of numbers. For a hello-world guest it reports guest boot of tens to hundreds of microseconds on QEMU and Solo5, and no more than about 1 ms on Firecracker. Total VM boot including the VMM is reported as about 3 ms for Solo5 and Firecracker, about 10 ms for the QEMU microvm machine type and about 40 ms for standard QEMU. The same page cites other work (not re-measured) putting Alpine Linux on Firecracker at about 330 ms and OSv at 4 to 5 ms. It reports that 2 to 6 MB of memory is enough to boot its tested guests, with images for hello-world, nginx, Redis and SQLite under 2 MB (Unikraft performance docs). The page does not name the host CPU, runs on a single core, and the authors note competitor configurations were constrained, so these are best-case figures from the project itself.

Read the two sources together and a pattern appears. The boot time of a microVM with a general Linux guest is dominated by the guest kernel and init system, in the low hundreds of milliseconds with a trimmed config. The boot time of a unikernel is dominated by the VMM, in single-digit milliseconds. A third-party comparison cites roughly 100 to 200 ms boot for Firecracker with a regular guest (Edera comparison), consistent with the 125 ms target. Containers have no specified figure from the sources I could verify; a warm container start is process creation plus namespace and cgroup setup, which on a typical Linux host is tens of milliseconds, but image pull and filesystem preparation can dominate a cold start. Treat that as an estimate, not a measured value.

A worked recovery-time budget (illustrative)

Suppose a protocol-translation service on a gateway must be back within 1 second of a crash, and the supervisor takes 150 ms to detect failure and 100 ms to run its restart logic. That leaves 750 ms for the workload to reach readiness. The table uses the verified targets above plus labelled assumptions for the application’s own warm-up.

Option	Platform start (source)	App init (assumed)	Total	Fits 750 ms?
Container, image present	tens of ms (estimate)	200 ms	about 250 ms	Yes
MicroVM, trimmed Linux guest	125 ms target (spec)	200 ms	about 325 ms	Yes
MicroVM, stock distro guest	about 330 ms (cited for Alpine on Firecracker)	200 ms	about 530 ms	Yes, thin margin
Unikernel on Firecracker	about 3 ms total (reported)	200 ms	about 205 ms	Yes
Unikernel on QEMU	about 40 ms (reported)	200 ms	about 240 ms	Yes

The lesson is that for most IoT services the application’s own initialization (TLS handshakes, loading a model, reconnecting to a broker) dwarfs platform boot. The unikernel’s microsecond boot matters when you want to start workloads on demand per request or per event, not when you restart one long-lived service. If your service holds a 200 ms warm-up anyway, a 125 ms microVM costs you little.

Memory density on a small gateway (illustrative)

Take a gateway with 4 GiB of RAM, reserving 1 GiB for the host OS, the agent and page cache. That leaves 3,072 MiB for workloads. Assume each tenant needs a 64 MiB working set.

Containers: 3,072 / 64 gives 48 tenants before overhead. Per-container runtime overhead is small (the shim and runtime, assumed a few MiB), so about 40 to 45 in practice.
MicroVM with trimmed Linux guest: each guest needs its own kernel, page tables and a minimal userland. Assuming a 40 MiB guest baseline plus the 64 MiB working set plus the 5 MiB VMM figure, the cost is about 109 MiB each, so about 28 tenants. The guest baseline is an assumption; measure yours.
Unikernel: Unikraft reports 2 to 6 MB to boot its tested guests. Assume 8 MiB for the library OS and runtime heap overhead plus the 64 MiB working set plus the 5 MiB VMM figure, about 77 MiB each, so about 39 tenants.

The ordering (containers densest, unikernels close behind, general microVMs lowest) is the robust finding. The exact counts depend on assumptions you must replace. Note that the largest part of each tenant is its working set, so isolation overhead matters most when tenants are small, as with per-event functions or protocol adapters.

Figure 2: Where time and memory go when a workload starts. The container path skips a guest kernel; the microVM path pays for guest kernel and init; the unikernel path pays almost only for the VMM.

Figure 2 breaks the start-up path into stages. The point to take from it is where each option spends time: the container pays image and filesystem preparation, the microVM pays guest kernel boot and init, and the unikernel pays VMM start and a very short library-OS boot.

Counting attack surface honestly

“Attack surface” is not one number, but you can count three layers consistently.

Host kernel interface reachable from the workload. For a default container this is about 250 system calls plus every driver and filesystem reachable through them. For a Firecracker microVM, the workload talks to a guest kernel; the host-facing interface is the VMM’s KVM ioctls, a handful of virtio devices, and whatever the seccomp filter allows the VMM process to call. For a gVisor sandbox, it is the small set of host calls the userspace kernel itself makes.
Code inside the guest or container that an attacker can exploit. A container image with a shell, package manager and libc exposes tools for post-exploitation. A stock Linux guest does too. A unikernel with no shell and no second process offers fewer tools, but a single bug has full guest privilege.
Management plane. The runtime daemon, the orchestrator agent, the image registry credentials and the update channel. This layer is the one most often breached in practice and is rarely discussed in isolation comparisons.

For layer 1, I can state the container figure from Docker’s documentation and the Firecracker device list from its design doc; I cannot give a verified syscall count for the Firecracker VMM or for Unikraft, so I do not. A defensible approach is to measure your own: run strace -c -f or an eBPF tracer against the VMM process during a representative workload and count distinct system calls observed, then compare with the seccomp allowlist.

Figure 3: Three layers of attack surface. Moving from containers to microVMs to unikernels narrows the host-facing layer first, then the in-guest toolbox, but leaves the management plane unchanged.

Figure 3 draws the same three layers per option. Reading across, the microVM move shrinks layer 1 dramatically, the unikernel move shrinks layer 2, and neither touches layer 3. That is why a team that adopts microVMs and neglects its fleet-update channel can end up no safer than before.

Performance on the data path

Unikraft’s page reports Redis and nginx throughput 30 to 80 percent higher than in containers, 70 to 170 percent higher than Linux VMs, and 10 to 60 percent higher than native Linux on its test setup (single core; Redis with 30 connections, 100k requests and pipelining 16; nginx under wrk with 14 threads, 30 connections and a 612-byte page). The authors state configurations were not tuned beyond removing obvious bottlenecks and that the gap against native narrows to 0 to 50 percent without kernel page-table isolation. Treat these as the project’s own results under favourable, network-heavy microbenchmarks, not as a prediction for an MQTT bridge doing TLS and JSON on an Arm core.

Running It on a Real Edge Node: A Firecracker Walk-through

Abstract comparisons hide the operational work. A minimal Firecracker launch shows what a microVM asks of you, and why a unikernel changes the shape of that work. The commands below follow the structure of Firecracker’s documented REST API over a Unix socket; paths are placeholders and I have not executed this exact snippet on target hardware, so treat it as untested and check field names against the current API reference before use.

# 1. Start the VMM (in production, launch via the jailer instead)
rm -f /tmp/fc.sock
firecracker --api-sock /tmp/fc.sock &

# 2. Point the guest at a kernel and boot arguments
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/boot-source \
  -H 'Content-Type: application/json' \
  -d '{"kernel_image_path":"/images/vmlinux","boot_args":"console=ttyS0 reboot=k panic=1 pci=off"}'

# 3. Attach a root filesystem (read-only for an immutable guest)
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/drives/rootfs \
  -H 'Content-Type: application/json' \
  -d '{"drive_id":"rootfs","path_on_host":"/images/rootfs.ext4","is_root_device":true,"is_read_only":true}'

# 4. Size the machine: 1 vCPU, 64 MiB
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/machine-config \
  -H 'Content-Type: application/json' \
  -d '{"vcpu_count":1,"mem_size_mib":64}'

# 5. Boot
curl --unix-socket /tmp/fc.sock -X PUT http://localhost/actions \
  -H 'Content-Type: application/json' \
  -d '{"action_type":"InstanceStart"}'

Five calls give you a running guest, and each one is a decision. The kernel image is yours to build and patch: you own the guest kernel CVE stream. The root filesystem is yours to assemble. Networking requires a TAP device and host-side routing or NAT you configure separately, and as the design document notes, Firecracker does no traffic filtering, so egress policy belongs on the host.

For a unikernel the same launch collapses. The “kernel” and the application are one artifact, so steps 2 and 3 become a single image path, there is no root filesystem to patch and no package manager, and the guest has no shell to attach to. In exchange you lose the ability to exec into a misbehaving guest, so observability must be designed in: structured logs over the serial or vsock channel, health endpoints, and metrics exported from the application itself.

Control-plane considerations that decide real deployments

Image supply chain. Containers inherit a rich ecosystem for signing and scanning (OCI images, signature verification, SBOM generation). MicroVM guests are usually built from the same OCI layers converted to a block device, so the tooling carries over with extra steps. Unikernel images are built per application from source with the library OS pinned; reproducibility is excellent when the build is deterministic, but scanners that assume a package database see nothing to scan. Plan to generate an SBOM at build time rather than discover it later.

Updates and rollback. Because a unikernel image is small (Unikraft reports under 2 MB for its tested applications), a fleet-wide update over a constrained cellular link is cheap. Compare shipping a 60 to 200 MB container image layer set, a figure that is workload-dependent and which you should measure. Smaller images also make A/B partition schemes practical on flash-limited devices.

Device access. Edge workloads often need serial ports, fieldbus adapters, GPIO or a GPU or NPU. Containers pass devices through easily. MicroVMs can pass them through using VFIO or similar mechanisms, but Firecracker’s deliberately minimal device model does not emulate arbitrary hardware, which is why teams that need heavy device access look at Cloud Hypervisor or QEMU instead. Unikernels inherit this limit: if the library OS lacks a driver, you write one. This is the single most common reason an edge unikernel proof of concept stalls.

Orchestration. Kubernetes at the edge (k3s, KubeEdge, MicroShift) speaks container runtime interfaces. Kata Containers plugs microVMs into that world through a runtime class, which lets you mix runc pods for trusted system services and VM-isolated pods for third-party code on the same node. Unikernels have less orchestration integration; most deployments wrap them with a small custom launcher.

A decision flow

Figure 4: A decision flow for edge workloads, starting from the trust question and ending at a runtime choice.

Figure 4 encodes four questions in the order that eliminates options fastest. Ask first whether all code on the node is trusted and from one party. If yes, hardened containers are the pragmatic answer. If no, ask whether the hardware exposes KVM and enough RAM headroom. If not, you are limited to gVisor-style sandboxing or stricter containers plus physical separation. If KVM is available, ask whether the workload needs a general OS or heavy device access; if yes, choose microVMs. If it is a single, well-defined service you can rebuild per release, a unikernel on a minimal VMM gives the smallest footprint.

Decision matrix

Criterion	Hardened container	gVisor sandbox	MicroVM (Firecracker class)	Unikernel on a microVMM
Isolation boundary	Shared host kernel	Userspace kernel, shared host kernel	Hardware virtualization, own guest kernel	Hardware virtualization, no separate guest userspace
Needs KVM	No	No (supports non-KVM platforms)	Yes	Yes
Boot time (sourced figure)	Not verified; estimate tens of ms	No VM boot; no figure	125 ms target	Reported about 3 ms with VMM
Memory overhead	Lowest	Moderate	VMM 5 MiB or less plus guest kernel	2 to 6 MB guest reported plus VMM
Run arbitrary Linux software	Yes	Mostly	Yes	No, must be ported or rebuilt
Interactive debugging	Easy	Easy	Moderate	Hard, no shell
Device passthrough	Easy	Limited	Limited to moderate	Limited
Best fit	Single-tenant, trusted	Untrusted code on weak hardware	Multi-tenant gateways	Fixed-function, per-event services

Trade-offs, Gotchas, and What Goes Wrong

No KVM, no microVM. The most frequent surprise is that the target board does not expose hardware virtualization, or exposes it only under a vendor hypervisor you cannot replace. Check /dev/kvm early. Nested virtualization (a microVM inside a cloud VM that emulates the edge node in CI) behaves differently from bare metal and can mislead your boot-time measurements.

Boot time numbers do not transfer. The 125 ms and 3 ms figures come from specific kernels, hosts and configurations. An eMMC root filesystem, a slow SD card or a thermally throttled Arm core can multiply them. Measure on target hardware, with your kernel config and your init, and record the 95th and 99th percentile, not the median.

Shared-fate failures survive isolation. A VMM bug is a host bug, even behind seccomp and a jailer. Side channels through shared caches and speculative execution cross VM boundaries on shared hardware. Isolation reduces the probability and blast radius of compromise; it does not remove the need for patching the host kernel, the VMM and the microcode.

Unikernel single-privilege risk. With no user/kernel boundary, an exploitable memory-safety bug in the application gives the attacker everything in that guest, including any secrets it holds. Using memory-safe languages (Rust, Go) for the application and keeping secrets short-lived limits the damage. The guest is small, so the damage is contained to that guest, which is the entire point of the boundary.

Observability debt. Without a shell or standard tooling, teams under-instrument unikernels and then cannot diagnose field failures. Budget for log shipping, crash dump capture over vsock and remote health checks before the pilot, not after.

Ecosystem maturity. Container tooling is mature and well staffed. Unikernel projects are active but smaller, library coverage varies, and porting a service with unusual dependencies (dynamic plug-ins, fork-based workers, exotic libc features) may be a rewrite. I could not verify current production-adoption figures for edge unikernels this run, so I do not cite any; assume you will be an early adopter and plan support accordingly.

The management plane. Whatever you choose, the orchestration agent, registry credentials and update channel remain the likeliest compromise path. A hardware boundary around workloads does not protect a node whose agent accepts unsigned updates.

Practical Recommendations

Start from the trust model, not the technology. If every workload on the gateway is built and signed by one team, hardened containers with a restrictive seccomp profile, dropped capabilities, read-only filesystems and user namespaces remain the best cost-benefit option. Do not adopt virtualization for its own sake on a 1 GB device.

If the gateway hosts code from more than one party, or runs anything that executes untrusted input such as plug-ins or generated code, move those workloads behind a hardware boundary. On hardware with KVM, microVMs through Kata Containers or Firecracker-based launchers are the lowest-risk path because they run unmodified Linux software. Keep trusted system services as plain containers on the same node to preserve density.

Reserve unikernels for narrow, stable, high-value services where the image is rebuilt every release: a protocol adapter, a signing service, a telemetry forwarder. These benefit most from a tiny image, near-instant start and no shell. Pilot one service, measure on target hardware, and only then widen scope.

A short checklist:

Confirm /dev/kvm exists and works on every SKU in the fleet.
Run the Firecracker jailer, default seccomp and per-VM cgroups; never run the VMM as root without them.
Pin and patch guest kernels on a defined cadence; treat them as part of the fleet.
Measure p50, p95 and p99 start time and resident memory on target hardware with your own init and application.
Count host-facing syscalls of the VMM process with a tracer and compare against the seccomp allowlist.
Filter guest egress on the host; the VMM does not.
Build SBOMs at image build time and sign images, including unikernel artifacts.
Design logs, metrics and crash capture before removing the shell.
Keep a container fallback path for workloads the isolated runtime cannot host.

Frequently Asked Questions

Are unikernels more secure than containers?

Usually they present a smaller attack surface and a stronger boundary, because they run behind a hypervisor and contain no shell or unused services. But a unikernel has no internal privilege separation, so a bug in the application compromises the whole guest. Unikraft’s own documentation says reduced surface “does not eliminate all attack vectors.” They are stronger against host compromise, not stronger against bugs in your own application code.

Is a Firecracker microVM the same as a unikernel?

No. Firecracker is a virtual machine monitor that boots a guest kernel, normally Linux, from an image you supply. A unikernel is the guest: an application linked with a library OS into one bootable image. You can run a unikernel on Firecracker, and Unikraft’s documentation reports Firecracker boots among its test platforms, but they solve different layers of the problem.

How fast does Firecracker boot?

Firecracker’s specification targets 125 ms or less from the InstanceStart call to the guest’s init process, measured with a minimal kernel and root filesystem and the serial console disabled. Its VMM memory overhead target is 5 MiB or less. Those are targets under a stated configuration on AWS bare metal. Real boot time on an edge SoC depends on your kernel config, storage and init system, so measure it.

Yes. Containers are namespaced and resource-limited processes on the host kernel, filtered by seccomp and capabilities. Docker’s default seccomp profile disables around 44 of more than 300 system calls, so most of the kernel interface remains reachable. A kernel vulnerability can therefore let a compromised container affect the host and other containers, which is the core reason to use VM-based isolation for untrusted code.

Can I run these on a small ARM gateway?

Possibly, if the SoC and bootloader expose hardware virtualization and the device has enough RAM for a guest kernel per workload. Many do not, or expose it only through a vendor hypervisor. Verify /dev/kvm, test a minimal guest and measure memory. Where virtualization is missing, use hardened containers or a userspace-kernel sandbox such as gVisor, and consider physical separation for the most sensitive code.

When should I use Kata Containers instead of raw Firecracker?

Use Kata when you want microVM isolation but need to stay inside Kubernetes and the container ecosystem. It runs each pod in a lightweight VM using Firecracker, Cloud Hypervisor or QEMU underneath, so existing images and manifests keep working. Use a raw Firecracker launcher when you control the whole stack, need the fastest start and are willing to build networking and lifecycle tooling yourself.

Unikernels vs MicroVMs vs Containers for Edge IoT: Isolation, Boot Time and Attack Surface (2026)

Unikernels vs Containers vs MicroVMs for Edge IoT: Isolation, Boot Time and Attack Surface

Context and Background