This page is about direction, not delivery. What Flui does today is on the platform and providers pages, in the present tense, and nothing here should be read as a description of it.
There is far more computing capacity in the world than the cloud market represents. Regional providers with real datacentres. Colocation facilities. University clusters. Machines a company already bought and depreciated. Hardware sitting close to where the data is actually produced. Most of it is perfectly good infrastructure, and almost none of it participates in what people mean when they say "the cloud".
The reason is not technical quality. It is that participating has come to mean building a hyperscaler: a managed Kubernetes service, an identity system, an observability stack, a load balancer product, a certificate authority, a console, a CLI, an API, and a decade of documentation. A provider with excellent machines and a good network still loses to one with a worse network and a better platform, because the platform is what developers actually touch.
So the market consolidates — not because the capacity is concentrated, but because the platform layer is.
If the platform layer were separable from the provider, a regional cloud would not need to reproduce a hyperscaler's product catalogue to be useful. It would need to be good at what it is already good at: machines, network, power, proximity, price, jurisdiction. The rest could come from somewhere else.
That is what Flui is trying to be — the layer above, rather than another entrant below. It is also why a provider does not have to implement everything to participate. A provider that offers compute and nothing else should still be able to run applications, and the platform should be honest about which capabilities are missing rather than flattening every cloud down to whatever the weakest one supports.
Today, choosing a cloud is choosing everything at once: compute, storage, network, DNS, identity, billing relationship, jurisdiction. They arrive as one decision because they arrive from one vendor, and separating them later is the thing everybody calls lock-in.
The direction Flui is building toward is one where those are separate decisions — where compute might come from one place, storage from another, DNS from a third, GPUs from a fourth, and a workload with particular constraints from a machine you own. Not because that combination is exotic, but because there is no good reason it should require rebuilding your platform to change any one of them.
This is not what Flui does today. Today a cluster belongs to one provider, and composition happens between clusters rather than inside one. The providers page says exactly where that line currently sits.
A machine in an office, a rack in a factory, a node beside the sensors producing the data — these are usually treated as a different category of infrastructure with a different set of tools. They should not be. The reason they are is again the platform layer: nobody ships one for eight machines in a building.
Bring-your-own-server exists in Flui today for exactly this reason, and it is deliberately not a lesser mode. It has no provisioning API, so nodes and firewalling are driven over SSH instead — and everything above that, applications and databases and scaling and observability, is the same product. That is the shape the rest of this should take.
In a large part of the world, the local answer to "where do I deploy this" is a hyperscaler region on another continent, or nothing. Local providers exist in many of those markets; what they lack is the layer that would make them usable the way developers now expect.
A composable platform layer is worth more in those markets than in the ones already well served. A developer in a country with three local providers and no hyperscaler region should be able to build on them, with the same tools, without waiting a decade for someone to decide their market is large enough.
The trade that the last fifteen years normalised is: hand over your infrastructure and get simplicity back. It is a real trade and it buys real things. But it is not the only possible one, and it has been treated as though it were.
Flui's position is that a platform can be the easy path without also being the owner. Your provider accounts stay yours. Your servers are billed to you. Your data is where you put it. Leaving is a normal operation rather than a project. The guided install is the sharpest version of this: it builds your cluster and then keeps nothing that would let it back in.
Composable infrastructure is more complex than a single provider, and that complexity is the honest objection to all of the above. Coding agents change that calculation: an interface that can absorb heterogeneity is exactly what makes many providers as approachable as one.
The risk is obvious and worth naming. Infrastructure that only a model can navigate is not owned by anyone. So the direction is agentic interaction over deterministic state: the conversation can be fluid, the resulting configuration stays explicit, diffable and revertible, and a person answers before anything consequential happens. That part is already built.
Flui is built in Italy, integrates European providers first, and runs without third-country dependencies. That matters, and for many teams it is the whole reason to look. But it is the first instance of the argument rather than the argument itself: European sovereignty is what composable infrastructure looks like when the boundary you care about happens to be a jurisdiction.
Other people care about other boundaries — a market, a building, a latency budget, a regulator, a bill. The model is the same one.
None of this requires anyone to be wrong. Hyperscalers built genuinely extraordinary infrastructure and there are workloads for which they remain the right answer. In a model where infrastructure is composable they are a backend among others — an excellent one, chosen for a particular job rather than for all of them at once.
What we are arguing against is not a company. It is the idea that the provider has to be the indivisible unit of the cloud.
