Deploy and catalog validate

flui deploy takes a flui.yaml manifest and rolls the application onto a cluster. The same command handles both manifest kinds:

• kind: CatalogApp — the image already exists in a registry; Flui pulls and deploys it.
• kind: Application — the image is built from source by the CI of the platform that hosts the repo, then the resulting image is deployed.

The user-visible flow is the same in both cases: read the manifest, target a cluster, run; the difference is whether there is a build step in front. See the concept chapters Catalog vs Application and Build pipeline, today and tomorrow for the model.

flui deploy [<file>]

flui deploy                                # ./flui.yaml, auto-detect repo/branch/cluster
flui deploy ./apps/api/flui.yaml           # explicit manifest path
flui deploy --repo acme/my-app --branch main
flui deploy --env DATABASE_URL=postgres://... --env API_KEY=secret
flui deploy --detach                       # queue and exit
flui deploy --validate-only                # check the manifest, don't deploy
flui deploy --cluster my-cluster           # pin a target cluster

Argument / Flag	Effect
<file>	Path to the manifest. Default: ./flui.yaml.
-c, --cluster <name|id>	Target cluster. Auto-detected when the active profile has only one.
-r, --repo <owner/repo>	Source repo. For kind: Application, auto-detected from git remote origin.
-b, --branch <name>	Branch to build. For kind: Application, auto-detected from the current branch.
-d, --domain <fqdn>	Custom FQDN for the app. Auto-assigned from the cluster’s DNS zone otherwise.
--name <name>	Display name override. Default: metadata.name from the manifest.
-e, --env KEY=VALUE	Per-deploy env override. Repeatable.
--detach	Return as soon as the build/deploy is queued. Track with flui app status.
--no-wait	Alias of --detach, kept for symmetry with other commands.
--no-build	Skip the build step and redeploy the current image. Useful when you only changed flui.yaml settings (env, ports, healthcheck, endpoint).
--image <ref>	Deploy a specific image reference (e.g. registry/owner/repo:sha). Skips the build pipeline; useful for rollbacks.
--skip-endpoint	Skip DNS and TLS provisioning. kind: CatalogApp only.
--validate-only	Validate the manifest against the spec and exit, without deploying.

Auto-detect rules

flui deploy with no arguments behaves as follows:

• The manifest is ./flui.yaml.
• For kind: Application: the repo is whatever git remote origin points at, the branch is the current one (from git branch --show-current).
• The cluster is the only one in the active profile; with more than one cluster, pass -c, --cluster.

Any of these can be overridden with the corresponding flag.

Fast iteration

When you change only configuration in flui.yaml (env vars, ports, healthcheck, endpoint) and don’t need a new image:

flui deploy --no-build                              # re-deploy the current image
flui deploy --image registry/owner/repo:abc123      # deploy a known-good image

--no-build skips the build entirely; --image lets you pin a specific image you already trust (rollback, hand-picked tag).

flui catalog validate <file>...

Validates one or more flui.yaml manifests against the Flui spec. Read-only: nothing is deployed, nothing on the cluster is touched.

flui catalog validate ./flui.yaml
flui catalog validate ./catalog/vaultwarden.flui.yaml ./catalog/memos.flui.yaml

<file>... is repeatable: pass several manifests in one shot. The validator covers both kind: CatalogApp (full schema check) and kind: Application (lighter checks — some fields are populated by the build pipeline so they are not required at validation time).

The same check is also available inline as flui deploy --validate-only, which is convenient when you are about to deploy and want a quick gate.