ArcaneOS: How a Flux Node Proves What It Is

Fluxers! Here is a number that surprises people: of the 1,841 applications registered on Flux right now, 811 are private enterprise deployments — 44% of everything on the network. Their code, configuration and secrets are encrypted, and the network will only place them on one kind of node: a node running ArcaneOS.

That raises the obvious question. On a network of independently operated machines, owned by people you have never met, what does it actually mean to trust one with your application? This article explains how an ArcaneOS node proves what it is.

The problem ArcaneOS solves

Collateral already gives every operator something to lose. A node locks FLUX to join the network, and the chain decides whether it is eligible to host and to be paid. That is a strong economic guarantee.

But collateral says nothing about what the machine is running. For a private application, you also want to know that the operating system underneath it is the real one, that it has not been modified, and that your data on its disk cannot simply be read by whoever has the hardware in front of them. ArcaneOS is the answer to those three questions.

Layer one: a boot chain Flux controls

ArcaneOS is a hardened Linux image built for FluxNodes, and it starts with Secure Boot. The firmware will only run a bootloader and kernel signed by keys it trusts — and on an ArcaneOS node, the platform key at the top of that chain is a Flux-controlled key, not a hardware vendor’s.

The node’s security service then checks, rather than assumes, that this is true. It confirms Secure Boot is actually enabled, that the enrolled platform key’s hash matches the pinned Flux value exactly, and that a TPM2 security chip is present. A machine that cannot prove all three is not treated as an ArcaneOS node. The outcome is specific, too: each failure has its own code, so an operator knows precisely which link needs fixing.

Layer two: a disk only that boot can open

The system volume is encrypted with LUKS, and the key that unlocks it is sealed inside the node’s TPM.

This is the clever part. The TPM will only release that key if the machine booted under the expected Secure Boot policy — the same Flux-controlled key chain from layer one. Boot something else, or pull the disk and put it in another machine, and the TPM simply does not hand over the key. The data stays encrypted at rest.

For a tenant, that means a private application’s storage is not something an operator can casually browse. For an operator, it means hosting other people’s encrypted workloads without ever being in a position to read them — which is a far more comfortable place to be.

Layer three: a root filesystem that cannot be quietly changed

ArcaneOS mounts its root filesystem under dm-verity. Every block of the operating system is checked against a cryptographic hash tree as it is read. Change a single byte of a system file and the check fails.

So the operating system a node is running is the operating system that was built and signed, not a tampered copy. The node’s security service reads the verity status directly as part of confirming the node is what it says it is.

Where private applications come in

Put the three layers together and you get a machine the network can reason about. That is what makes private deployments possible.

An enterprise application’s components are encrypted for the network, and only ArcaneOS nodes can decrypt and run them. On chain, such an app publishes an empty component list; the real specification — images, environment variables, commands, registry credentials — exists only inside nodes that have proved themselves. When you manage one through the Flux Cloud MCP server or the new FluxCloud interface, its details come from an ArcaneOS node using your owner key, and secrets never leave it.

811 private applications running this way is the clearest possible signal that it works — and that businesses are comfortable putting real workloads on it.

Independently audited

ArcaneOS has been through an independent security audit by Halborn, which found zero critical vulnerabilities, with every finding addressed and patched. We covered the audit in detail in ArcaneOS Security Audit.

What comes next: attestation you can stake on

ArcaneOS is the first layer of a larger plan. The second is a bonded attestation network, in which nodes stake collateral on signed claims about exactly what they are serving, and lose that stake if a challenger proves them wrong. Its parameters are set, and the design work on the slashing mechanism is under way.

That turns “this node booted correctly” into “this node is serving exactly what it claims, and has money on it.” It is also a cornerstone of Progressive Node Rewards, where a strong eligibility standard is what lets every node in a tier share the reward pool fairly.

Run an ArcaneOS node

If you operate a FluxNode, ArcaneOS is the way to make your machine eligible for the private workloads that now make up nearly half the network. The installation guide is in the Flux documentation.

And if you are deploying, choosing private mode means your application only ever lands on a node that has proved, three layers deep, that it is what it says it is.