Skip to content

Applications

The app topic groups every command that acts on an application running in a cluster — both catalog installs (kind: CatalogApp) and source-built apps (kind: Application). The behavior is identical on both sides: the application is the unit of operation, regardless of how its image got into the registry.

Every verb under app takes an application name or slug as its first positional argument, and accepts -c, --cluster <name|id> to pick the cluster (auto-detected when the active profile has only one). The few output flags follow the same pattern as the rest of the CLI: -o, --output table|json (or text|json on the streaming commands), -f, --force to skip confirmations, --no-wait to queue and exit.

The sections below group the commands by intent: inspection, runtime diagnostics, release management, lifecycle, data management, and deletion.

Inspection

flui app list

Lists the applications in the cluster with their high-level state.

Terminal window
flui app list
flui app list --output json

flui app status <name>

Shows the live runtime status of one application: how many replicas are ready vs desired, the current release, and any condition that needs attention.

Terminal window
flui app status my-api
flui app status my-api --output json

flui app logs <name>

Streams application logs from the cluster. By default returns the last 100 lines; filter by level, full-text search, or bump the window.

Terminal window
flui app logs my-api
flui app logs my-api --level error
flui app logs my-api --tail 500
flui app logs my-api --search "connection refused"
FlagDefaultEffect
-l, --levelFilter by error, warn, info, debug.
-n, --tail <n>100Number of lines to return.
-s, --search <q>Full-text search.
--namespace <ns>auto-detectedOverride the namespace; rarely needed.
-o, --output text|jsontextOutput format.

flui app metrics <name>

Instant resource metrics for one application: CPU, memory, network I/O, replica count. Useful to spot-check a workload’s footprint or correlate a spike with a deploy.

Terminal window
flui app metrics my-api
flui app metrics my-api --output json

Runtime diagnostics

flui app crashes <name>

Lists recent crash diagnoses for the application — automatic reports produced when a workload restarted unexpectedly, summarising the exit code, the signals the runtime saw, and the probable cause.

Terminal window
flui app crashes my-api
flui app crashes my-api --output json

flui app crash <name> <id>

Shows one crash diagnosis in full, including the full reasoning chain the platform used to classify it. The --dismiss flag marks it resolved so it stops appearing as an active issue on the dashboard.

Terminal window
flui app crash my-api 5d3f... # show one diagnosis
flui app crash my-api 5d3f... --dismiss # mark it resolved

Get <id> from flui app crashes.

flui app build <name>

Status of the latest build of a source-built application (kind: Application). With --watch the command stays in the foreground polling until the build reaches a terminal status.

Terminal window
flui app build my-api
flui app build my-api --watch
flui app build my-api --refresh # force the backend to re-poll the CI
FlagDefaultEffect
--refreshForce a fresh poll of the upstream CI.
-w, --watchPoll until the build reaches a terminal status.
--interval <s>5Polling interval in seconds.

flui app builds <name>

Recent build history (default: last 10).

Terminal window
flui app builds my-api
flui app builds my-api --limit 50

Release management

A “release” is one rollout of an image into the cluster — a deploy or a rollback. A given image can be released multiple times; not every image gets released.

flui app releases <name>

Release history.

Terminal window
flui app releases my-api
flui app releases my-api --current # only the running release
flui app releases my-api --limit 50

flui app versions <name>

Image versions present in the container registry for this application, annotated with whether each one is the current deployment, a previous release, or unreleased.

Terminal window
flui app versions my-api
flui app versions my-api --limit 50
flui app versions my-api --output json

flui app redeploy <name> [<target>]

Re-deploys an existing image, without rebuilding. The target is a tag, a short digest (12+ hex chars), or a full sha256:<digest>. Alternatively --build <id> deploys the image produced by a specific prior build.

Terminal window
flui app redeploy my-api a1cac27
flui app redeploy my-api sha256:812bdfd0a833...
flui app redeploy my-api --build <build-id>

This is the rollback path: pick a known-good app versions entry and redeploy it.

Lifecycle

flui app start / flui app stop / flui app restart

The everyday lifecycle verbs. stop scales to 0 replicas (workloads disappear but their configuration and volumes are preserved); start restores the previous replica count; restart performs a rolling restart (one replica replaced at a time, the running count never drops).

Terminal window
flui app start my-api
flui app stop my-api
flui app restart my-api

flui app stop is equivalent to flui app scale my-api --replicas 0.

flui app scale <name> --replicas <n>

Sets the desired replica count.

Terminal window
flui app scale my-api --replicas 3
flui app scale my-api --replicas 0 # same as `app stop`

What scale actually achieves depends on the application’s storage class (see Storage classes and dedicated placement for the conceptual model):

  • Shared storage — every replica reads and writes the same network filesystem, so the platform can run as many replicas as you ask for, on any node. This is the case for stateless apps and for anything that uses the default storage class.
  • Dedicated storage — the application is pinned to the node that hosts its local disk and there is only one such disk; raising replicas beyond 1 would mean running multiple copies competing for the same on-disk state, which is unsafe. For these apps, horizontal scaling at the platform level is not supported: the way to give a dedicated workload more capacity today is to resize the host node (see flui env scale-master/scale-node). Application-level scaling for stateful workloads that can run as a cluster (read replicas, primary/replica databases, sharded queues) is a separate, planned direction — handled per-application rather than via flui app scale.

Data management

