Skip to content
Flui Documentation

What Flui is

Flui is an open source platform for hosting applications. To start using it, all you need is an API key from one of the supported providers. If you would rather not use a provider, or you want to use Linux servers you run on premises, you can do that too. A single command creates a complete cloud platform: clusters, networking, TLS, DNS, identity management, observability and a dashboard.

That is the base an installation starts from, but you can go beyond the provider you started with. Flui is built around the idea of a composable cloud: one surface where the capabilities that different cloud providers offer come together in a single platform. Flui manages a fleet of servers spread across one provider or several, and hides that work behind a clear web interface, a CLI and MCP.

This chapter explains the ideas behind Flui, and the gaps and needs it was built for. If you would rather start from the operational side, go to the Tasks section.

The gap Flui closes

Where you run your software matters, and each kind of cloud gives you a different experience.

Regional, sovereign and budget clouds

Many providers compete on good machines at fair prices. What they usually do not sell is the platform around those machines: the virtual network, the firewall, certificate management, DNS, scaling, application management and backups. These are the parts that turn machines into a place to run applications. When one of these providers does offer some of them, they tend to be its own stack, tied to that provider.

You can assemble the missing pieces yourself, and some teams do. Those projects usually end up as side projects that are hard to maintain.

This is where Flui helps most. Bring a key for one of these clouds, or a machine you already rent from one, and flui env create gives you the full stack a managed PaaS would give you. That includes something machines alone never give you: applications that scale within the limits you set, and clusters that buy another machine when they run out of room, with your consent and within a spending ceiling. See What a cluster may buy for itself.

Self-hosted panels also offer much of this stack, one server at a time. Flui goes further. An installation is not one cluster but as many as you need, on different providers and in different regions, all managed together; see Multi-cluster topology. A panel keeps the platform on the machine it was installed on. A Flui installation can grow beyond it.

Major hyperscalers

On the major clouds the building blocks already exist: managed Kubernetes, managed DNS, identity and observability. They work well, but they have a cost: vendor pricing, tight coupling to the provider’s network and identity, and an ecosystem that is hard to leave.

Flui does not compete with what hyperscalers already do well. On a hyperscaler, the reason to use Flui is portability: your applications can move between clouds, and the platform on top is not tied to one vendor’s stack.

Do-it-yourself stacks

On any provider you can build the platform yourself: an IaC tool for provisioning, a configuration tool for the hosts, a packaging tool for workloads, your own GitOps, ingress, certificate management, DNS automation and observability. Each piece works on its own. Keeping them working together is the real job.

Managed PaaS

Hosted application platforms give you a good experience, but they own the runtime. Your applications, your data and the format you describe them in belong to the platform.

Where Flui sits

Flui gives you the experience of a managed PaaS on the providers you already use, around an open specification you can take with you. An installation can use more than one provider, and Flui fills in what any single provider lacks. The control plane, the runtime, the manifest specification and every component Flui ships are open source.

What Flui does

From the outside, it works like this:

  1. You connect a provider Flui can provision on, or point Flui at a Linux machine you already own. The key stays with you: the CLI keeps it in an encrypted vault on your machine, and the installation keeps what it needs in its own database, on the machines you run. There is no Flui-operated service that receives your key. See where Flui runs for the current list.
  2. You run flui env create. About five minutes later the platform is installed and ready to host applications. This first cluster is the control cluster. It runs the control plane: dashboard, API, identity, database and observability. Each component (networking, TLS, identity, observability, the dashboard and so on) has its own chapter.
  3. From then on, Flui is where you manage the whole installation. You add workload clusters later, from the dashboard or through an agent, on the provider you started with or on another one. Clusters, nodes, networking, identity, certificates, observability and the applications themselves are all managed the same way, through the same CLI, dashboard and API.

Where Flui runs

Flui can put a machine in four kinds of place, and they do not all offer the same things.

  • Hetzner. Flui creates the servers, the private network, the firewall and the storage, and manages the DNS zone. Machines are billed by the hour.
  • Scaleway. The same: Flui creates the servers, the network, the firewall, DNS and storage. Machines are billed by the hour.
  • OVHcloud. Flui creates the servers through OpenStack, builds the private network and attaches the nodes to it, all billed by the hour. Two things work differently. OVHcloud has no DNS zone Flui can manage, so a cluster there publishes its names in a zone hosted on Hetzner or Scaleway, or in records you write yourself. There is also no firewall at OVHcloud’s edge that Flui can control, so the rules are applied on the machines themselves, as on a server of your own.
  • Your own server. Any Linux machine you can reach over SSH, whether you rent it, keep it in an office or under a desk. Flui installs on top of it and buys nothing. A VPS you rent from any provider counts as your own server, whether or not Flui integrates that provider.

