FluxOS 8.21: One Writer, Nothing Lost
Fluxers! FluxOS 8.21 is rolling out across the network. It is a release about trust in the details: apps with a single writer hand over to a standby without losing a byte, nodes serve the app registry only once it is complete, a node whose address moves keeps its apps, and FluxOS takes full ownership of the node’s firewall. In numbers, that is 27 merged pull requests and 634 commits since FluxOS 8.20, three weeks ago.
Single-writer apps: one writer, nothing lost
Some apps on Flux run as single-writer (g:) apps: one primary node runs the app while standby nodes hold a live, synced copy of its data, ready to take over. FluxOS 8.21 makes that handover clean, end to end.
- Files keep their owners and modes on every node. A standby’s copy carries the primary’s exact ownership and permissions, so a node that takes over simply starts the app — no permission sweep, no surprises.
- Only the primary ever writes. A folder is writable only on the node that holds the component and read-only everywhere else, and a returning ex-primary steps back in line.
- The last save always leaves. A primary that shuts down hands over its final writes before it goes.
- Takeover only on evidence. A quiet peer counts as gone only when this node actually saw the connection close and still sees most of the network, and every start asks every holder first.
- Room to grow. An app may use up to 820 GB with no limit on file count; FluxOS re-checks a million unchanged files in about two and a half minutes.
A registry served only when complete
Every node serves the network’s app registry and app locations. In 8.21, a node that is still catching up answers “try again shortly” (a 503 with Retry-After) instead of a partial list, so every registry answer from a Flux node is a complete one. A new /apps/registrystatus route reports a node’s registry state at a glance.
Address moves that keep their apps
Home nodes sometimes get a new public IP from their provider. FluxOS 8.21 treats that as a first-class event: the node records its own move once, tells it to each peer as it connects, and reconciles everything — configuration, apps, location records and geolocation — to the new address. Primary roles follow the move, so the apps on that node keep running with no failover at all.
A firewall FluxOS owns
FluxOS now keeps the node’s firewall whole and consistent in one step at start, before any app container runs. App containers cannot reach the node owner’s private networks, and one app reaches another only through a published port. Registries at private or reserved addresses are refused on every hop. The minimum Docker version rises to 28.1.1, which nearly every node on the network already runs.
A node that knows itself
- Tunnel detection. FluxOS now reports whether a node reaches the internet through a tunnel to a remote box, published under
flux.uplinkin/flux/infoand at/flux/uplink. - Honest health.
/flux/healthreports every check as ok, unmeasured, degraded or fail, and adds a check on the Flux daemon itself. - Ready means ready. FluxOS tells systemd it is ready only once its API and the daemon both answer, the groundwork for cleaner restarts on ArcaneOS.
- Local benchmark socket. Where fluxbench offers a local Unix socket, FluxOS uses it, in step with the fluxbench 6.5 line on ArcaneOS.
- Logins survive a restart, and an update to an expired app now renews it at the normal price.
Tested like infrastructure
Behind the release is the FluxOS test harness, which boots whole networks of simulated nodes to prove behavior end to end. The firewall work alone passes more than 8,000 unit tests and 163 integration suites, and the container rules were proven across five Docker versions in 60 scenarios and nearly 22,000 probes before a single node ran them. A quick 8.21.1 follow-up refined how read-only copies treat writes that never leave the node.
Get it
FluxOS updates itself on every node; there is nothing to do. The full list of changes is in the FluxOS releases on GitHub, and we covered the previous release in FluxOS 8.20.
Posted in Product Updates
by RunonFlux
Tags:
Comments
Leave a Reply
You must be logged in to post a comment.
