Execution modes

Every Stack has an execution mode: it decides how a change gets applied relative to merging its pull request. It changes only the apply trigger — a pull request still gets a plan-only check in every mode, so reviewers always see what would change. Pick it in the Stack’s Settings; new Stacks start at merge_then_apply.

The four modes

merge_then_apply (default) — a pull request gets a plan check; merging it plans on the tracked branch and parks at awaiting approval. A human reads the plan and approves, and then it applies. Nothing applies unattended.

branch_apply — apply from the pull request, before you merge. Review the plan on the PR, apply it straight from the branch, and merge afterward. The merge itself does nothing — the change is already live. Your tracked branch stays equal to what is actually applied, so if an apply goes wrong you revert by re-applying the branch. See Branch apply below.

auto_apply — merging plans and applies immediately, with no approval gate. Fits low-stakes Stacks where the review is the pull request.

manual — nothing runs from a push or a merge. Plans and applies happen only when you ask, from the Console or CLI — zero runner minutes until you do.

Destroy Runs are the exception to all of this: they are manual-only and always require approval, whatever the mode.

Branch apply

Under branch_apply, the apply is triggered from the open pull request:

• From the PR check. Each touched Stack’s Longbridge Stacks / <stack> check carries an Apply button once its plan is ready. Clicking it applies that Stack — the button lives on that Stack’s own check, so there is nothing to target by hand in a monorepo.
• From the Console. The Run page has the same Apply button, and it is how you apply outside a pull request — for example, to re-apply the tracked branch as a revert.

What applies is the reviewed plan, pinned: there is no re-plan at apply, so what you approved is what runs. If the state moved since you planned — a sibling PR applied, or someone ran tofu apply from a laptop — OpenTofu refuses the stale plan and you re-plan. Applies to one Stack serialize, so two pull requests can both plan but never apply over each other.

Before an apply is allowed, the pull request must be:

• mergeable — it passes your branch protection, including any required approvals. Four-eyes is GitHub’s “require N approvals” rule; Stacks does not run a second approval system.
• undiverged — the tracked branch has not moved past the commit you planned.

Separately, a grant decides who may apply a given Stack, independent of the pull request’s state.

Automerge

A branch_apply Stack can automerge: once every apply-capable Stack a pull request touches has applied cleanly and GitHub reports the PR mergeable, Stacks merges it for you, using the repository’s own merge method. It is off by default and set per Stack; if any touched Stack has it off, a human merges.

Require an apply before merge

Turn on require apply before merge — a per-Stack setting, meaningful only under branch_apply — and Stacks publishes an apply-status check that you can mark required in branch protection. GitHub then blocks merging a pull request that has not applied, so the tracked branch never falls behind live infrastructure and no second apply is needed on merge. A monorepo pull request that does not touch the Stack passes the check automatically.

Migrating from auto-apply

If you used Stacks before execution modes, the old per-Stack auto-apply toggle became this setting: auto-apply on is now auto_apply, and auto-apply off is now the default merge_then_apply. Nothing about how your Stacks already behave changed.