Docs / Build your stack

Stack kits

Planned Committed, and built after the first stage. Everything below is the planned design.

Most sites need the same building blocks: a database, object storage, backups, monitoring and a way to deploy applications. Stack kits: reusable infrastructure blueprints are how TractorStack plans to package those blocks once and use them on many sites. A kit is a versioned definition of a whole stack, written as code, that an environment repository pins to a specific release, much like an application pins a library version.

Stack kits: reusable infrastructure blueprints

A kit bundles the OpenTofu modules, Ansible roles, Compose files and, for later stages, Helm charts that belong together. It doesn’t hold any site’s addresses, names or passwords. Those come from the environment that uses it, through settings and secrets.

The first kit we plan is a base data platform kit. It is intended to contain:

• A PostgreSQL role with pgBackRest backups to S3-compatible storage
• RustFS with buckets for backups, artifacts and mirrors
• The nightly test restore into a scratch container, and its report
• Host hardening and monitoring agents from the Ansible baseline

Later kits would add things like a Patroni PostgreSQL cluster for stage 2 or the Kubernetes application layer for stage 3.

How an environment uses a kit

The environment repository refers to a kit by name and version, and supplies its own values. A planned example, not taken from a release:

# Planned example only: kits.yaml in an environment repository
kits:
  - name: base-data-platform
    version: 1.4.2
    inputs:
      postgres_version: "17"
      backup_bucket: backups-plant-a
      restore_test_schedule: "02:30"

Upgrading a kit is a normal change request: change the version, read the plan and the check output, get approval, apply. Nothing moves to a new kit version on its own.

Rules every kit follows

1. Pinned versions everywhere. Container images, OpenTofu providers, Ansible collections and charts are pinned to exact versions. No :latest, no floating tags.
2. Documented inputs and outputs. Each kit lists what it needs (with types and defaults) and what it exposes, such as hostnames and connection details that the next kit can use.
3. A tested restore. A kit that holds data isn’t released until a backup made by it has been restored in a test environment, and that test is repeated for each new version.
4. Kubernetes-ready. Applications and services inside a kit follow the Kubernetes-ready rules, so moving a site up a stage changes the runtime, not the kit’s contract.
5. Release notes that say what changes. Every version states what it does to running systems, whether a restart is needed and how to go back.

Your own kits

Kits are planned to be ordinary Git repositories with tags, so you can write your own for internal applications and keep them on your own GitLab server. The same rules apply. A kit you write for a payroll system and one we write for PostgreSQL should look alike to anyone reviewing a change.

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