← H2 Labs

Also from H2 Labs

What we build
and run.

Our main work is cybersecurity for infrastructure. Alongside it we build our own tools where the usual ones fall short, and write up what we learn. Each entry says what it does, what runs today and where it stands.

Security tools

The machine, who signs in to it, what runs on it, how it is reached, and what an agent on it may touch.

purpose-built Linux

UHT

Immutable Linux, prepared for the job.

UHT is our way of setting up Fedora’s immutable Linux. The system is a signed, read-only image that changes only as a whole: an update applies completely or not at all, and the version before it stays in the boot menu.

On that base we set each machine to what its role needs, and name what each setting costs. The kernel’s strictest lockdown also stops eBPF monitoring, so a workstation runs it, and a host we watch with eBPF runs the level below.

Fig. 1 UHT: one foundation, prepared for different jobs

What runs today

SELinux enforcing, kernel lockdown with hardening boot options, and encrypted disks.
sudo with a touch of a hardware security key, the password kept as a fallback; SSH keys held on the key itself.
Hourly snapshots of home folders, and a daily encrypted backup to a mirrored pair of drives, with a phone alert when a run fails.
Apps in Flatpak sandboxes, command-line tools in containers, untrusted code in virtual machines.
uht check compares a machine with the documented setup and prints the fix for each gap.

Status

Runs on our own machines, each one prepared by hand.

UHT in detail

identity and access

Identity Core

One key for your apps, your Linux logins and sudo.

Identity Core is our own single sign-on, written from scratch in Rust. People sign in with a passkey or a security key; their accounts have no password to phish or reset. Web applications sign people in through OpenID Connect, and Identity Core asks the person’s consent before an application learns who they are, unless the organisation marks it as one of its own.

Linux uses the same identity. Each machine receives a signed set of rules: who may log in, and the exact commands, arguments and accounts they may use with sudo. Identity Core’s sudo plugin checks the permission again on every command. We test this in virtual machines with software keys, and have confirmed it on our own machines with physical keys.

Fig. 2 Identity Core: one key, through one system, to apps, Linux and sudo

What runs today

id.h2.io signs our team in to our own apps and to two of our Linux machines; a third is enrolled.
Three servers hold the sign-in, and two must agree on each change; with each one stopped in turn, the sign-in page stayed up.
Accounts by invitation only, with a one-use token that expires after 15 minutes.
Several keys per person; adding or removing one takes a touch of a key you already hold.
A laptop still accepts its owner’s key without a network, for a set time, under a signed lease.

Status

Runs our own sign-in at id.h2.io.

Identity Core in detail

evidence and response

Runtime Assurance

Know what runs. Control what changes.

A clean scan cannot prove that a machine is uncompromised. Runtime Assurance works from specific checks: signed probes inspect a system without changing it, and what they find becomes evidence a person can act on.

Each part has one job. Identity Core establishes who is acting, and policy decides which target and operation they may approve. A local enforcer applies one scoped change, then checks its effect.

Fig. 3 Runtime Assurance: evidence, one approval, one scoped change, its effect checked

What the lab exercises

Signed probes run isolated: writes and network access are refused, resource limits hold, and a tampered probe is rejected.
Approvals in the browser through Identity Core, each used once, that block and restore narrowly scoped traffic.
File changes detected, and actions without permission refused.
Each result checked on the receiving side, independently of the action.

Status

Tested in an isolated Linux lab and a disposable container, with a virtual passkey.

Runtime Assurance in detail

remote access

askd

Reach your machines with no open ports.

Machines dial out to a relay and wait, so nothing on them listens and there is no port to find. The relay stays silent too, until one signed packet asks for access.

The relay is blind: it brokers bytes it cannot read, and SSH runs end to end on top. Every access event is sealed to an offline auditor’s key before it is written, so the relay records who reached what and cannot read its own log back.

Fig. 4 askd: the host dials out to a blind relay and has no inbound port

What runs today

A single-packet knock, the blind relay, and credentials signed by a certificate authority.
Several paths at once, with sessions that resume.
A sealed audit ledger, with live deny, drain and cut controls at the relay.
The certificate authority’s key on a hardware token: 7 of 7 end-to-end tests pass on a YubiKey and on a Nitrokey HSM.
One static binary well under 1 MB, running as an unprivileged user.

Status

In use by its author; the source is not published. The byte-exact specification and its test vectors are public under Apache-2.0.

askd in detail

confinement

Isolation stack

Fourteen Linux isolation mechanisms, each one a working demo, from the hardware to the runtime.

Isolation in Linux spans five layers: hardware, hypervisor, kernel primitives, kernel policy and runtime. We run each mechanism as its own demo on a stock Linux machine, with no Kubernetes and no cloud account.

Some of them confine our own agents. Our coding agents run in rootless containers with limits on processes, CPU and memory, and see only our code folder. Zoya can run each shell command it starts under Landlock, or under bubblewrap where Landlock is missing; if Landlock cannot be applied, the command does not run.

