Skip to main content

​
Overview

fjall rollout restarts an application’s running ECS services in place. Tasks read their SSM secrets when they start, so a rotated value only reaches your application once its tasks relaunch. A rollout registers a fresh task-definition revision (with the containers unchanged) and rolls each service — no image build, no CDK deploy, typically a minute or two instead of a full deploy. After fjall secrets set or fjall secrets import, the CLI offers to run this for you (Apply to <app>'s running services now? (Y/n)).

​
Usage

Before confirming, the CLI shows which services are running with stale secrets — SSM parameters modified since the service’s tasks last launched:

​
Options

​
What a Rollout Does (and Doesn’t)

  • Does relaunch every running task in the target services, so new tasks re-resolve their /<app>/<cluster>/<service>/ SSM values.
  • Does record a release (operation restart) with the SSM parameter versions that were applied, so the webapp’s release history shows exactly what went live.
  • Doesn’t build or push an image, change your infrastructure, or pick up new secret keys — a new key needs a full fjall deploy <app> so the task definition gains the reference.
Rolling out applies whatever the current SSM values are. If several people are editing secrets, check fjall secrets list --app <app> first — the restart picks up all changes, not just yours.
  • fjall secrets — set, import, and delete the values a rollout applies
  • fjall releases — release history and image rollback
  • fjall deploy — full build-and-deploy, needed for new secret keys or code changes