flui.cloud

What one command installs

flui env create points at one of the supported providers, or at a Linux server you already own. About five minutes later the platform is running: a K3s cluster with networking, ingress, TLS, DNS, identity and observability, all managed from one CLI, API and dashboard.

One installation, many providers

One control cluster and as many workload clusters as you need, each on the provider and region you choose. The Flui network connects them with end-to-end encryption, and you manage them all from the same CLI and dashboard. Some capabilities belong to no single cluster: S3-compatible storage, email and model inference can come from any provider that offers them.

A platform agents can operate

Flui supports MCP, so a coding agent can deploy and manage the platform with its own key. Everything it does stays visible, and you decide how far it reaches: which areas and which applications.

Applications describe what they need

A runtime, a PostgreSQL database, storage, a rule about where data lives. The flui.yaml manifest describes requirements instead of one provider’s product names, and the platform turns them into placement and infrastructure.

Start here

Concept chapters explain why Flui works the way it does. Reference pages give you the name of each flag. Neither tells you how to get your app on the internet.

The task pages do. Each one covers a single job, in the order you will need them: from nothing installed, to a running application, to letting other people and agents in.

The task pages Every job in order: get Flui running, put an application on it, keep it running, let people and agents in.

Get Flui running The first hour. Start with a provider credential, or a Linux machine you already own, and finish with a running platform.

Deploy an application From a connected repository to a running application: the manifest, the checks against your installation, the deploy.

Connect an agent Give a coding agent its own credential, decide how far it reaches, and see what it does with it.

Go deeper

Once you know the basics, the concept chapters explain why the platform makes the choices it does. Read them when something behaves in a way you did not expect.

Multi-cluster topology One installation, one control cluster, many workload clusters, and what lets a cluster run on another provider.

The network Flui builds How the Flui network connects clusters at different providers with encryption, and closes the public path only after it has proved it can replace it.

The flui.yaml manifest The open specification at the centre of the platform, which your applications use to describe what they need.

The action cycle Why a write made by an agent stops and asks a person first, and why a standing permission can never widen what anyone may do.

Who can reach what Four roles in one ladder, grants that bind a principal to a set of resources, and why some refusals read as if nothing were there.

What a cluster may buy for itself Autoscaling starts with your written consent: bounds, a spending ceiling and a readable reason for every decision.

TLS and certificates The three issuance modes a cluster can run in and the three certificate shapes Flui picks between.

Observability as first-class Why metrics, logs and crash reports come with the platform instead of being an add-on you wire up yourself.

---

The dashboard has no section of its own here. It is documented where you use it: every task page shows each surface that can do that job (the CLI, the dashboard, an agent) and describes in words which screen and tab to use and what it asks you for. Only the surfaces that can do the job appear, so you will not find an empty tab or a command made up to fill one.

For now most of those descriptions are text, and screenshots are still being added. The dashboard’s source lives at flui-cloud/flui-dashboard.