Set up approval rules

Approval rules let you define who must review and approve a ChangeSet before it can be applied to an environment. Without at least one matching rule, ChangeSets can be applied immediately. With rules in place, a ChangeSet is blocked until the required number of designated people have approved it.

This is one of the key governance controls in CloudBooster — it ensures that changes to sensitive resources always get a second pair of eyes.

Before you begin

• You must be an owner or admin in the project.
• Organisation members must already be invited before you can select them as eligible approvers.

Open the approval rules settings

Navigate to Project → Settings → Approval Rules. This tab shows all rules defined for the project.

How rules work

When a ChangeSet is created, CloudBooster evaluates every approval rule in the project against the ChangeSet's target environment and the component types it touches. If a rule matches, it becomes a required gate.

A ChangeSet is ready to apply only when every matching rule has collected enough approvals from its eligible approvers.

Create an approval rule

Click Add rule. The rule form has these fields:

Name

A descriptive label for the rule — for example, "Production database approvals" or "Security team sign-off". Shown in ChangeSet review screens.

Required approvals

The minimum number of approvals the rule needs before the gate clears. Must be at least 1 and at most the total number of eligible approvers you select.

Allow self-approval

When disabled (the default), the person who created the ChangeSet cannot count their own approval toward this rule. This prevents a single person from bypassing review by proposing and approving their own change.

Eligible approvers

Choose the organisation members who may approve ChangeSets covered by this rule. At least one must be selected.

Applies to environments (optional)

Leave empty to fire on every environment. Select specific environments to restrict the rule — for example, to require extra approval only for production.

Applies to component types (optional)

Leave empty to fire on every change. Add one or more component type patterns to restrict the rule to changes that touch matching resources.

Patterns follow an aws:category/type@version format and support * as a wildcard:

You can type a pattern directly or start typing to see suggestions from the component registry. Press Enter or click Add to commit each pattern.

Import rules from a codeowners file

If your team already maintains a codeowners-style file that maps component type patterns to reviewers, you can import it directly.

Click Import codeowners and paste a block in this format:

# Each line: <component-type-pattern> <user-uuid> [<user-uuid>…]
aws:iam/*       a1b2c3d4-0000-0000-0000-000000000001
aws:kms/*       a1b2c3d4-0000-0000-0000-000000000001 a1b2c3d4-0000-0000-0000-000000000002
aws:security/*  a1b2c3d4-0000-0000-0000-000000000001

Lines starting with # are treated as comments. Each non-comment line becomes one approval rule. The Required approvals and Allow self-approval settings you choose in the modal are applied uniformly to every imported rule.

Click Preview parse to verify that the block parses cleanly before committing. Any invalid lines are shown with an error before anything is created.

Edit or delete a rule

All rules are listed in a table. Click Edit to change any field. Click Delete to remove a rule — pending approvals attributed to a deleted rule no longer count toward any ChangeSet.

Disabled rules

A rule can be disabled without deleting it. Disabled rules are shown with a Disabled badge and do not block ChangeSets.

See also

• ChangeSets — the artifact that approval rules gate.
• Projects and environments — how projects and environments relate.
• Organisation members — how to invite teammates before adding them as approvers.