Run Every Tenant in Its Own Kernel
Built for SaaS and database cloud providers who run customer workloads on shared nodes. Multikernel gives each tenant an independent kernel with dedicated cores inside the cloud VMs you already rent: VM-grade isolation at container density, with no nested virtualization and no bare-metal requirement.
The Multi-Tenant Compute Tradeoff
Providers running tenant workloads on shared infrastructure currently choose between three compromises.
Containers
High density, but every tenant on the node shares one kernel. Cross-tenant interference appears in tail latency, and kernel-level vulnerabilities expose all tenants at once.
MicroVMs
Strong isolation, but they require bare-metal instances or nested virtualization. Fleet cost rises and instance selection narrows.
One VM Per Tenant
Clean isolation with poor economics: low density, slow provisioning, and unsustainable cost for small and serverless tiers.
Kernel-Per-Tenant on Shared Nodes
Multikernel partitions each node into independent Linux kernels: one per tenant, plus a device kernel that owns physical I/O. Tenants share hardware, not a kernel.
Each tenant runs on its own kernel with dedicated cores. Tenants share hardware, not a kernel.
Tail Latency by Architecture
Dedicated cores, a private page cache, and no cross-tenant interrupts or kernel lock contention. p99 query latency is protected structurally rather than by cgroup tuning.
Isolation for Untrusted Code
User-defined functions, extensions, and customer code run inside the tenant's own kernel. A compromise is contained by a kernel boundary, not a container boundary.
Per-Tenant Network Isolation
Each tenant kernel has its own network device backed by dedicated descriptor rings and hardware queues. Packet frames never cross tenant boundaries; only descriptors move between kernels.
Utilization Without Static Partitions
Kernel partitions are not fixed reservations. CPU cores and memory move between tenant kernels at runtime through standard Linux hotplug interfaces, so node utilization and capacity planning follow your economics, without rebooting the node or the tenants that stay in place.
Fleet Operations Under Tenant SLAs
The operational properties that matter when thousands of nodes carry customer commitments.
Kernel Patching Without Downtime
LiveUpdate applies kernel security patches across the fleet without rebooting nodes or interrupting tenant databases. CVE response no longer competes with customer SLAs.
Sub-Second Kernel Failover
A kernel crash fails over to a standby in under a second instead of taking down every tenant on the node for a reboot cycle.
Fast Tenant Provisioning
Tenant kernels boot directly into Docker images via kexec, with no full OS initialization per instance. Suitable for dedicated tiers and scale-to-zero serverless compute alike.
From Evaluation to Production
A three-step engagement model, integrated with the orchestration you already run.
Evaluation
Proof of concept on your dedicated-compute tier: kernel-per-tenant on your instance types, measured against your current isolation approach on your workloads.
Integration
Kernel lifecycle integrated under your existing orchestration and provisioning flow, with our engineers working alongside your platform team.
Production
Fleet rollout on a per-node subscription: validated builds, CVE stream with LiveUpdate images, and SLA-backed engineering support.