Docs / Start
Roadmap & status
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 is the TractorStack roadmap and status for every part of the platform, in one list. TractorStack is built in four stages, in order, and most organizations will stop at stage 2 or 3. Each stage keeps the same GitLab repository and the same tools, so moving up is a planned step rather than a rebuild.
One part works today, inside InfraTractor. Nothing is available to install yet.
How to read the TractorStack roadmap and status labels
| Status | Meaning |
|---|---|
| Built | Exists and works internally. Not yet packaged for customers. |
| In design | Being specified and built next. The shape is mostly settled; details are still moving. |
| Planned | Committed, built after what it depends on. The approach is chosen but not yet detailed. |
| Exploring | Being evaluated. It may change a lot, or be dropped if it doesn’t prove useful. |
Built Working internally
- PostgreSQL high availability with Patroni: a multi-node PostgreSQL cluster with automatic failover. Also see PostgreSQL.
In design Next up
- Stage 1: Standalone: one server with Docker Compose, nightly backups and a test restore.
- Change requests and sign-off: every change proposed, reviewed and approved by a named person.
- Where state lives: OpenTofu state in PostgreSQL, encrypted and on site.
- Settings and variables: how an environment is configured.
- Sites and environments: how repositories are laid out.
- Secrets and credentials: storage, use and rotation.
- Audit trail: who changed what, and who approved it.
- Data protection: encryption, access and backups.
- Your data stays on site: data residency by design.
- Kubernetes-ready rules: six rules stage 1 follows.
Planned Committed
- Stage 2: Resilient: storage on its own disks, off-site copies and site-loss drills, around the built database cluster.
- Stage 3: Kubernetes for apps: self-managed Kubernetes installed by Ansible, apps deployed by Argo CD.
- Stack kits: reusable, versioned stack definitions.
- The site runner: runs OpenTofu and Ansible on site.
- Delivery pipelines: GitLab CI for plans, checks and applies.
- Git as the source of truth: GitOps with GitLab and Argo CD.
- Guardrail checks: policy as code before apply.
- Drift checks: nightly detection of changes made outside Git.
- Alerts: who is told what, and when.
- Monitoring: metrics, logs and dashboards on site.
- Backups and restore tests: off-site copies from stage 2.
- Fixing common problems: runbooks with first checks.
- Offline and air-gapped: local mirrors for packages, images and providers.
Exploring Being evaluated
- Stage 4: All on Kubernetes: data services in the cluster, GPU workloads.
- Rollout waves: one change across many sites, in steps.
- Automation tokens: narrow, expiring tokens for scripts.
- AI-assisted review: plain-language explanations of a planned change.
- Capacity and cost planning: sizing hardware per stage.
- Teams and tenants: separation for teams and MSP customers.
- Sign-in and SSO: single sign-on for platform services.
- Evidence packs: compliance evidence for CMMC and NIST SP 800-171.
- Hardware setup: firmware inventory and BIOS settings through Redfish, then a PXE install.
What could change
Order is firmer than dates. We won’t start stage 3 before stage 2 works, and items marked Exploring may look quite different by the time they are built. If one of them matters to you, tell us at sales@infratractor.com; pilot feedback is what moves things up the list.
Last updated 25 October 2026.
Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com