Fjall Docs — deploy AWS infrastructure into your own account

Interactive command. Opens your browser to deploy an OIDC CloudFormation stack, then waits for the stack to report back.

Usage

fjall connect [options]
fjall connect status [options]
fjall reconnect [awsAccountId]

fjall connect establishes an OIDC trust between Fjall and one AWS account. Use it to:

Register the AWS Organizations management account, the first connect after fjall create organisation.
Connect a standalone AWS account after fjall create account.
Add another member account to an existing organisation.

fjall create organisation and fjall create account only scaffold project files. Neither establishes AWS trust, so fjall connect is a separate step in both journeys.

Prerequisites

Authenticated with fjall login.
Permission in the target AWS account to create IAM roles and CloudFormation stacks.
Signed in to the target AWS account in your browser.

What It Does

Checks for existing connections and reads your organisation config.
Opens your default browser on an AWS CloudFormation quick-create link.
The stack creates an IAM OIDC provider and a role that Fjall assumes on demand.
Polls until the stack completes, printing an elapsed-time line.
Validates the OIDC trust and records the connection against your organisation.

The four progress steps are Checking existing connections, Opening AWS CloudFormation, Waiting for CloudFormation, and Validating OIDC connection.

What This Creates in Your Account

fjall connect deploys one CloudFormation stack, FjallOIDCConnector. Every resource it creates carries the tags fjall:managed=true and fjall:org-id=<your organisation id>.

Resource	Name	What it is
IAM OIDC identity provider	`fjall.io`	Federation endpoint for `https://fjall.io`, audience `sts.amazonaws.com`. A `Custom::FjallOIDCProvider` resource adopts the account’s existing provider when there is one, and creates it otherwise
IAM role	`FjallDeploy<orgId>`, at path `/fjall/`	The role Fjall assumes. Attached policy `AdministratorAccess`, capped by default by the permissions boundary below, `MaxSessionDuration` 3600
Customer-managed IAM policy	`FjallDeployBoundary<orgId>`	The permissions boundary applied to the deploy role
Three Lambda functions, each with its own role	`FjallOIDCProviderFn<orgId>`, `FjallDeployBoundaryFn<orgId>`, `FjallOIDCCallback<orgId>`	Custom-resource handlers that adopt the provider, publish the boundary, and POST the role ARN back to Fjall. The first two are scoped to the single IAM ARN each writes, the third has Lambda basic execution only

<orgId> is your Fjall organisation id, so the deploy role’s ARN is arn:aws:iam::<account id>:role/fjall/FjallDeploy<orgId>.

The deploy role holds AdministratorAccess

The deploy role’s attached managed policy is arn:aws:iam::aws:policy/AdministratorAccess. Fjall provisions VPCs, ECS services, RDS and Aurora clusters, S3 buckets, Lambda functions, CloudFront distributions, Route 53 zones, ACM certificates, IAM roles and CloudFormation stacks, and a hand-scoped policy would break every time Fjall adds a resource type. AdministratorAccess is attached to exactly one role in the stack. What that role can actually do is AdministratorAccess intersected with the permissions boundary, so read the two documents together.

The permissions boundary is on by default

