Every workload, its own kernel. Nothing else.
Tessera is a unikernel manager. Each function ships as a single-purpose VM (your code and a minimal kernel fused into one image) and runs in its own address space, on the hypervisor, with no operating system underneath it.
No syscall boundary. No context switches. No shell, no init, no package manager. Nothing but the bytes the workload needs to run.
- Cold boot p50
- 1.2 ms
- Image size
- ~2 MB
- Context switches
- 0
- Address spaces
- one per workload
When this matters
If your workloads share a kernel, they are sharing more than that.
Tessera is for teams running untrusted, ephemeral, or multi-tenant code, and for anyone who has read the cold-start line on a P95 chart and wished it were different.
You run code you did not write
LLM-generated functions. Customer plugins. Agents that arrive with their own deps. A shared kernel under all of it is one kernel bug away from a multi-tenant breach.
Cold starts tax every request
A container takes hundreds of milliseconds to come up: pull, unpack, init, network. By the time it answers, the user has retried. The fleet is paying for warmth nobody is using.
Your runtime ships with a userland it does not need
Your function does one thing. The image carries a shell, a libc, a package manager, an init system, and a kernel built for a laptop. Every byte is attack surface someone signed for.
Compliance keeps asking what is on the box
A regulator wants the SBOM. The team wants the patch list. The container has 412 packages, and 38 of them have CVEs nobody has gotten to yet. The audit is overdue.
How it works
A unikernel per workload, scheduled like containers, isolated like VMs.
Tessera takes the isolation guarantee of a hypervisor and the ergonomics of a function runtime, without the operating system that usually sits between them.
Pack the workload
Your function compiles into a unikernel image: your code, a minimal libos, and the device drivers it actually needs. No shell, no init, no userland. The image is tens of kilobytes to a few megabytes.
Boot on the hypervisor
Tessera schedules each unikernel directly on the hypervisor. There is no host OS in the path. Boot is microseconds-to-low-milliseconds, because there is almost nothing to boot.
Run in one address space
Inside the VM, kernel and application share an address space. There is no syscall boundary, no user/kernel context switch. Function calls all the way down. Faster, smaller, fewer corners for an attacker.
Snapshot, fork, retire
Warm pools serve cold paths. Tessera forks new instances from a hot snapshot in microseconds, runs them, and reaps them when idle. Pages zeroed, image gone, no residue between tenants.
What ships
Smaller surface. Faster boots. Hard isolation by construction.
Three things drop into place the day Tessera takes over the runtime.
- 01
A runtime with no operating system underneath
Each workload is its own kernel: the smallest one that runs your code. No shared libc to exploit, no host kernel to escape into, no neighbour with a noisy sidecar. The blast radius is one VM.
- 02
Cold starts measured in milliseconds
Single address space, no userland to bring up, fork from a warm snapshot. Tessera serves the first request the way containers serve the thousandth, without the keep-warm fleet you were paying for.
- 03
A fleet view that fits on one screen
Image hash, memory, boot time, and lifetime, per VM, per tenant. SBOM is the image manifest. No agent to install, no sidecar to operate, no host metrics to correlate against.
Fleet · last 60 seconds2,184 VMs0 ctx switches1.4 ms boot p50auth-jwt
↳ forked from hot pool
unik:0x4a · 1.8 MB0.9 msimg-thumb
unik:0x91 · 2.4 MB1.1 mspy-sandbox
↳ untrusted code · isolated VM
unik:0xc7 · 4.2 MB1.7 mspdf-extract
unik:0x6e · 5.6 MB2.0 ms
Why Tessera
The cheapest layer is the one you do not ship.
A unikernel is the operating system you would build if you only had one program to run. Tessera is what that looks like as a fleet.
01
It removes the layer most attacks aim at.
No shared kernel, no userland, no syscall boundary to abuse. The thing an attacker usually pivots through is not in the image. The image is one address space, one purpose, one workload.
02
It runs faster because it does less.
No context switch tax, no scheduler walking between user and kernel, no init pulling in a hundred things you do not call. Function calls instead of syscalls, every time.
What Tessera isn't
Three things people assume, and the actual answer.
The category overlaps three others. Here is what makes Tessera structurally different.
Not a container runtime
Containers share a host kernel. Tessera does not have a host kernel. Each workload is the kernel: fused with its application, scheduled on the hypervisor, isolated by hardware.
Not a sandbox SDK
There is no in-process jail to escape. Untrusted code runs in its own VM, on its own pages, with its own MMU. Sandboxing is a side effect of the architecture, not a library you call.
Not a heavier microVM
A microVM still runs Linux. Tessera ships the function and a libos. No userland, no shell, no package surface to inventory. The image is what executes; nothing extra came along for the ride.
Common questions
What teams ask before they put it in the runtime path.
01Do we have to rewrite our code?
No. Tessera ships language runtimes (Node, Python, Go, JVM, Rust, WASM) packaged as unikernel base images. You bring a function or a binary; the manager fuses it with the libos and registers the image. The toolchain is a build step, not a project.
02How is this different from Firecracker or microVMs?
Firecracker boots a Linux kernel inside the VM. Tessera does not. Each workload is its own kernel, with no userland, no shell, and no init. The result is a smaller image, a smaller surface, and a faster cold start, for the same isolation guarantee.
03What about syscalls and devices?
There is no syscall boundary inside a unikernel. The libos is linked into your binary and called as a library. The hypervisor exposes virtio devices for network and storage; Tessera handles the wiring so workloads talk to the outside world like a normal service.
04Where does it run?
Hosted on bare metal in our regions, or BYOC inside your data centre or VPC. Tessera needs a hypervisor (KVM or equivalent) and is otherwise self-contained. No Kubernetes, no host distro, no agent to maintain.
05Is sandboxing the point?
Sandboxing is a property, not the pitch. You get it because each workload is its own VM with its own kernel. The reasons to use Tessera are speed, footprint, and a runtime that does only what your code needs.
Pricing
Pay for VM-seconds, not host fleets.
Idle pools are free. Booted unikernels are billed by the millisecond. The incentive sits on the right side.
- One workspace · all base images
- Hot-pool snapshots + scheduler
- Direct line to the engineering team
- Pricing fixed at beta rate after launch
- Unlimited workloads and tenants
- Per-tenant isolation by construction
- Image registry · SBOM exports
- SOC2-ready data handling
- Email + Slack support
- Self-hosted on KVM bare metal
- Per-tenant KMS keys (BYOK)
- SSO, SAML, SCIM
- Dedicated solutions engineer
- Procurement-friendly contracts
Plan 01
Pilot
Free · 90 days
For closed-beta partners
Run one workload type on Tessera in front of real traffic. Co-built migration, weekly check-ins, and pricing locked in for the first year.
Plan 02
Team
From $499/mo
For shipping product teams
Hosted, multi-region, full feature set. Usage-based billing on VM-seconds. Idle pools are free until they boot.
Plan 03
Enterprise
Custom
BYOC hypervisor
Single-tenant deployment on your bare metal or VPC. Air-gap supported, dedicated SRE, custom retention and audit.
§ 03 · Engagement intake
01 / Start a brief
Talk to the people who’ll do the work.
We staff small and senior, scope by phase, and end on a written deliverable. We don’t sell decks or hours.
If we’re not the right team for the job, we say so on the first call. The bar is production, not pitch.
02 / Where to find us
Montreal, Quebec
Satellite office- Lat / Lng
- 45.5089°N · 73.5542°W
- Local
- —:— EST · UTC−05