HOP · the orchestrator

Run your machines as one small cluster.

HOP is one Go binary that schedules plain processes, Docker containers and bare-metal HopOS apps. Every node can be agent, leader and HTTP API. Shared state is one object in any S3 bucket.

try HOP → open the GUI see how it works

use the machines you have · add HopOS metal when it helps →

What it is

An orchestrator with almost no control plane.

Put the same agent binary on each Linux or macOS machine. The agents elect a leader, accept jobs through one API and keep the requested workloads running.

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.

01 · no image required

exec

Run ordinary binaries with resource limits on the Linux and macOS machines you already own.

best for · simple services and existing hosts
02 · keep your images

Docker

Run existing containers unchanged on Linux and macOS. Docker stays the runtime; HOP schedules and supervises it.

best for · packaged services and non-Go workloads
03 · remove the host OS

hop → HopOS

Run compiled 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.

01

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

02

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

03

Keep the orchestrator small enough to know.

Leader, scheduler, agent, API and three workload drivers live in one ~7,550-line Go program. Cluster state is one object in S3, not another database cluster.

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. This is the complete cold path — firmware, HopOS, HOP recovery and app start — not the lease timeout of a live leader failover.

Read the full election and state design →

Operational surface

The daily tools, with less platform underneath.

The daily tools are here

  • Processes, Docker and HopOS under one job model
  • Health checks, priorities, restarts and recovery
  • hopdns discovery and hoplb load balancing
  • Prometheus metrics through hopprom

What actually gets smaller

  • Leader, scheduler, agent and API become one binary
  • etcd or a Raft quorum becomes one object in S3
  • Workload definitions become a small HOP job spec
  • Processes no longer need a container just to be scheduled

Operate it your way

CLI or browser. The same small API.

Use the run CLI in scripts or point the hosted GUI at your cluster. Both talk to HOP’s HMAC-signed HTTP API; the GUI does not add another server to install.

open gui.gethop.org → browse the CLI and API
 run · the HOP CLI
$ run apply --name api --driver docker \
      --artifact registry.local/api:v12
api: created

$ run agents
ID        DRIVER          LAST SEEN
altra-1   hop             19:41:02
pi5-a     hop             19:41:04
linux-2   exec,docker     19:41:03

Try it

Download one archive.

Each archive contains agent, the node and control plane, plus run, the CLI. The links always resolve to the newest release.

Linux · amd64 Linux · arm64 macOS · Apple silicon
agent

agent · leader candidate · scheduler · HTTP API

run

CLI for jobs, nodes, logs and cluster operations

checksums

verify the downloaded archive →

read the setup guide → read the source → download a HopOS node →