Guardrail checks

Planned design. TractorStack is in development. This page describes how it is designed to work; nothing here is available to install yet. See the roadmap for the status of each part.

Planned Committed, but not built yet. Everything below describes the planned design.

Some mistakes are too costly to leave to a reviewer’s attention on a busy afternoon. TractorStack’s answer is policy as code: guardrail checks before apply that read the planned change and stop it if it breaks a rule you have agreed on. The rules live in your repository next to the infrastructure they protect, are reviewed like any other code, and run in every pipeline between the plan and the approval.

Policy as code: guardrail checks before apply

The checks work on the plan, not on the source code. tofu show -json turns a saved OpenTofu plan into JSON that lists every resource and every value that will be set. A policy tool reads that JSON and returns pass, warn or fail. Checking the plan rather than the code matters: the plan includes defaults, module outputs and values from variables, which are exactly where surprises hide.

The design uses Open Policy Agent, an open-source policy engine, with Conftest, a command-line tool that runs OPA policies against structured files such as JSON or YAML. Policies are written in Rego, OPA’s policy language. The same approach can check Kubernetes manifests rendered from Helm charts and Compose files, so one set of tools covers each layer.

Example rules

These are the kinds of rules we expect most customers to start with. The list is illustrative; your rules depend on your network and your obligations.

No admin ports on public networks. SSH, RDP, database ports and hypervisor management interfaces may not be reachable from a network marked as public or untrusted.
Pinned image versions. Every container image uses a fixed version from your own registry. :latest and untagged images fail. This is also one of the Kubernetes-ready rules.
Backups enabled. Any new database or bucket that holds data must be included in the backup configuration.
No unexpected destroys. A plan that destroys or replaces a VM holding data needs an explicit label on the merge request saying the destroy is intended.
Resource limits set. VMs and containers declare CPU and memory, so one service cannot starve the rest.

# planned example: one rule in Rego
package tractorstack.network

deny contains msg if {
  rule := input.firewall_rules[_]
  rule.source == "public"
  rule.port in {22, 3389, 5432, 8006}
  msg := sprintf("port %d open to a public network", [rule.port])
}

The example is a sketch to show the idea, not a policy from a release. Real input shapes depend on the provider and module.

Blocking and warning

Not every rule deserves to stop work. The design has two levels:

Level	What happens	Good for
Block	The pipeline stops; the change cannot be approved until the plan passes	Rules with no good exceptions, such as admin ports on public networks
Warn	The finding is shown on the merge request; a reviewer decides	Rules with occasional valid exceptions, or new rules being trialled

A sensible way to add a rule is to start it as a warning, watch what it flags for a few weeks, fix the false alarms, then make it blocking. Exceptions to a blocking rule are planned to be written in the repository, with a reason and an expiry date, so they are reviewed and don’t become permanent by accident.

Guardrails catch what you can describe in advance. They don’t replace a person reading the plan; see change requests and sign-off. Results of every check are kept in the audit trail and can feed evidence packs.

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