CoursesAtlantisIntermediate

Custom workflows & steps

Shape plan/apply commands.

Advanced12 min · lesson 6 of 12

A workflow defines the exact steps Atlantis runs for plan and apply. The default workflow is essentially terraform init, plan, and apply, but you can customize it — add a terraform fmt check, run a security scan or policy check between plan and apply, wrap in a different tool (Terragrunt), or run pre/post scripts. Workflows are defined and referenced by name, and a project selects which workflow it uses.

workflow (server-side)
workflows:
scan-then-apply:
plan:
steps:
- init
- plan
- run: checkov -f $PLANFILE.json --compact # scan the plan
apply:
steps:
- apply
# a project references it: workflow: scan-then-apply

Custom steps and Terragrunt

The run step executes an arbitrary command with useful variables ($PLANFILE, $WORKSPACE, $DIR) available, which is how you insert linting, policy, notifications, or a wrapper. Teams using Terragrunt define a workflow that calls terragrunt instead of terraform. This flexibility is powerful and is exactly why controlling where workflows may be defined matters — a run step executes with the server’s credentials, so an untrusted custom workflow is code execution on your Atlantis host.

terragrunt workflow
workflows:
terragrunt:
plan: { steps: [ { run: "terragrunt plan -out=$PLANFILE" } ] }
apply: { steps: [ { run: "terragrunt apply $PLANFILE" } ] }
A run step is arbitrary code execution on the server
Custom workflow run steps execute shell commands on the Atlantis host with its cloud credentials — so allowing repos to define their own workflows means a PR can run arbitrary code with those credentials. Define workflows server-side and forbid repo-side workflow definitions for untrusted repos (allowed_overrides / allow_custom_workflows), so only reviewed, operator-controlled steps ever run.