Skip to main content
Fjall authenticates with your AWS accounts using OpenID Connect (OIDC) or AWS IAM Identity Center (SSO). No long-lived access keys are stored, and you never author a profile by hand. Fjall derives every profile in memory from your organisation config, and never reads or writes ~/.aws/config.

​
Prerequisites

  • Fjall CLI installed and logged in (fjall login).
fjall login writes your Fjall credential to ~/.fjall/auth.json (or $FJALL_CONFIG_DIR/auth.json). That file holds one API key, so the CLI is signed in to one organisation at a time. Set FJALL_CONFIG_DIR to keep a second organisation’s state separate on the same machine.

​
How credentials are derived

The CLI fetches your organisation config from the Fjall API and derives AWS profiles from it at runtime. There is no fjall profile command and no profile file to edit. OIDC applies whenever an account carries its own role. SSO covers organisation members that do not, and becomes available once fjall org deploy has resolved your IAM Identity Center instance.

​
1. Establish OIDC trust

fjall connect is the only command that establishes AWS trust. fjall create organisation and fjall create account scaffold project files locally. Neither opens a browser and neither deploys anything to AWS. Both journeys run the same connect step:
Interactively, fjall connect prompts only for what it cannot already determine: the primary AWS region (skipped when your organisation already has one), the environment for this account, and the account name. It then opens your browser on an AWS CloudFormation quick-create link, polls until the stack completes, and validates the OIDC trust. The first connect after fjall create organisation skips the region and environment prompts, and registers the account as the AWS Organizations management account. The derived OIDC profile is available as soon as validation succeeds.

​
Connect options

With --no-wait, the CLI prints the quick-create URL and an external id. Resume polling once the stack is submitted:
The stack creates one role, FjallDeploy<orgId>, holding AdministratorAccess and capped by default with a Fjall-managed permissions boundary. What the role can actually do is the intersection of the two. See fjall connect for the full command reference, including fjall reconnect, the boundary’s governance tiers and denies, and how to turn it off.

​
2. Add SSO for organisation members

Enable IAM Identity Center in the management account first. AWS does not let CloudFormation or the API create the instance, so it is a one-time click in the console. See Enable IAM Identity Center.
Run fjall org deploy. It discovers the IAM Identity Center instance you enabled in the console (sso:ListInstances). From that point, every member account without its own OIDC role derives an AdministratorAccess SSO profile per account and region. You do not configure SSO start URLs, account IDs, or role names by hand. Before the organisation deploy runs, no SSO profile exists yet. See Understanding Profiles for the full derivation model.

​
3. Choose where deploys land

A deployment target is an account and region pair, named <accountname>-<regionabbrev>: the account name lowercased, then the region short code (us-east-2 becomes use2, eu-west-1 becomes euw1). The default organisation scaffold declares Production, Staging, Development, Platform and BusinessContinuity accounts, so a us-east-2 organisation derives production-use2, staging-use2, and so on. List every derived target. The active one carries a ▸ marker, a row may carry ✓ ready or ! not ready — <reason>, and a trailing Active: line names it:
Read the active target on its own:
Switch the active target before deploying:
fjall target set writes activeTarget to .fjall/local.json, a gitignored file beside fjall-config.json. It is per-machine state and is never committed, so it cannot re-aim a colleague’s deploy or a CI pipeline.

​
What fjall target set checks

At deploy time, Fjall resolves the account in one fail-closed order: an explicit --target <name>, then the active target from .fjall/local.json, then auto-selection when exactly one target exists (or the root profile when there are none). If none of those resolve, the deploy stops and lists the valid targets. An unknown --target name is a hard error, never a silent fallback. Use -r, --region to override the region within the resolved account. In account mode with a single connected account, Fjall selects the target for you.

​
What you end up with

  • One AWS account carrying OIDC trust, or a full organisation once fjall org deploy completes.
  • Profiles derived on every command, with no access keys on disk.
  • An active deployment target, so fjall deploy <app> knows which account and region to use.

​
Next Steps

Understanding Profiles

How Fjall derives OIDC and SSO profiles

Deploy Organisation

Create and deploy your AWS organisation

Connect an AWS Account

Add or recover an AWS account connection

Deploy an Application

Ship your first application to AWS