HopOS · the Go-only OS
HopOS boots directly on ARM and RISC-V hardware. No Linux, no VM and no container layer. It turns a board into a small, stateless application node where each app gets physical cores and hardware-fenced memory.
HOP decides what runs where · meet the orchestrator →
no Linux · no containers · no shared kernel
What it is
Compile a Go service for HopOS and hand HOP a signed image plus a small job spec. HopOS downloads it, gives it cores and memory, connects it to the network and keeps it inside that boundary.
That narrow job is the point. There are no users, packages, shell services, container daemons or local state to manage.
Compile your Go app for arm64 or riscv64.
HOP sends the job to a matching node.
HopOS assigns cores, memory and network access.
The app talks through ten small OS operations.
Why it exists
A conventional node already trusts a complex bootloader before it starts a ~30-million-line Linux kernel — then adds systemd, libc and a container runtime. AI makes large patch rounds easier to produce; it does not make that surface smaller. HopOS includes its own boot path; a complete node is about 11,300 lines.
a smaller bug surface
Lean contains the network stack, TLS, HTTP, S3 and ELF support in one readable Go module. It can be the only library dependency of a HopOS app; it does not have to be — ordinary Go packages remain your choice.
no dependency pile
Apps do not share a kernel or an address space. HopOS gives each app cores and memory, then uses the processor’s own translation and protection hardware to make everything outside that partition unreachable.
hardware, not policy
HopOS owns the privilege level above the apps: EL2 on ARM and machine mode on RISC-V. It loads an app into a memory partition, asks the processor to enforce that partition, and only then starts the app at the lower privilege level.
The node streams the signed app image into its assigned partition. Address translation lets every slot use the same link address, so one artifact per architecture can run in any slot.
ARM uses a stage-2 page table with its own VMID. RISC-V uses a PMP whitelist for the boundary and an Sv39 page table for relocation. If HopOS cannot establish the cage, it does not start the app.
The app talks to HopOS through a control page and two rings. The node programs network and storage devices; an app cannot invent a syscall or point DMA outside its cage.
On ARM, HopOS revokes the stage-2 mapping and parks the core. On RISC-V, it resets the hart. The boundary belongs to the hardware, so stopping one slot does not require cooperation from its app.
| ARM | RISC-V | |
|---|---|---|
| HopOS owns | EL2 | machine mode |
| app runs in | EL1 | supervisor mode |
| memory boundary | stage-2 table + VMID | PMP whitelist |
| relocation | the same stage-2 table | Sv39 page table |
| stop | revoke mapping + park core | reset hart |
By default an app also gets whole physical cores, with no time-sharing between strangers. Trusted apps may explicitly opt into a sharegroup; the memory cage stays in place.
One OS, two ways to use it
one machine
Jobs in hopos.init[] live on the boot medium. Without S3, every boot is clean: HopOS starts that exact set of Go apps again.
a fleet
HOP commits the desired cluster state to one object in S3. Each HopOS node reads that shared state and reconstructs its own jobs after a reboot.
The Go-first ecosystem
Stulp is a real HopOS workload. GoNet is companion tooling for running .NET test work from Go, on your own development machine.
home automation · production app
A home controller whose ten plugins continuously pull and poll on a 256 MB HopOS board. It is also the endurance rig: a week of work without going out of memory.
Stulp on GitHub →.NET runner · test work
A .NET runner written in pure Go, powered by wazero. It runs .NET test suites on your own machine without installing the .NET runtime — especially useful for testing repositories from a Go toolchain.
GoNet on GitHub →The smaller infrastructure apps get no privileges either. Browse all signed HopOS apps →
Where it runs
Apps are built once per architecture, not once per board. HopOS supplies the board-specific boot and drivers underneath. On UEFI machines and the Mac mini M4, its own bootloader takes over from the platform firmware — no GRUB in between.
Try it
The HopOS Imager downloads the latest 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 $ ./image/uefi-run.sh agent HOPOS_AGENT_UP
Each file is the complete medium. GUI boots the SURF desktop; Headless contains no graphics code.