Tessera/A product from GroupLabsUnikernel manager

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.

tessera · schedulerLive
hypervisor
ctx 0boot p50 1.2 ms
unik:0x4a
auth-jwt
1.8Mspawn
unik:0x91
img-thumb
2.4M
unik:0x12
sql-eval
3.1M
unik:0xc7
py-sandbox
4.2M
unik:0x33
rate-limit
0.9M
unik:0x6e
pdf-extract
5.6M
one addr space · per tile
cold spawn · hot snapshot
Unikernel fleet6 VMs · boot 1.2 ms
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.

    01

    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.

    02

    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.

    03

    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.

    04

    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.

    01Step

    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.

    02Step

    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.

    03Step

    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.

    04Step

    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 seconds
    2,184 VMs0 ctx switches1.4 ms boot p50
    • auth-jwt

      forked from hot pool

      unik:0x4a · 1.8 MB
      0.9 ms
    • img-thumb

      unik:0x91 · 2.4 MB
      1.1 ms
    • py-sandbox

      untrusted code · isolated VM

      unik:0xc7 · 4.2 MB
      1.7 ms
    • pdf-extract

      unik:0x6e · 5.6 MB
      2.0 ms
tessera · schedulerLive
hypervisor
ctx 0boot p50 1.2 ms
unik:0x4a
auth-jwt
1.8Mspawn
unik:0x91
img-thumb
2.4M
unik:0x12
sql-eval
3.1M
unik:0xc7
py-sandbox
4.2M
unik:0x33
rate-limit
0.9M
unik:0x6e
pdf-extract
5.6M
one addr space · per tile
cold spawn · hot snapshot
Unikernel fleet6 VMs · boot 1.2 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.

    01

    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.

    02

    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.

    03

    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.

    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.

    • One workspace · all base images
    • Hot-pool snapshots + scheduler
    • Direct line to the engineering team
    • Pricing fixed at beta rate after launch
    Recommended

    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.

    • Unlimited workloads and tenants
    • Per-tenant isolation by construction
    • Image registry · SBOM exports
    • SOC2-ready data handling
    • Email + Slack support

    Plan 03

    Enterprise

    Custom

    BYOC hypervisor

    Single-tenant deployment on your bare metal or VPC. Air-gap supported, dedicated SRE, custom retention and audit.

    • Self-hosted on KVM bare metal
    • Per-tenant KMS keys (BYOK)
    • SSO, SAML, SCIM
    • Dedicated solutions engineer
    • Procurement-friendly contracts

§ 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.

team@grouplabs.ca
Compose a brief30 min · intro
WGS84YYC / YUL
CalgaryYYC
51.05°N · 114.07°W
MontrealYUL
45.51°N · 73.55°W
Δ 3,020 km

02 / Where to find us

01

Calgary, Alberta

Studio HQ
+1 (587) 700-9968
Lat / Lng
51.0486°N · 114.0708°W
Local
—:— MST · UTC−07
02

Montreal, Quebec

Satellite office
+1 (825) 365-9891
Lat / Lng
45.5089°N · 73.5542°W
Local
—:— EST · UTC−05