How it fits together

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.

This page describes the planned design. TractorStack is in development and none of it is installable yet.

TractorStack is planned as six layers, built from the bottom up. Each layer is handled by one well-known tool, and all of it is described as code in a Git repository the customer keeps. Nothing in the design depends on a cloud service or on InfraTractor’s own servers.

The six layers

Layer	What it covers	Tools
L0 Network and site	VLANs, firewall rules, DNS and DHCP, an internal certificate authority	OpenTofu, Ansible
L1 Hardware	BIOS and iDRAC/iLO settings, firmware inventory through Redfish, PXE install Exploring	Ansible
L2 Virtualization	Virtual machines, disks and networks on Proxmox VE or VMware vSphere	OpenTofu
L3 OS and hardening	CIS-style baseline, users and SSH, host firewall, time sync, logging, Docker	Ansible
L4 Platform services	PostgreSQL, RustFS, optional Valkey or Redis, container registry, mirrors, monitoring with Grafana, backups	Ansible, Docker Compose
L5 Applications	Docker Compose stacks in stages 1 and 2, Helm charts deployed from Git in stages 3 and 4	Docker Compose, Helm

For Proxmox VE the design uses community OpenTofu providers such as bpg/proxmox. For vSphere it uses the hashicorp/vsphere provider. The layers above L2 shouldn’t care which hypervisor is underneath.

One Git repository per environment

Each customer environment is planned to live in a single Git repository. Production and a test environment would each get their own. Everything needed to rebuild the environment is in it, apart from secrets, which are referenced rather than committed.

A planned example layout, not taken from a release:

# planned layout (illustrative)
tofu/          VMs, disks, networks
ansible/       OS hardening, data services,
               Kubernetes install, routine checks
compose/       application stacks (stages 1-2)
k8s/           Helm charts and GitOps apps (stages 3-4)
runbooks/      failover, restore, upgrades

The Ansible inventory is generated from OpenTofu outputs, so a VM created in tofu/ appears in Ansible without anyone typing its address twice. See OpenTofu and Ansible for detail.

How a change flows

No one changes production by hand. The planned flow for every change, from a new VM to a firewall rule, is:

Merge request. Someone edits the repository on a branch in the customer’s self-hosted GitLab and opens a merge request.
Dry run. The pipeline runs tofu plan for infrastructure changes and ansible-playbook --check --diff for configuration changes, and posts the output on the merge request.
Approval. A second person reads the plan, not just the code, and approves the merge request.
Apply. After merge, the same GitLab pipeline runs tofu apply or the playbook for real. From stage 3, Argo CD applies Kubernetes changes from the same repository.

The dry run is the important step. It shows what will be created, changed or destroyed before it happens, and it doubles as a record of who approved what.

Drift is caught the same way. A scheduled tofu plan that shows changes means something was altered outside Git, and the routine checks will report it.

Where state and backups live

Everything stays on-site.

OpenTofu state is planned to use OpenTofu’s pg backend, stored in your own PostgreSQL. OpenTofu 1.7 and later can also encrypt state on the client side before it is written.
Application data lives in PostgreSQL, files and artifacts in RustFS, and cache or queue data, if any, in Valkey.
Backups go from PostgreSQL to RustFS through pgBackRest, using the standard S3 API. From stage 2, copies also go to a second site, for example a Tier III colocation facility you control.

Because backups use plain S3 from the start, a later stage can restore what stage 1 saved. More on this in Backups and Security.

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