Fig. 5 Isolation stack: layers that compose around an agent

What runs today

Namespaces, cgroups v2, capabilities, Landlock with seccomp, and SELinux or AppArmor.
An eBPF socket filter, a time namespace, seccomp user notification, and a network namespace with a virtual Ethernet pair.
WasmEdge, CRIU, gVisor, Firecracker, and confidential computing: a real attestation report on Intel TDX or AMD SEV-SNP hardware, a simulation elsewhere.
All they need is Linux 5.15 and Zig 0.13, or newer; KVM only for Firecracker.

Status

Demonstrated on a stock Linux machine, and written up on labs.h2.io.

The 14 demos

Operations

The person on call when something breaks, and the move from Windows to Linux.

on call

H2 Pager

The pager, after Opsgenie.

Atlassian switches Opsgenie off on 5 April 2027. H2 Pager does the same job: when something breaks, it pages the person on call at the highest priority, which can ring through Do Not Disturb, and keeps escalating until someone answers.

Alerts come in from ServiceNow, monitoring tools, a SIEM or email, and every change goes back out to ServiceNow, chat and signed webhooks. Each alert waits in a SQLite inbox until it has been handled, so nothing is lost if the pager restarts, and a repeat of an open alert pages nobody new.

Fig. 6 H2 Pager: from any tool to the phone of the person on call

What runs today

Push alarms through ntfy, on Android and iPhone.
Opsgenie’s alert and heartbeat API, so a tool changes only the address it sends to.
A read-only import of people, teams, rotas, overrides and escalation rules from Opsgenie; nothing in Opsgenie changes.
A health check that an outside dead-man’s switch can hold.
Names, rotas and alert history stay yours, to take with you.

Status

One instance on our own server, in shadow mode: it works out who it would page and records the pages without sending them.

H2 Pager in detail

migration

Windows to Linux

Keep good hardware working on a maintained system.

Windows 10’s ordinary support ended on 14 October 2025, yet the machines that run it still work. A maintained Linux system can keep useful hardware in service, and puts more control over your tools, your data and your spending in your hands.

We have used Linux every day for more than 25 years, and we run our business on it. Our analysis sets out the options for individuals and for companies, the European initiatives behind the renewed interest, and what a trial on real work should measure.

Fig. 7 Windows to Linux: the same hardware on a maintained system, and what a trial measures

What it covers

Two tracks: one for individuals, one for companies from small business to fleet.
UHT, our hardened immutable Fedora, and experience with openSUSE Aeon, Ubuntu and NixOS.
A trial measured on daily tasks and real documents, on recovery from a failed update or a lost laptop, and on the whole cost, including any Windows services kept.
StatCounter’s figures for Linux on the desktop, read for what they measure: a share of web traffic.

Status

An analysis published on h2.io on 7 October 2026.

Read the analysis

Platform and agents

The platform this site runs on, and our own agent.

app platform

Servo

The self-hosted app platform this site runs on: every app a folder, no build step.

Servo serves each app straight from its folder: every folder is an app, reachable at its own name. There is no build step and no bundler, and a configuration file is optional.

This site is one Servo app: its static pages and the contact form’s backend, together. Each page it serves gets the shared light and dark theme, unless the app opts out.

Fig. 8 Servo: every folder an app, no build step

What runs today

h2.io and the apps at apps.h2.io run on it.
Static sites and apps with server code of their own, side by side.
Sign-in to its apps through Identity Core.

Status

Runs this site and our own apps.

personal agent

Zoya

A sovereign personal agent: one Zig binary, a memory that never resets, channels we control.

Zoya is an agent runtime in one static binary, hosted on its owner’s hardware. It drives a language model, keeps its own memory, reaches the world through tools, and answers on the channels its owner chooses.

It speaks SimpleX, its own web and mobile clients, a command line, an HTTP API and MCP. It once took messages from Telegram, Discord and WhatsApp; we removed those listeners on sovereignty grounds.

Fig. 9 Zoya: channels we own, one Zig binary, a memory that never resets

What runs today

One executable of about 140 MB, with SQLite compiled in.
About 44,000 lines of Zig in some 60 modules.
MCP both ways: it uses other servers’ tools and offers more than 60 of its own.
Sensitive tools wait for a person’s approval; every sender has a budget and a rate limit.
Its shell commands can run under Landlock or bubblewrap, and its secrets sit in an encrypted vault.

Status

Built and run by H2 Labs, for our own use.

Start with a free inventory

Most of the work starts with knowing what runs. We read it from your systems with your permission, then give you a 45-minute readout with one real finding and a straight answer on whether you need us.

Get a free inventory How we start

FreeInventory. What runs on your systems and what is exposed, read on the dates you agree. You keep the results.
€9,500Assessment. Priorities, risks, a plan and a quote, for a fixed fee, excluding VAT, credited against the work that follows.
MonthlyOngoing protection. From €2,400 a month: we apply your updates, watch your systems, record every action and send a short report each month. The three plans.