Skip to content
flui.cloud

Multi-context — many installations from one workstation

The previous chapter described multi-cluster: a single Flui installation that operates many clusters. This chapter is about the layer above — one workstation driving several Flui installations, each with its own control cluster, its own credentials, its own state. The CLI calls each of these connections a context.

Multi-context is not multi-cluster

The two ideas are easy to mix up:

  • Multi-cluster means one installation governing many clusters. You move between clusters within an installation by saying which cluster the operation is for — or letting the CLI choose when only one is available.
  • Multi-context means one workstation talking to several installations. A consultant operating Flui for three customers, a developer with separate local, staging and prod installations, a platform team running Flui for two unrelated business units — each of those is a separate context.

Two installations are not just two clusters. Every installation has its own API, its own identity provider, its own admin credentials, its own database, its own SSH trust root. Switching between them is not a flag on a command; it is replacing the entire connection state the CLI uses.

A context is the unit of switching

A context bundles everything the CLI needs to talk to one installation: the URL of that installation’s API, the credentials to authenticate against it, the provider tokens it stores, the trust anchor it uses to reach cluster nodes, and the local view of clusters, nodes and operations that installation knows about.

The CLI stores each context on disk. Switching between them is a single command, and the switch is instant — nothing is copied around or re-fetched; the CLI simply changes which context’s on-disk state it reads from. A one-off command can also borrow a different context for a single invocation without changing the active one.

What a context isolates

Contexts share nothing operational by design:

  • Credentials don’t cross. The provider tokens you added to one context are not visible to another. The same is true of the admin keys used to talk to the API.
  • Secrets are encrypted per context. Even with read access to a context’s files, decrypting them requires that context’s own key.
  • Local caches are per context. The cluster list you see, the recent operations, the SSH trust — all of it belongs to the active context. Switching to another context replaces them with that context’s view.

This isolation is the point of the design. Nothing operational travels between contexts: a command typed in the wrong one cannot reach into another installation, because the wrong context simply does not hold the credentials to.

On disk, this isolation is plain to see. Each context is a separate directory under ~/.flui/profiles/, holding its own configuration, secrets, caches and trust material:

~/.flui/profiles/
├── default/
└── another-context/

The exact layout of each directory, and the commands that create, inspect and switch contexts, live in CLI: Profiles & Configuration.

How the CLI shows which context is active

Every CLI command prints a small header before its output stating which context it is acting on and which API it is talking to. A forgotten switch does not produce silent damage on the wrong installation: the header is the first thing you see. This is a small piece of UX that prevents an entire class of “I just ran that against production” mistakes.

Where this chapter goes from here