Initialization policy»
Warning
Initialization policies are deprecated. Use approval policies instead for a more flexible, powerful way to control which runs are allowed to proceed.
Existing users with initialization policies should migrate as soon as possible using our migration guide.
Initialization policies can prevent a run or a task from being initialized, blocking any custom code or commands from being executed.
They look like plan policies in that they affect existing runs and print feedback to logs, but they don't get access to the plan. Instead, initialization policices can be used to protect your stack from unwanted changes or enforce organizational rules concerning how and when runs are supposed to be triggered.
Warning
Server-side initialization policies are being deprecated. We will be replacing them with worker-side policies that can be set by using the launcher run initialization policy flag (SPACELIFT_LAUNCHER_RUN_INITIALIZATION_POLICY).
For a limited time period we will be running both types of initialization policy checks but ultimately we're planning to move the pre-flight checks to the worker node, thus allowing customers to block suspicious looking jobs on their end.
Let's create a simple initialization policy, attach it to a stack, and see what it does:
1 2 3 4 5 | |
This policy results in:

Rules»
Initialization policies only use a deny rule with a string message. A single result for that rule will fail the run before it has a chance to start, as shown above.
Data input schema»
Each policy request will receive this data input:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 | |
Aliases»
In addition to our helper functions, we provide aliases for commonly used parts of the input data:
| Alias | Source |
|---|---|
commit |
input.commit |
run |
input.run |
runtime_config |
input.run.runtime_config |
stack |
input.stack |
Use cases»
There are two main use cases for run initialization policies:
Protect your stack from unwanted changes»
Although Spacelift is specialized, you can run custom code before the Terraform initialization phase using before_init scripts. This is a very powerful feature that must be handled responsibly. Since those scripts get full access to your Terraform environment, someone could, in theory, create a commit on a feature branch that would run terraform destroy -auto-approve.
Initialization policies can help you avoid unwanted runs. That's where initialization policies can help. This example policy explicitly blocklists all Terraform commands if they're running as before_init scripts and adds a single exception for a formatting check:
1 2 3 4 5 6 7 8 | |
What if someone, to get around this policy, creates a Docker image that symlinks something very innocent-looking to terraform? You have two choices: replace a blocklist with an allowlist, or make sure that a known good Docker is used to execute the run. Here's an example:
1 2 3 4 5 6 7 | |
Danger
If you're using an image other than what Spacelift controls, you'll be responsible for ensuring that the attacker can't push bad code to your Docker repo.
Enforce organizational rules»
Run initialization policies can also be used enforce best practices, ensuring that the right things get executed the right way and at the right time.
One of the above examples explicitly allowlisted an OpenTofu/Terraform formatting check. This example policy ensures that command always gets executed first. Per the Anna Karenina principle, this check is most elegantly defined as a negation of another rule matching the required state of affairs:
1 2 3 4 5 6 7 8 9 10 | |
Enforce feature branch naming convention»
Now let's enforce a feature branch naming convention. We'll keep this example simple, requiring that feature branches start with either feature/ or fix/, but you can require references to Jira tickets or even look at commit messages:
1 2 3 4 5 6 7 8 | |
Migration guide»
A run initialization policy can be expressed as an approval policy if it defines a single reject rule, and an approve rule that is its negation. Here are the initialization policy examples expressed as approval policies.
Enforcing OpenTofu/Terraform check»
1 2 3 4 5 6 7 8 9 10 | |
Disallowing before-init OpenTofu/Terraform commands other than formatting»
1 2 3 4 5 6 7 8 | |
Enforcing runner image»
1 2 3 4 5 6 7 | |
Enforcing feature branch naming convention»
1 2 3 4 5 6 7 8 9 | |