Docs / Make changes safely

Change requests & sign-off

In design Being designed now, alongside stage 1. Everything below is the planned design.

Nothing in a TractorStack environment is meant to change because someone logged in and typed a command. Change requests, approvals and sign-off are how every change is planned to happen instead: a merge request on your self-hosted GitLab, an automatic preview of what will change, approval by a named person who didn’t write it, and an apply of exactly what was reviewed. The result is an audit logging trail you get as a side effect of normal work.

Change requests, approvals and sign-off

1. Merge request. Someone edits the environment repository on a branch and opens a GitLab merge request. The description says why, not just what.
2. Preview. GitLab CI runs on the site runner. It runs tofu plan and saves the plan file, and runs Ansible with --check --diff. Both outputs are attached to the merge request.
3. Review. A named approver reads the plan and the diff. If either shows something unexpected, the merge request goes back.
4. Approval. The approver approves in GitLab. The author can’t approve their own change.
5. Apply. After merge, the pipeline applies the saved plan and runs the Ansible playbook for real.
6. Record. The merge request, the plan, the approval and the job log stay linked in GitLab, and a summary is written to the audit trail.

Apply what was reviewed, nothing else

The plan the approver read is the plan that runs. OpenTofu supports this directly: tofu plan -out=plan.bin writes a plan file and tofu apply plan.bin applies only that. If the infrastructure or state changed in between, OpenTofu refuses the saved plan as stale, and the merge request needs a fresh preview and a fresh look.

Ansible has no saved plan, so the design pins the run to the merged commit and the same inventory used for the check. A plan file can contain sensitive values, so it is stored as a short-lived job artifact on site and, where possible, encrypted with OpenTofu’s plan encryption.

Who can approve

• Each environment lists its approvers in the repository, by name. Production usually has fewer than test.
• GitLab’s merge request approval settings are planned to block approval by the author and to reset approvals when new commits are pushed.
• The default branch is protected, so nobody pushes to it directly, including administrators in normal work.

Some approval features, such as required approval rules, depend on your GitLab edition. Where they aren’t available, the design adds a pipeline check that refuses to apply without a recorded approval from someone other than the author.

Limits of the dry run

A preview is good evidence, not a guarantee. Some Ansible modules don’t support check mode and are skipped, and some tasks depend on results from earlier tasks that didn’t really run. A tofu plan can’t tell you whether an application will like its new disk. That’s why risky changes still go to a test environment first, as described in sites and environments.

Emergencies

Sometimes a person has to fix something by hand at 3am. The design accepts that and asks for two things afterwards: write the change into the repository through a normal merge request, and let the next drift check confirm the code and the system agree again. An emergency fix that never reaches Git will keep showing up as drift until it does.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com