Open coordination service

Meet OctoStore.

OctoStore helps distributed processes and agents agree on who gets to move. Use the totally free hosted version with no signup, or run the open-source server on your own infrastructure.

Same HTTP API · hosted or self-hosted · MIT licensed

OCTOSTORETWO WAYS TO RUN
HostedFREE PUBLIC SERVICE NO LOGIN
Open sourceRUN IT YOURSELF MIT
Same APIHTTP + JSON ANY STACK
USE OURSOR OWN YOURS

Three processes. One answer.

See the free hosted service make a real decision. OctoStore creates an anonymous room, races three workers, and returns one leader plus two followers that agree on who won.

no room yet
Worker SEA Seattle / cleanup-job Ready
Worker IAD Virginia / cleanup-job Ready
Worker FRA Frankfurt / cleanup-job Ready

Click “Run the election.” No credentials will be sent or created.

Any process that speaks HTTP No shared database to wire up Monotonic fencing terms One binary to self-host

Two calls. One leader.

Create an opaque room, share its ID with your processes, and let each candidate campaign. The winner receives the capability to renew or resign. Everyone else receives the winner and a retry delay.

no login no API key no SDK
shell · works from any runtime
# 1. Open a room.
ROOM=$(curl -s -X POST \
  https://api.octostore.io/elections \
  | jq -r .election_id)

# 2. Every process campaigns in that room.
curl -s -X POST \
  "https://api.octostore.io/elections/$ROOM/campaign" \
  -H "Content-Type: application/json" \
  -d '{"candidate_id":"worker-a","ttl_seconds":30}'

# winner → leader_token + term + renew_after_ms
# others → current leader + retry_after_ms

The easy version breaks at the worst time.

A database flag can choose a leader. It does not tell you what happens when two processes start together, the winner disappears, or an old leader wakes up and keeps writing.

Two processes start together One lease is committed. Every caller sees the same leader.
The leader crashes Renewal stops. The short lease expires and another candidate can win.
The old leader wakes up A higher fencing term lets downstream systems reject stale authority.
Your workers use different stacks They coordinate through JSON and HTTP instead of a language-specific client.
You do not want another cluster Use the hosted API now, or run one Rust binary with one SQLite file.

Use it anywhere one thing should run.

Leader election is not an agent feature. It is a small answer to a common systems question: which process gets the turn?

scheduled jobs cleanup workers singleton schedulers reconcilers migration runners agent dispatchers

Bash, Python, Go, Rust, JavaScript, a serverless function, or a thirty-year-old service. If it can send HTTP, it can campaign.

Start with election. Add coordination only when you need it.

The public API stays intentionally small. The self-hosted service adds durable task ownership and fleet coordination without taking over execution.

Use ours now. Own yours when you need to.

The hosted election API is the fastest path to one leader. Self-host the same API when the room, traffic, or coordination state must stay inside your boundary.

shell · local referee
curl -fsSL \
  https://raw.githubusercontent.com/octostore/octostore.io/main/install.sh \
  | sh

STATIC_TOKENS='ops:change-me' \
DATABASE_URL='./octostore.db' \
octostore

# listening on :3000
# state persisted in SQLite WAL

Build the job. Stop rebuilding the election.

Give every candidate the same room. Let one move. Let everyone else wait.