Skip to main content
Interactive command. At a TTY, fjall target set with no name walks an account picker and a region picker, and fjall target list / fjall target get render the active target’s detail card. Pass --non-interactive for plain-text output. From fjall 32, naming a target sets it directly either way; on fjall 31 a name at a terminal opens the pickers anyway, so setting a named target there takes --non-interactive.

Overview

A target is a deployment destination: one connected AWS account paired with one of your organisation’s configured regions. The active target decides where fjall deploy lands and which credentials fjall aws exec mints. Targets are derived at runtime from your organisation config, which Fjall fetches from the API. Accounts, regions and role ARNs are never authored by hand in a repository file. See Understanding Profiles for how a target becomes an AWS profile.

Prerequisites

fjall target get reads the local active target first, so it still prints a name when the organisation config cannot be fetched. It adds (Could not fetch organisation config for details) instead of the account and region.

Usage

Bare fjall target dispatches to list. Every subcommand also accepts -v, --verbose, --non-interactive, and the agent-output flags --agent, --budget <level>, --fields <list> and --full. See Agent mode.

Target names

A target name is the lowercased account name followed by an abbreviated region:
The abbreviation is the first region segment, a short code for the compass direction, and the trailing number. From fjall 32, compound directions get two letters (southeast is se, northeast is ne) and so does south (so), which keeps ap-south-1 and ap-southeast-1 apart.
Asia Pacific target names change in fjall 32. ap-southeast-*, ap-northeast-*, ap-south-*, af-south-1, eu-south-* and me-south-1 abbreviated to a single direction letter before that, which gave ap-southeast-1 and ap-south-1 the same name. The table above carries the fjall 32 names; on fjall 31 those regions still take the single letter, so ap-southeast-2 is aps2 rather than apse2. From fjall 32 a target name using an old code is refused with the replacement to use, never resolved to a region you did not name. Run fjall target list for the current names, then fjall target set <name> to re-point. Every other region is unaffected.
Account names can contain hyphens, so acme-prod-use1 is the account acme-prod in us-east-1.

How the list is derived

Fjall crosses every connected account with every configured region:
  • Accounts: every connected account except the organisation (management) tier. Platform-tier accounts are included.
  • Regions: your organisation’s primary region, its secondary regions, and its disaster recovery region.
  • Order: environment, then account name, then region.
Adding a region to your organisation config therefore adds one new target per account.

List targets

Each row is the target name followed by its environment, account name and region. The active target carries a marker and a bold name.

Readiness annotations

fjall target list probes each target and annotates the row. The probe is advisory: it never fails the command. The IPAM pool is only part of the check for an organisation that has a management account. A solo connected account is judged on its stack alone. When some targets could not be probed, the output closes with a dim Readiness not checked for 1 of 2 targets: no AWS session line. Deploy the missing stack with fjall org deploy, or fjall account deploy when your organisation has no management account.

Empty results

The second case is not an error. Run fjall target set and pick a region: selecting one adds it to your organisation’s regions.

Show the active target

With no active target, the command prints No active target set. Use 'fjall target set <name>' to set one. and still exits 0. If the recorded name no longer resolves to a connected account, the status is stale and the output carries Target no longer exists in organisation config. That happens when the account was disconnected, renamed, or promoted to the organisation tier. Run fjall target set again.

Set the active target

From fjall 32, naming a target sets it directly, at a TTY or not. On fjall 31 add --non-interactive, or the pickers open and the name is ignored. Run fjall target set with no name to choose the account and region from pickers instead.

Options

Choosing a region your organisation has not registered

Target names are resolved against every AWS region, not only the configured ones. Setting a target in an unregistered region therefore has a side effect: the region is written back to your organisation config, where it becomes available to every account and is included in organisation deploys. Fjall never does that silently.
The region picker lists your configured regions plus an Other region… row. Picking an unregistered region raises a confirmation before anything is written:
Confirming prints Adding eu-west-1 to your organisation's regions..., then the usual confirmation card.
The write is composed from a fresh read of the organisation config, so a region another machine or the web app added in the meantime is never reverted. If the region turns out to be configured already, nothing is written and the command succeeds.
When your organisation has no primary region yet, the region you pick becomes the primary region rather than a secondary one. The interactive prompt and the --yes advisory both say so, and the wording changes to <region> will become your organisation's primary region. Add it?. A primary region cannot be changed after your first successful deploy, so read the prompt before confirming.

Running outside a Fjall project

The active target is stored per checkout, so fjall target set needs a project to anchor it to. With no fjall-config.json in the current directory or any parent, the command refuses rather than planting a stray config:
Interactively the same situation raises a confirmation instead: Create the config here or Cancel. A freshly scaffolded fjall/<app>/infrastructure.ts layout is exempt, because its first target set legitimately writes the project’s first config.

Readiness after a set

Once the target is saved, Fjall probes it and prints one line: The unready line is a full sentence, for example:
An unready target is a warning, not a refusal. The target is still set.

Where the active target is stored

fjall target set writes activeTarget to .fjall/local.json, a git-ignored file beside fjall-config.json. The choice is per developer and per checkout, so a colleague’s target and a CI pipeline’s never inherit yours.
An activeTarget inside the committed fjall-config.json is legacy. Fjall reads it only to print a deprecation warning, then behaves as if no target were set. Delete it from the committed file and run fjall target set <name> instead.

Agent output

--agent emits structured records for all three subcommands. target get reports status as active, stale or none. target list also carries a totalCount aggregate and the active target’s name.

Handling failures

Next Steps

Understanding profiles

How a target becomes an AWS profile, and how a deploy resolves its account.

Run AWS commands

Use fjall aws exec --target <name> to run any AWS command with minted credentials.

Deploy an application

Ship an application to the active target.

Connect an account

Add the AWS accounts that targets are derived from.