FluxOS 8.19 and 8.20: Signed Network Policy, Strict Pinning and a New API Reference

Fluxers! Two FluxOS releases landed back to back in September — 8.19.0 on the 23rd and 8.20.0 on the 25th — together carrying 420 commits since 8.18. They change how the network agrees on its own rules, make pinned enterprise deployments strict, give every node a proper health endpoint, and come with a completely rebuilt API reference.

FluxOS updates itself, so most operators already have them. Here is what they bring.

Network policy, spread by the network itself

Every node needs to know the network’s current policy — for example, which images are blocked and what counts as tampering. Until now, each node fetched that policy from a single published source.

From these releases, policy travels as a signed bundle, and nodes pass it to one another. When a node adopts a new version, it announces it to its direct peers; any peer that is behind fetches it from that node, adopts it, and announces it onward. A change spreads outward across the fleet from whichever node received it first. The published source now only seeds it.

The key to making that safe is the signature. A node verifies every bundle against a known key list before using it, so it no longer matters where a bundle came from — a bundle passed along by a stranger is exactly as trustworthy as one fetched from the source, because only a correctly signed one is ever accepted. And a node restored from an older bundle holds it until no reachable peer is ahead, so the fleet converges on the newest policy rather than an old one.

It is a small change on the surface and a big one underneath: the network now distributes its own rules, peer to peer, with cryptographic proof attached.

Pinned means pinned

Enterprise owners can pin an application to specific nodes — trusted, known machines they have chosen. From 8.20, a pinned app runs where it says, or not at all. There is no quiet fallback that installs it somewhere else half an hour later.

For teams who pin for compliance or data-residency reasons, that turns pinning into a real guarantee. Pinning a version 8 specification is now reserved to enterprise owners, which keeps the guarantee meaningful.

A proper health check for every node

Every node now answers GET /flux/health. It runs the node’s full fitness battery — database, Syncthing, Docker, hardware and more — and returns either success with a result for each check, or the first check that failed.

Previously those checks were folded into an authentication call, which meant a passing glitch in one subsystem could fail a node’s benchmark. Separating health from authentication makes both more reliable — and gives operators and monitoring tools one clear place to ask whether a node is well.

Nodes that tell you why

A node whose connection to its peers keeps collapsing cannot serve the applications it holds. FluxOS now notices the pattern — five sharp drops in peer count inside two hours — and takes that node out of service with a clear reason, instead of leaving it silently unable to take work. The operator sees exactly what is wrong; the network routes around it.

Your data stays where your spec says

Components can now mark a directory to keep off the network — data that is stored locally but never replicated to other instances, ideal for caches, local backups or scratch space. The specification is the single source of truth for what may leave a node: the ignore rules are derived fresh from it on every pass, so nothing written inside the container can quietly widen what gets synchronised.

Volume handling got a thorough pass too: operations that write into staging pause when space runs low, compressing and extracting enforce limits file by file as they go, and a volume the host could not mount is recorded clearly rather than counted as if it were there.

Simpler, cleaner pricing

Application pricing is now uniform: every application is priced by the same rule, primary/standby storage included, and USD prices round up to a price ending in .49 or .99. Quotes are easier to read and easier to compare. A price you set yourself through the API still comes back exactly as you sent it.

Settings that moved to the network

Per-node blocked ports and blocked repositories, which each operator used to configure individually, have been retired. What may run on the network is now decided once, in the signed network policy described above, rather than differently on every node — so an application behaves the same wherever it lands.

A new API reference

Alongside 8.20, the FluxOS API reference at docs.runonflux.io has been rebuilt from the ground up:

• It matches the code. The reference documents FluxOS 8.20.0 exactly — 135 retired routes are gone, the new ones are in, and the fixes were checked against the handlers themselves.
• Links never dead-end. Links to removed endpoints redirect to removal notes explaining what replaced them.
• Ask AI on every endpoint. Each endpoint has its own Ask AI button, answered by the Flux documentation assistant — which has itself been re-indexed on the 8.20 reference.
• A section for AI agents and MCP, for anyone building agents that deploy to Flux.
• The Flux look, on a fast, self-hosted reference.

Getting it

FluxOS updates itself; if you run a node, check its version on the dashboard. Developers building against the node API should start at docs.runonflux.io, and the full changelog is on GitHub.