The hub handles your code and your service’s traffic in memory while it routes and serves it. A hub you run yourself keeps that processing inside infrastructure you control.
Security and privacy
How each link is protected.
Omnira is a hub, the devices that run your services inside a vault in memory, a gateway in front of the hub, and a data broker between the hub and your storage. This page says what protects each link, what runs in memory, what rests sealed, and what is planned but not yet done. It describes the shipped code; nothing here is a promise about hardware or a certification.
Reviewed against the code on 11 October 2026. Report a vulnerability to security@omnira.dev.
- Free account
- No card
- A code by e-mail — no password
Link by link
The links, one by one
Each card says what travels, how it is protected, what the other side proves, and what is planned.
Your browser or client → the hub
What travels. Your request and the service’s answer.
How it is protected. HTTPS, TLS 1.2 or newer, at the gateway. Certificates are issued automatically, or supplied by whoever runs a hub. The gateway relays bytes to the hub it is attached to and keeps no content.
What the other side proves. The gateway’s certificate proves the name you asked for. No port is opened on any device for this traffic: every device connects out to its hub.
Planned. Nothing on this link is planned; it is the ordinary web.
A device’s vault ↔ the hub
What travels. The hub’s instructions, your service’s requests and answers, the device’s heartbeat.
How it is protected. One outbound connection from the device, TLS with certificate verification against the system roots. A device never dials a public address in the clear.
What the other side proves. The device proves who it is on every connection: it signs the hub’s fresh challenge with a key only it holds (Ed25519). The hub’s trusted signing keys, its revocations and its enforcement switch come from a policy whose generation can only move forward; a stale or missing policy denies rather than widens. A device that connects before the policy is loaded gets no verdict and is asked to reconnect. The device’s own software updates are checked by digest and can never roll back below a floor.
Planned. Signed software updates, and a hub that proves itself to the device inside the connection as well.
Hub ↔ hub
What travels. No customer traffic. Hubs do not pass your requests to each other.
How it is protected. One hub holds a short-lived lease recorded in the data broker’s store; the gateway attaches to the holder; a standby is a standby. Every device keeps its own encrypted connection to each hub it belongs to.
What the other side proves. The lease is taken with a compare-and-swap, so two hubs cannot both believe they hold it.
Planned. Nothing on this link; a sovereign hub is a single hub by construction.
The hub ↔ the data broker ↔ your storage
What travels. Your published code, your service’s settings, the records of what is where.
How it is protected. The hub never talks to cloud storage itself; the data broker does, with its own credential, over TLS. Published code and settings rest sealed with ChaCha20-Poly1305 in the broker’s store. A device’s own state rests sealed with XChaCha20-Poly1305 under a key the running app holds and never writes down. Nothing of a job is written to a device’s disk.
What the other side proves. Each caller proves itself to the broker with its own credential; devices hold no credential for your storage.
Planned. Customer-held keys for all workload data, so that even the broker’s operator cannot open them.
In memory
Inside a device
Code arrives in memory and runs from memory.
A service’s bytes are loaded into a memory file and executed from there. On supported, verified paths, 0 bytes of your code or data are written to or read from the device’s disk.
One process per service, in its own process group.
Stopping a service stops everything it started. One service cannot reach another’s memory, and the runner itself is a separate process.
A sandbox the device computes, never the service.
The profile comes from the device’s own platform and mode: file-size and memory limits, a confined scratch area, platform secrets scrubbed from the service’s environment, and outbound traffic through a shim where the platform enforces it. An uploaded artifact cannot choose a weaker profile.
The device’s own logs carry no job data.
Your service’s logs and results stream back to your own storage. The runner’s log records what ran, never what it processed.
Honest limits.
Linux filesystem isolation is in its second increment; macOS has no reliable address-space cap, so a memory-hungry service is bounded there by the operating system rather than by the sandbox. The machine’s operating system and its administrator remain trusted for data in use.
Isolation
A misbehaving service: the poison pill
A request that crashes a service crashes that one process, and nothing else.
The crash is contained.
The service’s process dies; the device notices and starts it again from memory for the next request. Other services on the device, the runner and the device itself never notice.
A service that keeps crashing is held.
After a few crashes in a short time the device holds the service for a while, longer each time it keeps happening. Visitors are told plainly that the service has a serious bug and keeps crashing; its owner is pointed at the crash record. The hub re-routes reads to another device; it never retries a write on your behalf.
Planned: fleet-wide quarantine and removal.
A service that keeps poisoning devices is taken out of dispatch across the fleet and its owner notified, with the digest of the requests that came just before each crash. A service that violates the platform’s rules is removed the same way.
Admission
Devices the platform does not trust
Today a device joins the fleet only with a proven identity and the capabilities the device itself probes; a device that cannot prove who it is serves nothing once enforcement is on. Planned: the platform refuses hardware and kernel classes it marks as vulnerable, written as configuration rather than shipped as code, so the list can change the day a flaw is known.
Plainly
What we do not claim
The machine’s operating system and its administrator remain trusted for data in use. Execution that is attested to exclude the host is planned, not shipped.
Service settings and secrets are encrypted with keys the hub manages. Customer-held keys for all workload data are planned, not yet available.
No disk promise is unconditional: it holds on supported, verified paths, and the proof page lets you check it on a machine you have.
Evidence
For reviewers
The designs behind this page are numbered in our engineering record: fleet admission and workload authority (16.7.398), request isolation and the poison pill (16.7.400), the device sandbox (16.7.132), and the data taxonomy that decides what may touch a disk (16.7.191). The proof page runs the traceless check on a machine you have. A live service exists only to crash on demand so you can see the containment yourself.
Prove it on a machine The query of death Report a vulnerability
Questions
What reviewers ask first
Is the connection from a device to the hub mutually authenticated?
The device proves itself with a signature on every connection; the hub proves itself with a certificate the device verifies. A second proof of the hub inside the connection is planned.
Can the hub’s operator read my data?
The hub handles your traffic in memory while it routes it, so a hub’s operator is trusted for data in use; a hub you run yourself keeps that inside your own infrastructure. We do not describe the hub as blind.
Where are the keys?
Service settings are sealed under keys the hub manages; a device’s own state is sealed under a key the running app holds and never writes down. Keys you hold yourself, for all workload data, are planned.
What happens to a request that crashes my service?
It gets an error; the service restarts from memory for the next request; if it keeps crashing the device holds it and tells visitors so. Nothing else on the device is affected.
See the containment yourself.
Create your account in about two minutes — free, no card needed — publish a service, and read the proof page on a machine you have.
- Free account
- No card
- A code by e-mail — no password
Already have an account? Sign in