exec
Run ordinary binaries with resource limits on the Linux and macOS machines you already own.
best for · simple services and existing hostsWhat it is
One process carries the control plane.
Put the same agentd daemon on each Linux or macOS machine. The agents elect a leader, accept jobs through one API and keep the requested workloads running. A HopOS node carries the same agent and leader inside the node.
There are no dedicated servers to nurse. If the leader disappears, another agent takes the lock. If a node reboots, it reloads its own committed jobs.
01Describe
→
Name the artifact, resources and restart policy.
02Match
→
HOP finds nodes with the right architecture and driver.
03Run
→
The agent starts a process, container or HopOS app.
04Reconcile
Health checks and committed state bring it back.
What it runs
Three drivers. One job spec.
Start with the runtime you already use. HOP does not make every workload become a container before it can be scheduled.
Docker
Run existing containers unchanged on Linux and macOS. Docker stays the runtime; HOP schedules and supervises it.
best for · packaged services and workloads that need Linuxhop → HopOS
Run compiled Rust or Go apps on physical cores behind hardware memory fences, with no Linux underneath.
best for · edge, appliances and dedicated resources meet HopOS →One job may contain builds for several architectures; each agent downloads the first artifact that matches its node.
Why it exists
A small cluster should not inherit a networking industry.
Remove the layers that cause the incident.
Kubernetes and K3s bring a large control plane plus network plugins, overlays and policy layers. HOP schedules onto the network you already operate; it adds no cluster overlay or CNI layer of its own.
less that can break
Make the network boundary honest.
The VLAN is the boundary. A workload on that VLAN — or someone who controls a host — can already reach the services there. HOP does not hide that fact behind another software network.
no overlay to debug
Keep the orchestrator small enough to know.
Leader, scheduler, agent and API live in the same Rust program; the logic crates are no_std so one code base runs as a host daemon and as a HopOS resident. The three workload drivers implement the same job lifecycle. An S3-compatible store or a hoplockserver holds the committed job snapshot and election lease.
one inspectable program
How does HOP elect and recover? open the election + restart path
Every agent is already a leader candidate. Election is one small lease; recovery is reading the desired state and starting only what is missing.
free / expired lease→conditional write→one winner→restore desired state
One renewable lease
The leader renews a small blob in an S3-compatible store or hoplockserver. The store is the referee; HOP does not run a separate election quorum.
One conditional winner
At boot an agent tries immediately. After a live leader disappears, agents wait for lease expiry and then race the same conditional write. Exactly one succeeds.
No new control plane to boot
The winning agent enables the leader role inside its existing process, loads the committed snapshot and opens the leader API.
Reconcile, do not replay
A new leader first lets agents register what they still run. HOP compares that with desired state and dispatches only missing instances, so a takeover does not duplicate healthy jobs.
17.3 s
power back → 126 jobs running again
Measured on the 128-core Ampere Altra with the previous generation of HopOS and HOP. This is the complete cold path — firmware, HopOS, HOP recovery and app start — not the lease timeout of a live leader failover. The v3 figure follows with the Altra bring-up.
Operational surface
Place it. Update it. Watch it recover.
The daily tools are here
What actually gets smaller
- Leader, scheduler, agent and API become one binary
- Committed jobs and a renewable election lease use an external store
- Workload definitions become a small HOP job spec
- Processes no longer need a container just to be scheduled
A complete job lifecycle
The operations you use every day.
Placement
Tell it what the job needs.
Instance counts, CPU and memory requests, node affinity and architecture-specific artifacts guide placement. On HopOS, resource ownership reaches down to app cores and memory partitions.
Changes
Choose how a job is replaced.
Rolling, recreate and blue-green update strategies are part of the job model. Health checks and restart policies govern recovery; live logs travel through the same API.
Visibility
Use the CLI or the browser.
Inspect agents, jobs and tasks, follow logs and apply changes. The hosted GUI connects to your cluster API. Discovery, routing and metrics remain separate, reusable services.
Recovery
Keep desired state outside the node.
With S3 persistence configured, a new leader reloads committed jobs and reconciles them with what agents still run. The external store must support the lease backend’s conditional-write semantics.
HOP can run on existing Linux and macOS hosts. On HopOS it is integrated into the node; SURF’s launcher and task manager are clients of its API. See that API on a desktop →
Operate it your way
CLI or browser. The same small API.
Use the hop CLI in scripts or point the hosted GUI at your cluster. Both talk to HOP’s HMAC-signed HTTP API through the leader; the GUI does not add another server to install.
$ hop apply --name api --driver docker \ --image registry.local/api:v12 Job 'api' dispatched $ hop agents ID ENDPOINT VERSION TEMP LAST SEEN o6n-1 192.168.1.205:8080 3.0.0 39.0°C 19:41:02 pi5-1 192.168.1.207:8080 3.0.0 57.0°C 19:41:04 linux-2 10.0.0.12:8080 3.0.0 - 19:41:03
Try it
Download one archive.
Each archive contains the node and control plane daemon plus the CLI. The links always resolve to the newest signed release; v3 builds from the repository with cargo build --release -p agentd -p cli.
agentd
agent · leader candidate · scheduler · HTTP API
hop
CLI for jobs, agents, logs, events and the kernel flip
checksums