fjall migrate runs one-off migrations that bring deployed stacks onto current fjall contracts. It has one subcommand, identity.
This command does not run database or schema migrations. Application database migrations run as part of a deploy, and
fjall deploy --skip-migrations controls them.fjall migrate identity pins the capacity identity of a deployed pre-6.0 application into fjall-config.json, so later synths reproduce the deployed resource names byte-for-byte and a rename-safe deploy stays rename-safe.
Prerequisites
Prerequisites
- The Fjall CLI installed and signed in. Run
fjall loginfirst, the command authenticates before it does any work. - A connected AWS account holding the deployed stacks. Connect one with
fjall connect. - An application with an
infrastructure.ts, created byfjall create application. - A shell in the fjall project root, so the CLI can detect application targets. Without
--app, a single detected application is used, and several require you to name one. - An account and region that map to a configured deploy target. Check with
fjall target list. Pins are keyed by target name, so a session that matches no target cannot write them.
Pin deployed capacity identity
fjall deploy --target does:
What Happens
The command runs a gate-before-write ceremony. Nothing reaches disk until every candidate pin passes.1
Resolve the application
--app must name a detected local application target. Without it, a single detected application is used. Several detected applications produce an error listing them.2
Authenticate and resolve credentials
The command requires an authenticated session.
--target resolves credentials exactly as fjall deploy --target does. --region overrides the region.3
Synthesise with existing pins
The application is synthesised with any pins already in
fjall-config.json applied, mirroring how a deploy threads capacity identity into the assembly.4
Compute the plan against live templates
The synthesised assembly is diffed against the live CloudFormation templates. A synthesised stack with no live counterpart is recorded and skipped rather than failing the run.
5
Gate the candidate pins
Candidate pins are injected as CDK context, never written to disk first. The application is re-synthesised and the identity-surface gate runs over every pinned slot, both new candidates and pre-existing pins.
6
Write, all or nothing
Pins are written to
fjall-config.json under capacityIdentity[appName][targetName][slot] only when every candidate passes. One failing slot means no pins are written at all.fjall-config.json change. Pins travel with the project, and deleting one renames every stateful resource in its slot.
Dry runs
There is no dry-run flag. The gate-before-write ceremony gives you the equivalent safety: a run that refuses any candidate writes nothing, reports the failing slot and its gate failures, and exits with code 1.Nothing to pin
Three outcomes report no work rather than an error:Exit codes
Agent mode
With--agent, the command emits a structured result instead of the human report. The result name is one of:
The payload carries
app, accountId, region, targetName, clean, duration, plus outcomes and verified arrays when the report has them. Dependency-gate warnings arrive as structured warning events rather than stderr diagnostics.
Options
All options belong to theidentity subcommand. The fjall migrate group itself accepts only --non-interactive and -v, --verbose.
Empty values are rejected at the boundary.
--app "" and --target "" fail validation rather than falling back to auto-detection.
Next Steps
fjall deploy
Deploy the application once its pins are committed.
Destructive Changes
The rename and consent ceremony that pins protect against.
fjall drift
Detect and repair resources changed outside CloudFormation.
fjall validate
Check infrastructure.ts before the next deploy.