Skip to main content
  • The Fjall CLI installed, running on Node 22 or newer.
  • A signed-in session. Run fjall login first. Credentials live at ~/.fjall/auth.json (or $FJALL_CONFIG_DIR/auth.json).
  • At least one deployment triggered from the CLI, from CI, or from the web app.
  • cancel and force-release act on a deployment id, which fjall deployments list prints in the ID column.
  • force-release additionally requires the organisation owner or admin role.

​
Inspect your organisation’s deployments

A bare fjall deployments prints help.

​
What Happens

​
fjall deployments list

Reads your organisation’s deployments over the Fjall API and prints them most recent first. The server returns the 30 most recent rows. The command takes no filter or window flags. Rows print with a trailing count. With nothing to show, the command prints No active or recent deployments and exits 0. The read needs the applications:read scope, and a constrained token sees only rows whose application or account match its constraints.

​
fjall deployments cancel <id>

Writes a cancellation intent against the row. The outcome depends on what is holding the slot. When a refused row has reported no progress for more than five minutes, the CLI prints the exact force-release command to run next, including the id to retype as --confirm. Cancellation is co-operative, so it is a request, not an instant kill. The command exits 0 on a refused remote cancel, because a refusal is an answered question rather than a failure. The API allows 10 cancels per minute per organisation.

​
fjall deployments force-release <id>

Marks a demonstrably silent occupying deployment as failed so a blocked deploy can claim the slot. Three gates apply, all server-side:
  1. The caller holds the organisation owner or admin role.
  2. --confirm <id> matches the deployment id exactly. A mismatch is refused.
  3. The row has reported no progress, no status write and no event, for at least five minutes. A row that reported progress inside that window is refused, as is a paused row awaiting a human decision.
Every force-release writes an audit event carrying the actor, the deployment id and the masked --reason text. The API allows 10 force-releases per minute per organisation.
Force-release frees the Fjall slot. It does not stop the remote machine. If that machine is still alive it keeps deploying, and CloudFormation’s per-stack lock is the only thing left protecting the stack. Run fjall deployments cancel <id> first and reach for force-release only when the machine is gone.

​
Agent mode

Add --agent to any of the three subcommands for structured output. deployments list exposes id, status, target, source, startedAt and triggeredBy, plus a total aggregate. --fields selects exactly those names, and an invalid selection fails fast, before the authentication round-trip is spent. None of the three commands has a dry-run flag. list is read-only, cancel writes an intent the deploying machine acts on, and force-release writes a terminal status. An older Fjall server that does not offer one of these routes returns a capability notice and exit code 0 rather than an error, so a script can probe for support safely.

​
Options

Every subcommand carries the shared flag set. --confirm and --reason belong to force-release only. The bare fjall deployments command carries --non-interactive and -v, --verbose alone.

​
Next Steps

fjall deploy

Deploy an application, and read the flags that gate a destructive change.

fjall releases

List the recorded releases for an application and find the current one.

fjall rollout

Restart running services so rotated secrets take effect, with no rebuild.

Deployment safety

Understand slots, approval gates and how Fjall protects a live stack.