HopOS · bare metal, in Rust
An operating system written in Rust around a small job: give an app memory, give it compute, connect it, and reclaim its resources when it finishes. No Linux underneath. One static binary is the OS, on ARM64 and RISC-V, from a small board to a many-core server.
HOP decides what runs where · meet the orchestrator →
one kernel, one orchestrator · Rust apps and Go apps side by side
The execution model
Give a compute job dedicated cores, including several cores for one app. Let explicitly trusted apps share a core cooperatively when that fits the workload. Each resident keeps its own hardware-enforced memory partition. There is no shell, no libc, no userland and no processes.
The kernel is mechanism only: it owns the cage, the switch, the storage and the clock. HOP, the orchestrator, is the first resident, an app with one privilege no other app has: the right to place, stop and replace apps. HOP owns the policy.
Claim the app’s memory and compute.
Stream the image into its own partition.
Do work; park the core when there is none.
Confirm the stop, then return ownership.
What it can do
01 / Compute
Give a busy app whole cores, or several cores for one SMP app. Put trusted, intermittent workloads together in a sharegroup on one core. Where a board is short on cores, HOP itself can share the OS core with the kernel. Every form uses the same lifecycle and keeps separate memory partitions.
02 / Updates
A running node replaces its kernel without a reboot. The apps, HOP, their connections through the switch, the NAT flows and the volumes stay; only the kernel changes. An outgoing TCP connection of an app runs on across the jump. A cold flip, for a kernel with a different switch code, stops the apps first and places them again.
03 / Rust
All state has exactly one owner, and that owner is a task: no mutexes, messages instead. The kernel tree denies unwrap, panic and todo through lints; every unsafe block carries its reason. Each layer is a crate, and the import direction is a build rule the gate enforces. Boot, vectors and the switch are the only assembly.
04 / Go compatibility
An app is one ELF that speaks the slot ABI: the same tail, control page, rings and call frames whichever language built it. A Go image from the TamaGo toolchain and a Rust image from the app library are placed, connected and stopped by the same job spec. HOP sees no difference. Both SDKs are maintained in the tree.
The first green v3 node on hardware was a Raspberry Pi 5 on 30 September 2026, including the first in-place kernel update on real hardware. Since then the Pi 4, the Radxa Zero 3E, the Orion O6N and the Mac mini M4 have repeated it with their apps and connections intact. Read the flip procedure →
One path for work
Each app has its own network stack on a node-internal LAN. The kernel’s switch routes between residents, publishes ports to the uplink and masquerades outbound traffic. The app’s system calls travel over the same path as its other traffic, one caller at a time.
The switch writes frames into the resident’s ring and rings its doorbell. A notification tells the resident to look; the ring holds the actual work. Between two apps on one node the switch moves frames from ring to ring, which is why app-to-app traffic on a Mac mini M4 reaches 6,380 MB/s.
The network device feeds this path through one interrupt: MSI-X on the Pi 5 and, via the GICv3 ITS, on the Orion O6N; a wired interrupt on the Radxa Zero 3E; virtio on QEMU. Boards whose NIC offers no usable line, such as the Pi 4, the Altra and the M4, poll deliberately, with the reason on the console.
Follow the boards and their interrupts → · Read the storage barrier contract →
Measured on hardware
No VM, no WASM, no interpreter, no container: an app runs natively on its own cores at full clock speed, and the kernel is one hop away over a ring. The numbers above are single runs on real boards; the measurements page keeps the spread per board, the command and the console marker for each.
App to app: one app pulls 800 MiB from another on the same Mac mini M4 through the kernel’s switch, on a performance core, measured on 1 October 2026 at 6,379 and 6,383 MB/s; 40 GiB sustained at 2,813 MB/s. Storage: the raw NVMe benchmark at boot on the M4’s Apple NVMe with 1 MiB commands over 16 MiB wrote 4,952 and read 1,925 MB/s; through the full app storage path, 256 MiB in 1 MiB calls, an app wrote 1,270 and read 1,690 MB/s. Random 4 KiB reads with sixteen commands in flight reached 175,055 per second raw in the kernel; through the app path, four apps together read 25,000 and eight apps 36,000 blocks per second, one call per app at a time. Smaller boards: app to app 407–435 MB/s on a Raspberry Pi 4 and 257–262 MB/s on a Radxa Zero 3E at its firmware clock of 816 MHz. These are short completed-I/O measurements; sustained throughput and power-loss durability were not measured.
Measurements and conditions →One OS, two ways to use it
one machine
HOP is built into the node as a standalone leader. Post a job spec to its API, and the kernel places the app, publishes its port and keeps it running. HOP keeps its state on the node’s own storage and reads it back after a restart.
a fleet
Name a lock in the node config, and HopOS nodes and Linux or macOS agents form one cluster: one lease on a hoplockserver or in an S3 bucket, one committed cluster state next to it, and whichever node holds the lease leads.
Software running on the kernel
An app is one ELF that speaks the slot ABI. A Rust app links against a small app library with its own network stack; a Go app builds with the TamaGo toolchain against the Go SDK. Both produce the same kind of image, placed by the same job spec.
In the tree
A welcome page, a network bench, a board doctor that runs the performance tests, a display app for the screen, a decoder for the hardware codec, and a Cloudflare tunnel client whose loaded image is 530 kB. Browse the apps →
Go apps
A Go home controller with device integrations, plus the Go builds of welcome, vitals and cloudflared, run through the same ABI as the Rust apps. Build a Go app for v3 →
Cluster services
hoplb, hopdns, hopprom, hoplockserver and the HOP GUI are Rust apps at v3.0.0. They run on a node or on a host next to HOP. See the HOP workflow →
Storage
Replica links native SQLite into a no_std app over the kernel’s file calls, with a confirmed sync barrier. The full persistence proof, write, restart, recover and repair, takes about 0.2 s on the M4. Read the barrier contract →
A display, a browser and an emulator run as apps too; windows can come from different nodes. See the desktop →
Where it runs
Apps are built once per architecture, not once per board. The kernel binary picks exactly one board, which supplies boot and device wiring. On UEFI machines its own EFI stub takes over from the firmware, and on the Mac mini M4 it boots from iBoot — no GRUB in between.
Try it
The HopOS Imager downloads the newest signed release, writes and verifies the card, keeps config during updates and finds the node on your network.
$ git clone https://github.com/xinix00/HopOS $ cd HopOS $ sh image/qemu-run.sh HOP_UP
Each file is the complete medium. GUI boots with the screen, Headless contains no graphics code, Media adds the hardware codec. The links resolve to the newest signed release; v3 images for every board build from the repository with one script each, and rust-toolchain.toml pins the compiler.