Two complementary surfaces operate on an application’s persistent volumes:

  • Snapshots live inside the cluster — a full clone of a volume, stored as another volume on the same cluster’s local storage. The clone copies the actual file contents (not a pre-allocated declared size), so a snapshot occupies roughly the space currently used by the source data. Restore is a local volume-to-volume copy, faster than fetching from object storage but not instant. The cost adds up with retention: each snapshot doubles the on-node disk used by that workload, so keeping many around pulls the cluster’s free capacity down quickly.
  • Backups archive the volume’s contents to S3-compatible object storage outside the cluster — much cheaper, slower to restore, durable across cluster destroys.

The two sets are independent; neither implies the other.

flui app snapshot create <name>

Creates a snapshot of an application’s volume. If the application has multiple volumes, pass --volume <name>.

Terminal window
flui app snapshot create my-app
flui app snapshot create my-app --description before-upgrade
flui app snapshot create my-app --volume data

flui app snapshot list

Lists snapshots. Without filters, lists every snapshot in the cluster; filter by application with --app.

Terminal window
flui app snapshot list
flui app snapshot list --app my-app
flui app snapshot list --app my-app --output json

flui app snapshot restore <name> <snapshot-id>

Restores a snapshot into a new side-by-side volume. The application is left untouched — the new volume is created in the same namespace and can be promoted later with snapshot swap. Pass --swap to do the restore-and-promote in one step.

Terminal window
flui app snapshot restore my-app <snapshot-id>
flui app snapshot restore my-app <snapshot-id> --swap
flui app snapshot restore my-app <snapshot-id> --swap --volume <name>

When --swap is set, the CLI also needs to know which application volume to retarget. If you don’t pass --volume, the CLI assumes the volume is named data (the conventional default). Pass --volume <name> explicitly whenever your app’s primary volume is named something else, or whenever the app has multiple volumes.

flui app snapshot swap <name> <new-pvc-name>

Swaps the application’s live volume for a different one (typically the one snapshot restore just created). Triggers a rolling restart; the previous volume is preserved as a backup until you delete it explicitly. The CLI asks to confirm before applying — --force skips the prompt.

Terminal window
flui app snapshot swap my-app my-app-data-restored-20260511
flui app snapshot swap my-app new-pvc --volume <name>
flui app snapshot swap my-app new-pvc --volume <name> --force

Same rule as restore --swap for --volume: without it the CLI assumes the volume is named data. Pass --volume <name> when your app uses a different name or has more than one volume.

flui app snapshot delete <name> <snapshot-id>

Deletes a snapshot. Asks to confirm; skip with --force.

Terminal window
flui app snapshot delete my-app <snapshot-id>
flui app snapshot delete my-app <snapshot-id> --force

flui app backup create <name>

Archives an application’s volume to S3-compatible object storage. If --bucket is omitted, the cluster’s provider auto-provisions one; otherwise pass --endpoint plus --bucket and S3 credentials (via flag or via FLUI_S3_ACCESS_KEY / FLUI_S3_SECRET_KEY).

Terminal window
flui app backup create my-app # auto-provisioned bucket
flui app backup create my-app --description nightly
flui app backup create my-app --bucket my-archive \
--endpoint https://s3.fr-par.scw.cloud \
--access-key <key> --secret-key <secret>
FlagEffect
-b, --bucket <name>Destination S3 bucket. Auto-provisioned when omitted.
-e, --endpoint <url>S3 endpoint URL. Required when --bucket is set.
-r, --region <code>S3 region (default: auto).
-v, --volume <name>Volume name when the app has multiple volumes.
-d, --description <s>Human-friendly tag appended to the key prefix.
--access-key <k>S3 access key. Required when --bucket is set; otherwise read from FLUI_S3_ACCESS_KEY.
--secret-key <s>S3 secret key. Required when --bucket is set; otherwise read from FLUI_S3_SECRET_KEY.
--key-prefix <s>Override the destination key prefix. Default: flui/<cluster>/<app>/<timestamp>/.

When --bucket is set, all three of --endpoint, --access-key, and --secret-key are mandatory (the last two can come from the matching env vars). Pass them together or none at all — passing the bucket without credentials fails up front.

Auto-provisioning works fully on Scaleway (it uses the same compute key); on Hetzner it requires Object Storage credentials to be connected. There is also a top-level flui backup topic for cluster-wide policy-driven backups — app backup is the ad-hoc, single-app variant. Run flui backup --help for the full subcommand list while the dedicated reference page is in progress.

flui app backup delete <name>

Deletes an S3 backup. Removes every object under the export key prefix.

Terminal window
flui app backup delete my-app <backup-id>

Deletion

flui app delete <name>

Permanently removes the application and its resources from the cluster. Works for both catalog installs and source-built apps.

Terminal window
flui app delete my-app
flui app delete my-app --force # skip confirmation
flui app delete my-app --no-wait # queue and exit

Some applications are system-protected (typically the components Flui itself depends on inside the control cluster). For those, --force is required as an explicit acknowledgement that you know what you are doing.

flui app image delete <name> <version-id>

Removes an image version from the container registry. Two guards protect against losing the ability to roll back:

  • The version that is currently deployed can never be deleted — this guard cannot be bypassed.
  • The version of the most recent release is also refused; --force overrides this second guard only.
Terminal window
flui app image delete my-api 845914920
flui app image delete my-api 845914920 --force

Get <version-id> from flui app versions <name> --output json — it is the numeric registry id, not the tag.