The boundary is a customer-managed policy named FjallDeployBoundary<orgId>. The template’s FjallPermissionsBoundary parameter controls whether it is applied: it accepts true or false and defaults to true. fjall connect sets it to true explicitly on the quick-create link it opens, so a stale published template cannot drop the cap. A boundary is an intersection, not a grant, so the document leads with Allow on */* and then denies actions no deploy or destroy performs. The set of denies is a governance tier. Three tiers exist and they are cumulative: foundation is a subset of compliance, which is a subset of hardened. The quick-create template has no tier parameter, so fjall connect always installs hardened, and hardened is also what the CDK equivalent renders when no tier is set. The tier only ever changes which ceiling the role gets, never whether it has one.

From tier	Denied	Actions
`foundation`	Leaving the organisation, closing the account	`organizations:LeaveOrganization`, `account:CloseAccount`
`foundation`	Turning off CloudTrail	`cloudtrail:StopLogging`
`foundation`	Escaping its own boundary	`iam:DeleteRolePermissionsBoundary` anywhere, and `iam:PutRolePermissionsBoundary` on `role/fjall/FjallDeploy` and `role/cdk--cfn-exec-role-` unless the replacement is a `FjallDeployBoundary` policy
`foundation`	Tampering with the boundary policy	`iam:CreatePolicy`, `iam:CreatePolicyVersion`, `iam:DeletePolicyVersion`, `iam:SetDefaultPolicyVersion`, `iam:DeletePolicy` on `policy/FjallDeployBoundary*`
`foundation`	Disabling a KMS key	`kms:DisableKey`
`compliance`	Minting standing human credentials	`iam:CreateUser`, `iam:CreateLoginProfile`, `iam:CreateAccessKey`, `iam:CreateAccountAlias`
`compliance`	Stopping the AWS Config recorder	`config:StopConfigurationRecorder`
`hardened`	Weakening the account password policy	`iam:UpdateAccountPasswordPolicy`, `iam:DeleteAccountPasswordPolicy`
`hardened`	Turning off default EBS encryption	`ec2:DisableEbsEncryptionByDefault`

Every deny names an action CloudFormation never performs on your behalf, which is why they are narrower than they look: cloudtrail:StopLogging and not DeleteTrail, kms:DisableKey and not ScheduleKeyDeletion, config:StopConfigurationRecorder and not DeleteConfigurationRecorder. Destroying a trail, a key or a recorder as part of a stack teardown still works. The full document is in the reference below. To pick a tier other than hardened, see the governance profile on fjall create organisation.

The boundary policy is an account-global singleton

FjallDeployBoundary<orgId> is one policy per AWS account, shared by every Fjall stack in it, and it is deliberately not owned by any stack. A Custom::FjallDeployBoundary resource adopts the policy by name when it already exists and creates it otherwise, exactly as the OIDC provider resource does. That shape is what makes connecting a second account, or re-connecting an existing one, safe. A stack-owned managed policy could never be deleted once cdk bootstrap had capped an execution role with it (DeleteConflict), and a retained one would fail the next connect with EntityAlreadyExists. The writer only ever publishes a document matching one of the three tiers, and it will not weaken a policy that is already in place:

Deploying the same tier is a no-op — nothing is written.
Deploying a tighter tier converges the policy in place as a new default version. IAM caps a policy at five versions, so the oldest non-default version is rotated out first.
Deploying a looser tier fails the stack update rather than lowering the ceiling. Widening is an administrator action, run from a principal outside the boundary.

The ratchet compares the set of denied actions, not statement scope — a policy someone has tightened by hand at the resource or condition level converges back to its tier on the next deploy. If a tier upgrade is interrupted. CloudFormation gives a custom resource one attempt. If the writer publishes the tighter tier but its response is lost, the stack times out and rolls back, re-presenting the previous tier — and the ratchet refuses it, because the policy now carries the tighter document. The stack lands in UPDATE_ROLLBACK_FAILED, always on the stricter side. Recover with the same credentials that ran the deploy:

aws cloudformation continue-update-rollback \
  --stack-name FjallOIDCConnector \
  --resources-to-skip FjallDeployBoundaryPolicy

then re-run the connect or deploy that carried the tier change; it finds the policy already at the target tier and writes nothing. FjallDeployBoundaryPolicy is the resource’s logical id in the quick-create template; a CDK-rendered connector uses the hashed id of its DeployBoundary construct, which aws cloudformation list-stack-resources shows. Setting the policy’s default version back by hand is not an alternative for the deploy role: iam:SetDefaultPolicyVersion on the boundary is one of the actions the boundary denies to itself, so that path is administrator-only.

The CDK execution role is capped by the same policy

Fjall deploys through CDK, which assumes its own bootstrap execution role, cdk-hnb659fds-cfn-exec-role-<account id>-<region>. That role also holds AdministratorAccess, so capping the deploy role alone would leave the hand-off wider than the role that made it. Every fjall bootstrap therefore looks for FjallDeployBoundary<orgId> in the account and, when it is there, passes it to cdk bootstrap as the execution role’s boundary. That is the second entry in the boundary’s own self-protection scope, role/cdk-*-cfn-exec-role-*. The two roles are capped on different schedules, because the policy has to exist before a bootstrap can point at it. See two-pass convergence for what that means on a new account and how to check where you are.

Turning the boundary off

There are two opt-outs, one per lane, and both are create-time decisions:

Lane	Opt-out
`fjall connect` quick-create	Launch the template with `FjallPermissionsBoundary` set to `false`
The CDK `Account` construct	`deployRoleBoundary: false` in `fjall/account/infrastructure.ts`

Either one renders no boundary policy and leaves FjallDeploy<orgId> holding AdministratorAccess with nothing above it. Because the policy is also what caps the CDK execution role, opting out uncaps both roles: nothing then stops a mistaken or compromised deploy leaving the organisation, closing the account, stopping CloudTrail, disabling a KMS key, or minting IAM users with standing credentials.

You cannot switch the boundary off after the fact. The boundary denies iam:DeleteRolePermissionsBoundary, so a role that is already capped cannot be uncapped by a deploy — setting deployRoleBoundary: false on a bounded role fails the stack update. Removing an existing cap is an administrator step: aws iam delete-role-permissions-boundary on each bounded role, run from a principal outside the boundary, then aws iam delete-policy.Turning it back on is self-service: re-run fjall connect with the parameter at its true default, or drop deployRoleBoundary: false from fjall/account/infrastructure.ts and redeploy.

deployRoleBoundary is not called permissionsBoundary on purpose. CDK’s own permissionsBoundary on StackProps is a different, stack-wide mechanism; this one governs the FjallDeploy role only. Setting both securityTier and deployRoleBoundary: false contradicts itself and fails at synth rather than silently picking one.

What the boundary does not stop

The boundary is a ceiling on accidental and negligent CloudFormation actions, and on the direct self-edits in the table above. It is not a hard cap against a hostile session that already holds the deploy role. That session still has AdministratorAccess minus the denies, so it could assume an unbounded role that already exists in the account — OrganizationAccountAccessRole exists in every member account — rather than escalating in place. Treat the boundary as one layer. The others are the OIDC trust policy above it (the deploy role is assumable only by your organisation’s subjects), the one-hour session cap, and, in an organisation, the service control policies the Enforced governance profile installs.

Sessions last one hour

MaxSessionDuration on the deploy role is 3600 seconds. Credentials are minted per operation and are not refreshed while a command runs, which is why fjall aws exec caps --timeout at 1h (default 10m). Split longer work into shorter phases.

Development accounts get four extra resources. When --environment development is passed, the stack also creates the managed policy FjallDevBoundary and the roles FjallDevDeploy<orgId>, FjallDevProvisioner<orgId> and FjallDevSyncWriter<orgId>. The three roles carry narrow inline policies scoped to dev-tier resources, never AdministratorAccess. No other stage renders them.

The OIDC provider outlives the stack. An IAM OIDC provider is account-global, one per account and issuer URL, shared with the Fjall account-management stack and trusted by other Fjall roles. The custom resource acknowledges a CloudFormation delete without removing it, and the boundary policy is handled the same way.Deleting the FjallOIDCConnector stack therefore removes the deploy role but leaves the OIDC provider and FjallDeployBoundary<orgId> in place. A later connect adopts both instead of failing with EntityAlreadyExists. To restore an account whose connector stack was torn down, use fjall reconnect, which repairs trust in place without re-tiering or renaming the account.

Removing the boundary policy at end of life

Because no stack owns the policy, no stack deletion removes it. fjall org destroy does, as a reference-counted sweep: for each account, once that account’s stack is gone, it checks whether any role, user or group still lists FjallDeployBoundary<orgId> and deletes the policy only when nothing does. It never un-caps a role to make the delete succeed. The order matters, and it is why a first destroy pass usually leaves the policy behind:

Destroy the account’s stacks first. The FjallDeploy role goes with them, and while it exists it counts as a live reference.
The CDK execution role in every bootstrapped region carries the same policy, and it lives in the CDKToolkit stack, outside everything Fjall destroys. While any of those survive, the policy is retained by design.
Remove the bootstrap stacks — or un-cap those roles from an administrator principal — and re-run the destroy. The sweep then removes the policy.

A retention is never silent. The destroy transcript names the principal holding the reference and the cure:

Deploy boundary policy FjallDeployBoundary<orgId> retained in account <account id>: still referenced by role <name>. Remove the CDK bootstrap stacks (or un-cap the role from an administrator principal) and re-run the destroy to remove it.

A left-behind policy is harmless. It grants nothing on its own, and the next connect into that account adopts it.

Reference: the IAM documents the stack installs

Reference copies of the two policy documents, so you can diff them against the stack in the CloudFormation console before you create it. Both are shown with the template’s parameters named.

Parameter	Resolves to
`${FjallOrgId}`	Your Fjall organisation id
`${FjallIssuerDomain}`	`fjall.io`
`${FjallOIDCProvider.ProviderArn}`	`arn:aws:iam::<account id>:oidc-provider/fjall.io`
`${AWS::AccountId}`	The AWS account you are connecting

Trust policy on FjallDeploy<orgId>:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FjallMachineSubject",
      "Effect": "Allow",
      "Principal": { "Federated": "${FjallOIDCProvider.ProviderArn}" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${FjallIssuerDomain}:aud": "sts.amazonaws.com",
          "${FjallIssuerDomain}:sub": [
            "org:${FjallOrgId}:*",
            "org:${FjallOrgId}:acct:${AWS::AccountId}"
          ]
        }
      }
    },
    {
      "Sid": "FjallUserSubjects",
      "Effect": "Allow",
      "Principal": { "Federated": "${FjallOIDCProvider.ProviderArn}" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": { "${FjallIssuerDomain}:aud": "sts.amazonaws.com" },
        "StringLike": { "${FjallIssuerDomain}:sub": "org:${FjallOrgId}:user:*" }
      }
    },
    {
      "Sid": "FjallServiceSubjects",
      "Effect": "Allow",
      "Principal": { "Federated": "${FjallOIDCProvider.ProviderArn}" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${FjallIssuerDomain}:aud": "sts.amazonaws.com",
          "${FjallIssuerDomain}:sub": [
            "org:${FjallOrgId}:discovery",
            "org:${FjallOrgId}:connection",
            "org:${FjallOrgId}:org-setup",
            "org:${FjallOrgId}:dev-substrate-setup"
          ]
        }
      }
    }
  ]
}

Three details a reviewer should read carefully:

FjallMachineSubject matches on StringEquals, so org:${FjallOrgId}:* is an exact literal subject, not a wildcard. Only that sentinel and the account-scoped org:${FjallOrgId}:acct:${AWS::AccountId} match.
FjallUserSubjects matches on StringLike, so org:${FjallOrgId}:user:* does match any user subject in your organisation.
The template branches the trust policy on the account’s tier. Both branches currently render the document above.

Permissions boundary FjallDeployBoundary<orgId>:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FjallInheritAdministratorAccess",
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    },
    {
      "Sid": "FjallDenyOrgAndAccountEscape",
      "Effect": "Deny",
      "Action": ["organizations:LeaveOrganization", "account:CloseAccount"],
      "Resource": "*"
    },
    {
      "Sid": "FjallDenyDisableAuditLogging",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging"],
      "Resource": "*"
    },
    {
      "Sid": "FjallDenyBoundarySelfEscape",
      "Effect": "Deny",
      "Action": ["iam:DeleteRolePermissionsBoundary"],
      "Resource": "*"
    },
    {
      "Sid": "FjallDenyBoundaryReplace",
      "Effect": "Deny",
      "Action": ["iam:PutRolePermissionsBoundary"],
      "Resource": [
        "arn:*:iam::*:role/fjall/FjallDeploy*",
        "arn:*:iam::*:role/cdk-*-cfn-exec-role-*"
      ],
      "Condition": {
        "ArnNotLike": {
          "iam:PermissionsBoundary": "arn:*:iam::*:policy/FjallDeployBoundary*"
        }
      }
    },
    {
      "Sid": "FjallDenyBoundaryPolicyTamper",
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicy",
        "iam:CreatePolicyVersion",
        "iam:DeletePolicyVersion",
        "iam:SetDefaultPolicyVersion",
        "iam:DeletePolicy"
      ],
      "Resource": "arn:*:iam::*:policy/FjallDeployBoundary*"
    },
    {
      "Sid": "FjallDenyDisableKmsKey",
      "Effect": "Deny",
      "Action": ["kms:DisableKey"],
      "Resource": "*"
    },
    {
      "Sid": "FjallDenyStandingHumanCredentials",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateLoginProfile",
        "iam:CreateAccessKey",
        "iam:CreateAccountAlias"
      ],
      "Resource": "*"
    },
    {
      "Sid": "FjallDenyDisableConfigRecorder",
      "Effect": "Deny",
      "Action": ["config:StopConfigurationRecorder"],
      "Resource": "*"
    },
    {
      "Sid": "FjallDenyAccountPasswordPolicyTamper",
      "Effect": "Deny",
      "Action": [
        "iam:UpdateAccountPasswordPolicy",
        "iam:DeleteAccountPasswordPolicy"
      ],
      "Resource": "*"
    },
    {
      "Sid": "FjallDenyDisableDefaultEbsEncryption",
      "Effect": "Deny",
      "Action": ["ec2:DisableEbsEncryptionByDefault"],
      "Resource": "*"
    }
  ]
}

Interactive Flow

Run fjall connect with no flags in a terminal. It prompts only for what it cannot already determine:

Prompt	Shown when
`Select your primary AWS region`	The region is unknown (no `--region`, no organisation primary region)
`Select the environment for this account`	`--environment` was not passed
`What should this AWS account be called?`	`--name` was not passed. Leave blank to use the AWS account’s own name

After the prompts, the browser opens automatically. If it does not, the CLI prints If the browser doesn't open automatically, visit: <url>. On success the interactive frame shows the completed step list, the next command to run (fjall account deploy), and a docs link. The Account ID, Status, Region and External ID block belongs to the plain-CLI output (--non-interactive, --no-wait, or agent mode).

First connect after fjall create organisation. When the fjall/organisation scaffold exists locally and no AWS account has connected yet, Fjall skips the region and environment prompts and registers the account as the AWS Organizations management account (tier organisation). Only the name prompt is shown. A standalone fjall/account scaffold does not qualify, so a solo account is never silently rooted.

If the account is already connected and active, fjall connect short-circuits with AWS account already connected and exits without touching AWS.

Options

Option	Description	Default
`--region <region>`	AWS region for the CloudFormation stack.	Organisation primary region, or `us-east-2` when none is set
`--environment <env>`	Workload stage for this account: `production`, `staging`, `development`, `platform`, or `compliance`. Required in non-interactive mode, except on the first connect after `fjall create organisation`.
`--name <name>`	Human-readable name for the AWS account, for example `Production`. A trailing region short code (`-use2`) is rejected, because Fjall appends its own.	The AWS account’s own name
`--force`	Re-issue a fresh CloudFormation stack for a connection that already matches this (region, environment) pair, bypassing the idempotency short-circuit.
`--no-wait`	Return after the browser hand-off instead of blocking on CloudFormation. Forces plain CLI output even in a terminal.	Waits for the stack
`-v, --verbose`	Enable verbose logging.
`--non-interactive`	Force plain CLI output, no prompts and no Ink UI.

--environment platform is structural, not a workload stage. It registers the account on the platform tier, which hosts shared infrastructure such as IPAM and Transit Gateway. Platform accounts are filtered out of fjall accounts list, no application can target them, and deploying to one is a governance operation. Choose platform only for a genuine shared-services account.

The management account’s tier is set by context during organisation setup, never by --environment.

Agent options

For AI-agent and scripted use, connect and connect status also accept the standard agent flags:

Option	Description
`--agent`	Emit machine-readable agent output.
`--budget <level>`	Output verbosity budget for agent mode.
`--fields <fields>`	Restrict the output to named fields.
`--full`	Include the full result payload.

Examples

Interactive

fjall connect

Connect a named staging account

fjall connect --name Staging --environment staging --region ap-southeast-2

Non-interactive

--environment is required here. Without it the command fails with the valid stage list, unless this is the first connect after fjall create organisation.

fjall connect --environment staging --region ap-southeast-2 --non-interactive

Scripted, without blocking on CloudFormation

--no-wait returns as soon as the quick-create URL is issued, so a script can hand the URL to an operator and poll separately.

fjall connect --environment production --no-wait
fjall connect status --external-id <id> --wait

Re-issue a stack for an existing connection

fjall connect --force --region us-east-2 --environment production

Typical workflow

Standalone account:

fjall login              # 1. Authenticate with Fjall
fjall create account     # 2. Scaffold fjall/account/infrastructure.ts
fjall connect            # 3. Install OIDC trust in the AWS account
fjall account deploy     # 4. Provision the account tier
fjall create app         # 5. Scaffold an application
fjall deploy web         # 6. Deploy it

Organisation:

fjall login                # 1. Authenticate with Fjall
fjall create organisation  # 2. Scaffold fjall/organisation/infrastructure.ts
fjall connect              # 3. Register the management account
fjall org deploy           # 4. Create member accounts and provision every tier

Check Connection Status

fjall connect status reads the connection lifecycle, including accounts marked disconnected.

# Every connection in the organisation
fjall connect status

# One connection, by the external id printed by `fjall connect`
fjall connect status --external-id <id>

# Block until that connection completes or fails (12-minute cap)
fjall connect status --external-id <id> --wait

Option	Description
`--external-id <id>`	Report one connection’s lifecycle phase. 32 to 64 lowercase hex characters.
`--wait`	Block until that connection completes or fails. Requires `--external-id`.

The overview prints one row per connection as <account id> <status> tier=<tier> stage=<stage> <name>. The single-connection form prints Status, Phase, and, where the server supplies them, Reason, Cure and Account.

Restore a Disconnected Account

fjall reconnect restores OIDC trust for an account the scanner has marked disconnected, for example after the connector stack was torn down. It repairs trust in place, without re-tiering or renaming the account.

# Auto-selects when exactly one account is disconnected
fjall reconnect

# Or name the 12-digit account id
fjall reconnect 123456789012

Use fjall reconnect for a disconnected account and --force for a connection that is already active. The two cases are different and the CLI routes them separately.

Troubleshooting

Browser does not open

Copy the URL from the terminal output and open it manually, then sign in to the correct AWS account.

Stack deployment fails

Check that the AWS account can create IAM roles and CloudFormation stacks, then rerun fjall connect to re-open the browser flow.

Non-interactive run rejects `--environment`

--environment accepts workload stages only. Pass one of production, staging, development, platform or compliance. root is not a valid input, because the management account’s tier comes from context.

Connection already exists

fjall connect short-circuits on a matching active connection. To connect a different AWS account, sign in to that account in your browser and rerun. To re-issue the stack for the same account, region and environment, add --force.

Account shows as disconnected

Run fjall connect status to confirm the phase, then fjall reconnect to restore trust. --force is the wrong cure here.

The OIDC connection issues short-lived credentials, so no long-term secrets are stored. Fjall assumes the IAM role on demand through OpenID Connect federation, and never reads or writes ~/.aws/config.

Next Steps

Deploy an account

Run fjall account deploy to provision the account tier after connecting.

Deploy an organisation

Create member accounts and provision every tier with fjall org deploy.

fjall create

Scaffold an organisation, an account, or an application.

Understanding Profiles

See how AWS profiles and deployment targets are derived from org config.

​Usage

​Prerequisites

​What It Does

​What This Creates in Your Account

​The deploy role holds AdministratorAccess

​The permissions boundary is on by default

​The boundary policy is an account-global singleton

​The CDK execution role is capped by the same policy

​Turning the boundary off

​What the boundary does not stop

​Sessions last one hour

​Removing the boundary policy at end of life

​Reference: the IAM documents the stack installs

​Interactive Flow

​Options

​Agent options

​Examples

​Interactive

​Connect a named staging account

​Non-interactive

​Scripted, without blocking on CloudFormation

​Re-issue a stack for an existing connection

​Typical workflow

​Check Connection Status

​Restore a Disconnected Account

​Troubleshooting

​Browser does not open

​Stack deployment fails

​Non-interactive run rejects --environment

​Connection already exists

​Account shows as disconnected

​Next Steps

Deploy an account

Deploy an organisation

fjall create

Understanding Profiles

Usage

Prerequisites

What It Does

What This Creates in Your Account

The deploy role holds AdministratorAccess

The permissions boundary is on by default

The boundary policy is an account-global singleton

The CDK execution role is capped by the same policy

Turning the boundary off

What the boundary does not stop

Sessions last one hour

Removing the boundary policy at end of life

Reference: the IAM documents the stack installs

Interactive Flow

Options

Agent options

Examples

Interactive

Connect a named staging account

Non-interactive

Scripted, without blocking on CloudFormation

Re-issue a stack for an existing connection

Typical workflow

Check Connection Status

Restore a Disconnected Account

Troubleshooting

Browser does not open

Stack deployment fails

Non-interactive run rejects `--environment`

Connection already exists

Account shows as disconnected

Next Steps