Skip to main content
This page is the command reference. For the full integration guide (plugin examples for GitHub Actions and Buildkite, AWS credential options, and exit codes), see CI/CD Integration.

​
Overview

The fjall ci family covers everything a pipeline needs, from scaffolding the workflow file to running the deploy. Pipelines authenticate with a CI deploy token (prefix fjall_dk_), stored as the FJALL_API_KEY secret.
Deploy tokens are minted only from a signed-in browser session, by an owner or an admin, in the web app under Settings → CI/CD Tokens. POST /api/ci/tokens rejects every token-authenticated caller, including the CLI’s own stored login, so the CLI carries no mint command. ci setup writes the workflow file and hands off to the web app for the token; everything after the mint works from the CLI.

​
Subcommands

​
Set up a pipeline

setup resolves the CI provider, the repository, the application and the deployment target, checks that the target’s AWS account is connected to your organisation, then writes the plugin-form workflow file for GitHub Actions or Buildkite and prints the web-app URL where the deploy token is minted.
setup never holds a deploy token. Without --plan it writes the workflow file (refusing to overwrite an existing one unless --force is passed) and prints the next step: mint the token in the web app (Settings → CI/CD Tokens), store it as the CI secret, then run fjall ci verify. With --plan it prints the resolved provider, application, workflow path and deploy target, then the fully rendered workflow YAML, and writes nothing. --plan also skips the existing-file check, so it never errors on a workflow that is already there.

​
Verify readiness

verify dry-runs the auth handshake before your first pipeline run and prints four checks. Every failing check carries a directional fix. Warnings do not fail verification. Any fail row sets exit code 1.

​
Check token readiness

status counts the organisation’s CI deploy tokens and reports Ready: yes when at least one is active. Expired and revoked counts print alongside, so a pipeline that started failing on auth shows its cause in one line.

​
Manage tokens

list prints one row per deploy token: name, token prefix, status (active, expired or revoked) and the resolved constraint summary. It warns separately about two states worth acting on. An unconstrained active token can deploy in every application, environment and AWS account in the organisation. A token with malformed constraints deploys as if unconstrained, because enforcement ignores what it cannot parse. Re-mint either one with constraints in the web app. list and revoke work with any authenticated credential. There is no create subcommand: minting is session-only, so the constraints (application, environment, connected account) and the expiry are chosen in the web-app mint dialog.
fjall ci token manages CI deploy tokens, which mint short-lived AWS credentials for a pipeline. fjall token manages personal and agent API tokens, which authenticate a human or an agent to the Fjall API. They are separate surfaces. See fjall token.

​
Run a deploy from CI

fjall ci run <deploy|destroy|build> <target> [service] is the single CI entry point, the same command both official plugins invoke. It forces non-interactive output, skips confirmation prompts, and rejects flags that do not apply to the verb you are running. Passing --skip-build to a destroy is an error, not a silent no-op. Target resolution is explicit or it fails. ci run never falls back to an active target or to the application’s server-side account registration, so a committed activeTarget or another machine’s local state can never re-aim a pipeline. On ci run deploy, --environment does two jobs: it selects the account above, and it selects the .env.<stage> Docker build-arg tier for the build. ci run deploy and ci run destroy queue behind a held deployment slot for up to 20 minutes, polling every 30 seconds. That covers a sibling application deploy without burning the build. A long organisation cascade can still exhaust the budget, and the block message says how long it waited.
The positional <target> is an application name. Tier operations are noun-verb and have their own commands: fjall org deploy, fjall platform deploy, fjall account deploy. Passing a tier word to ci run is rejected.
The full flag table, exit codes (including 2 plan-pending and 4 destruction-gate), and provider examples live in CI/CD Integration → Raw CLI Usage.

​
Next Steps

CI/CD Integration

Full pipeline guide: plugins, tokens, AWS credentials, exit codes.

Engine Compatibility

How cli-version keeps the CI-installed CLI aligned with your constructs.

fjall token

Personal and agent API tokens, distinct from CI deploy tokens.

Destructive Changes

What exit code 4 means and how to clear the destruction gate in CI.