Profiles and config

The CLI keeps every piece of local state under ~/.flui/ and exposes two related but distinct surfaces:

Profiles (context topic) — each profile is one isolated Flui installation on this machine: its own API URL, its own credentials, its own local inventory of clusters/nodes/firewalls.
Configuration (config topic) — a layered resolver that decides the value of each preference and stores provider credentials, always inside the active profile.

If you only ever run one installation from this machine, the auto-created default profile is enough and the context topic is something you can ignore. The config topic, on the other hand, is the one you reach for any time you need to change an email, add a provider credential, or troubleshoot “why does this preference have this value”.

Profiles

A profile is a directory ~/.flui/profiles/<name>/. The CLI creates default on first run and remembers the active one in ~/.flui/context. Switching profile is local-only — nothing in the cluster cares; the CLI just retargets every subsequent command at a different installation.

Commands

flui context list                    # all profiles, active one marked
flui context show                    # active profile + its API URL
flui context create staging          # create a new profile
flui context create staging --switch # create and switch in one go
flui context use prod                # switch to an existing profile
flui context delete staging          # delete a profile (asks to confirm)
flui context delete staging --force  # skip confirmation

Profile names accept alphanumeric characters, hyphens, and underscores.

Layered configuration

flui config reads and writes preferences and credentials. Every value goes through a cascade — the first layer that has a value wins:

explicit CLI input  >  env var  >  user-global config.json (active profile)  >  schema default

flui config show prints every preference along with which layer the current value came from — the fastest way to debug an unexpected value:

flui config show

Preferences

Four preferences are declared in the schema:

Key	Env var	Default	Purpose
`email`	`FLUI_EMAIL`	(required)	Contact email for Let’s Encrypt and operational notifications.
`certificateMode`	`FLUI_CERTIFICATE_MODE`	`production`	Certificate issuance mode written into the dashboard config. One of `production`, `staging`, `preflight` — see TLS and certificates.
`apiPath`	`FLUI_API_PATH`	`.`	Path to the `flui.api` repo. Only relevant to Flui contributors using `env export-config` / `dev creds`.
`dashboardPath`	`FLUI_DASHBOARD_PATH`	`../flui.dashboard`	Path to the `flui.dashboard` repo. Same scope as `apiPath`.

flui config set email you@example.com
flui config set certificateMode preflight
flui config get email                       # resolved value + source

Provider credentials

flui config set <provider> stores the credentials needed to talk to a cloud provider’s API. The shape is uniform across providers; the only thing that changes is whether the credential is a single token or a key+secret pair, which in turn decides whether it can be passed inline or has to go through the interactive prompt:

Provider	Credential	Input
`hetzner`	Single API token (`apiKey`)	Inline accepted: `flui config set hetzner <TOKEN>`
`scaleway`	Access Key ID + Secret Key	Interactive only: `flui config set scaleway` prompts for both fields and live-validates them against the Scaleway IAM API before saving

The list reflects what is supported today; the same flui config set <provider> pattern extends to any future provider — single-token ones will accept inline values, pair-credential ones will keep the interactive contract.

Credentials are never printed back. flui config list shows which providers have credentials stored but not their values; flui config get works on preferences only.

flui config set hetzner <YOUR_API_TOKEN>
flui config set scaleway                    # interactive prompt
flui config list                            # everything in the active profile
flui config list --tokens                   # provider credentials only
flui config list --preferences              # preferences only
flui config remove hetzner                  # asks to confirm by retyping the key
flui config remove scaleway --force         # skip the confirmation

System keys

api-url is the one system-level key today: the URL of the Flui API the active profile talks to. It is set automatically by flui env create (and on the joining side by importing the export-config output), and only rarely needs manual editing.

What lives in a profile, and how it is stored

A profile directory contains:

config.json — preferences (plain) and provider credentials (encrypted).
ca/ — the SSH CA used to authenticate to cluster nodes (encrypted).
clusters.json, nodes.json, firewalls.json, vnets.json, operations.json — local inventory cached from the API; safe to delete, will be repopulated on the next command that needs them.

Examples

# Create a staging workspace on Hetzner
flui context create staging --switch
flui config set email staging@example.com
flui config set hetzner <staging-token>
flui config set certificateMode staging
flui env create

# Same on Scaleway — interactive prompt for the key pair
flui context create staging-scw --switch
flui config set email staging@example.com
flui config set scaleway
flui env create --provider scaleway

# Debug where a preference is coming from
flui config show
flui config get certificateMode

# Remove a provider's credentials
flui config remove scaleway --force