Skip to content
flui.cloud

Start here

A concept chapter explains why Flui works the way it does. A reference page tells you what a flag is called. Neither one answers a request like “I want my app on the internet.”

The task pages in this section do. Each page covers one job, from the first command to the working result.

Every surface that can do the job

There are three ways to drive Flui: the CLI, the dashboard, and an agent connected over MCP. They cannot all do every job.

Each page shows every surface that can do that job, and only those. Where a surface cannot do it, the page says so and explains why. You will not find an empty tab here, or a command made up to fill one.

Three examples:

  • Getting Flui running: the CLI only, or app.flui.cloud, which runs the same command for you. The dashboard comes with the installation, so it cannot be what installs it.
  • Reaching the platform’s own database: the CLI only. That database is closed to the web console, and the tunnel is the only way in.
  • Answering an agent’s request: the dashboard only. You approve or refuse it there, or against the API underneath. There is no flui command for it.

The order of the pages

The pages follow one order, from installing Flui to recovering from a loss.

Get Flui running. You start with only a provider credential, or a Linux machine you already own, and end with a platform and somewhere to put work.

  1. Get Flui running
  2. Add a cluster and give it capacity
  3. Let a cluster buy its own machines

Put an application on it. There are two ways in, your own repository or something ready-made from the catalog, followed by the two things every application needs before it is useful: its configuration and an address.

  1. Deploy an application from your repository
  2. Install an application from the catalog
  3. Set an application’s configuration and secrets
  4. Put an application on the internet

Keep it running. Watching it, protecting it, moving it, removing it, and getting at the data underneath it. Two of these need care: removing an application takes its storage with it, and one database on the installation is the product itself.

  1. Watch and operate a running application
  2. Protect an application and get it back
  3. Move an application to another cluster
  4. Remove an application and its data
  5. Open a database from your machine
  6. Reach the platform’s own database

Let people and agents in. Up to here you have worked alone. This is where somebody else, or an agent, gets a key, and where you decide how far it reaches.

  1. Give a teammate access
  2. Connect an agent
  3. Choose what your agent may do
  4. When your agent stops to ask you
  5. Write down how this installation is run
  6. Send mail from this installation

When something is lost. A cluster, or the machine running Flui itself, is gone. These two pages put it back from Flui’s records and the backups.

  1. Rebuild a lost cluster
  2. Rebuild the control plane

Read them in order the first time. After that each page stands alone: it names what it assumes and links back to the page that provides it.

What is not here, and why

This section covers the jobs people ask for by name. Many real features are not jobs in that sense, and listing them here would make the list too long to read.

The public showcase is covered alongside the commands it belongs to, in the CLI section.

Where the rest of the docs live

  • Concepts: why Flui works as it does. Read these when something behaves in a way you did not expect. The task pages link to them instead of repeating them.
  • CLI reference: topics, verbs and flags, plus the conventions that recur everywhere. Every command also has --help, which is generated from the CLI itself and is never out of date.

If you have never run Flui at all, start with Get Flui running.