The Flux Roadmap: Building a Cloud for a Customer With No Email Address

Fluxers! The Flux roadmap has been rebuilt with the full plan from now through the second half of 2027 — what ships, when, and in what order, across the cloud platform, the network, the wallets and the chain.

It is worth reading in full, but the shape of it can be stated in one line: Flux is being rebuilt for a customer that has no email address.

Two rules that govern the whole thing

Before any of the items, the roadmap states two rules it holds itself to. They constrain the sequencing more than any individual feature does.

One: operator income never falls first. Anything that reduces what operators earn ships only after its replacement is live and paying.

Two: nothing irreversible ships before its gate. Contracts wait for audits. Chain changes wait for testnet. Privacy waits for its legal groundwork.

Those two rules are why the order of this roadmap matters as much as its contents: each change lands once the thing it depends on is already working.

Q3 2026: shipping now

Live, or in the final step before release. The CumulusVPN network is running across 135 gateways in 23 countries. Flux Console — the enterprise control plane — is live. SSP v2, SSP on Solana and XDC, bStocks and Kaspa tokens in Zelcore, the live supply tracker, and RPC, archive and indexing services are all in this bucket, with the VPN mobile apps sitting in Apple’s and Google’s review queues.

Q4 2026: one platform

The theme is consolidation. Two clouds, two dashboards and three billing systems become one product.

FluxCloud and FluxEdge merge. CPU container hosting and GPU capacity live in two places today, with two interfaces and two billing systems. They become tiers of a single platform, with one account, one dashboard and one balance. The marketplace, WordPress and FluxRunner become one-click templates inside it rather than separate destinations.

The interface gets rebuilt — a real priority rather than a coat of paint. The entire path a new user walks, from sign-up to first deployment to payment to custom domain, rebuilt in the merged product, with FluxEdge’s GPU and machine-rental flows folded into the same design language. Deployment management, monitoring, logs and billing in one place instead of three.

One balance, with top-ups, auto-renew and credits that spend across cloud, GPU and AI services. Low-balance warnings arrive before anything expires, with a grace period before teardown. Deployments dying because someone forgot to top up is a problem we intend to end.

FluxOS v9 specifications — the biggest change to how applications are described on Flux since the network launched. Components as a named map with plain fields and named ports; real load balancing declared in the spec, with custom domains, managed certificates, health checks, sticky sessions, retries and connection draining; proper sized volumes with explicit mount mapping; replicas and placement including active-standby and active-active; and duration as a first-class field, which is the foundation subscriptions and auto-renew are built on. The routing layer is already rewritten against it with a full regression suite, and it will be published as an RFC before rollout and tested like consensus code.

Also in Q4: deploy from Git (push a repository, get an application running across three instances, no Docker knowledge required), managed Postgres and MongoDB with backup and restore attached, private overlay networks, a Domain Manager overhaul, and an inference API.

The two items that define the direction

Two Q4 entries matter more than the rest, because they are the ones no other cloud is positioned to do.

SDK, CLI and MCP server. An MCP server first, so that “deploy on Flux” becomes a tool call any AI agent can make — then official SDKs, a real command-line interface, a Terraform provider and a GitHub Action from the same API. As it happens, this one shipped early: the Flux Cloud MCP server is already published. Agent-driven deployment is where a meaningful share of infrastructure demand goes next, and no cloud — centralised or not — is built for a customer that has no email address.

Payment is the account. The payment itself becomes the credential: pay from any wallet, receive an API token, deploy. No sign-up, no email, no card on file. It is the only onboarding a machine can complete alone — and it makes first contact simpler for humans too. With FluxEdge folded in, GPU capacity gets bought the same way: pay, run, stop, per second, without an account.

Operator protection

Operators host other people’s software and carry the risk that comes with it. The stated principle here is worth quoting: defence as protection from harm, not veto over content. Behaviour, not content.

That becomes four concrete things: an application oracle giving a live view of what each application consumes and where its traffic goes (aggregate volumes, never content inspection); resource guardrails that throttle and flag an application exceeding what it paid for; an optional standard egress profile with connection-rate limits and outbound abuse detection; and an evidence pack that produces, in one click, a document showing which application ran, when, and on which address.

The chain: three big pieces

Mint-and-burn bridge. Parallel assets move from being backed by FLUX held at bridge addresses to canonical mint-and-burn, where supply on each chain is provable and capped by the contract itself. Independent audit before deploy, multi-signature administrative control, per-chain caps, pausability, and reserve accounting published throughout. Ethereum and Base first. These contracts also become the home of a continuously verified proof that minted supply across every chain plus the main chain equals total issuance — a live proof-of-reserve for FLUX.

Privacy groundwork. Flux descends from the Zcash lineage, and private transactions are coming back: optional at the protocol level, shielded by default in our own wallets, viewing keys from day one, supply publicly verifiable. Q4 settles the remaining engineering choices — which shielded construction, wallet integration for Zelcore and SSP, and the legal position under the European rules arriving in 2027 — and the plan gets published with its reasoning.

Supply proposal. The mint-and-burn contracts make supply across every chain continuously provable, and that reconciliation is what makes a serious supply-policy decision possible. Once it is public, a proposal goes to the community in the open — a hard cap, freezing issuance at what has been produced, or letting the tail continue. Operators are paid from that issuance, so they get the full numbers before they are asked to weigh in.

H1 2027: usage starts paying the machines

PNR v2 is the change everything else is sequenced around. Today, when someone pays to run an application, that payment does not reach the machine running it. PNR v2 splits each application payment: part burned, part to the operator hosting that workload. Rewards are funded only by that workload’s own burn, so deploying an application to yourself to farm rewards costs more than it earns. It is a revenue-layer change, not new issuance. The sequence is testnet, then a pilot on a real product, then mainnet — with per-tier before-and-after examples published to operators before activation.

Alongside it: main-chain pruning for cheaper nodes and faster sync, with designated archive nodes preserving full history; a VPS tier with real virtual machines and a public IP, the largest single expansion of what Flux can sell; preview environments giving a URL per branch with automatic teardown on merge; referrals paid in hosting credits; and the consolidation from ten parallel-asset chains to fewer, stronger ones with long redemption windows.

Read it, and hold us to it

As the roadmap itself notes, these are development plans and priorities rather than a promise of specific delivery dates, and nothing here is investment advice. When a date moves, we say so in that month’s progress report.

Every item is expandable with the detail behind it at runonflux.com/timeline.