The difference matters most when a cluster needs to grow. A cluster can add machines on its own only where Flui can buy them. On your own servers it cannot, so when a cluster runs out of room it raises an alarm that names the machine to add. Flui decides this from what each provider declares it can do, never from the provider’s name.

The list is not closed. Each provider lives in its own isolated module and declares the capabilities it supports, so adding one does not affect the rest of the platform; see How Flui works across providers.

Bringing your own server

Flui has three ways of working with the infrastructure underneath: Full, Partial and BYOS. All three are described in How Flui works across providers.

BYOS means bring your own server. You point Flui at a machine and it installs over SSH:

Terminal window
flui env create --host 203.0.113.10

No provider API is involved. --port, --user and --ssh-key cover hosts where you do not log in as root on port 22. Flui installs the same platform it installs on a provider (dashboard, API, identity, observability and the rest) and applies a firewall on the host itself, because there is no provider firewall to use. Later, flui node connect --host <ip> adds another machine you own to the same cluster.

What you give up is the work the provider would do for you. Flui cannot create or delete your machines, so you add capacity by hand.

What composable means here

Composable does not mean you will run everything across five clouds. It describes how the pieces of the platform fit together, and you can see it in three places. The installation below is one example.

Belongs to the installation Object storage from Scaleway S DNS zone from Hetzner H Outgoing email from Scaleway S Inference from Mistral, Scaleway MS Control plane Ubuntu servers you own Flui network H Hetzner 3 servers · 7 apps H Hetzner private network H Firewall at Hetzner's edge S Scaleway 2 servers · 4 apps S Scaleway private network S Firewall at Scaleway's edge O OVHcloud 3 servers · 5 apps O OVHcloud private network Flui firewall H DNS through Hetzner from the provider supplied by Flui a server Flui may buy when the cluster runs out of room, within your spending ceiling
One installation across three providers. The control plane runs on Ubuntu servers you own; storage, DNS, email and inference come from whichever provider offers them.

An installation is not tied to the provider it started on. A workload cluster can run on another provider, in another region, and it is still a cluster like any other: you manage it from the same dashboard and drive it with the same commands. Flui connects clusters that share no network with an encrypted network of its own, the Flui network (The network Flui builds). Inside a cluster, traffic stays on the provider’s private network, or on the Flui network where the servers have none. When a cluster can run somewhere else, and what that costs, is covered in Multi-cluster topology.

Some capabilities belong to the installation, not to one cluster. S3-compatible storage, outgoing email and model inference attach to the installation. They can come from any provider that offers them, wherever your servers run.

Some pieces are supplied by Flui. No provider offers a complete platform, so Flui supplies some pieces itself: the Flui network between clusters, the Flui firewall where there is no provider firewall to control, and backups. Some exist because a provider has none. Others exist because owning them keeps the platform the same wherever it runs.

How you use it

You work with Flui through four surfaces, all backed by the same API:

  • The Flui CLI, the main entry point and the surface this documentation focuses on.
  • The Flui dashboard, a web interface for the same operations.
  • The Flui REST API, exposed by every running control plane.
  • MCP, a Model Context Protocol endpoint on the same API. A coding agent can use it to deploy and operate the platform with its own credential, under the same permission model as a person. See The Flui assistant and MCP and The action cycle.

What Flui is not

  • Not a fork of Kubernetes. Flui uses upstream K3s and the standard Kubernetes API. kubectl, Helm and standard manifests all work.
  • Not a replacement for the open source ecosystem. Flui builds on well-known tools for ingress, certificates, logs, metrics and identity, and integrates them instead of reinventing them.

Status

Flui is in alpha. This documentation describes behaviour you can verify in the source code or with the CLI, and leaves out features that are not released.

  • License: AGPL-3.0. Commercial use is allowed. If you offer Flui as a network service to others, the license requires you to share your changes to the source. The LICENSE file is the reference.
  • Roadmap and current work: see flui.cloud.

For a command-by-command reference, see the CLI section. This section explains why Flui works the way it does.