TractorStackby InfraTractor
In development · On-premise

From one server to Kubernetes, on hardware you own.

TractorStack is a set of tested building blocks for running applications and data on your own servers. Start with Docker Compose on a single machine. Grow to Kubernetes when you actually need it, without rewriting your apps or moving data in a hurry.

Talk to us about a pilotRead the design docs

TractorStack is being built now. This page shows what is planned and how far each part has got. Nothing here is available to install yet.

Four stages: one server with Docker Compose, a second host for resilience, Kubernetes for applications with data on virtual machines, and everything on Kubernetes
The building blocks

Open tools you can run yourself.

Every part is a well-known open-source tool, configured as code in a Git repository you keep. No cloud account and no subscription to our servers is needed to run it.

OpenTofu

Creates the virtual machines, disks and networks on your hypervisor, such as Proxmox VE or VMware vSphere.

Ansible

Hardens the operating system, installs Docker or Kubernetes, configures every service and runs the routine checks.

Docker Compose

Runs the services on one or two hosts. Simple to read, simple to operate.

PostgreSQL

Your application data, with backups to on-site storage. Also keeps OpenTofu’s state, so it never leaves your building.

RustFS

S3-compatible object storage on your own disks, for backups, files and artifacts.

Valkey or Redis

Added only when an application needs a cache or a fast queue. Many setups won’t.

Roadmap

Four stages, built in order.

Most organizations will stop at stage 2 or 3, and that is fine. Each stage keeps the same repository and the same tools, so moving up is a planned step rather than a rebuild.

1

Standalone

One server or virtual machine, running everything with Docker Compose.

  • OpenTofu and Ansible to build and harden the host
  • PostgreSQL, RustFS and optional Valkey
  • Nightly backups to RustFS, and an automatic test restore to prove they work
  • A one-page status report
In design
2

Resilient standalone

A second host, so one failure doesn’t mean days of recovery.

  • PostgreSQL streaming replica on the second host
  • RustFS on its own disks, with copies off-site, for example in a Tier III facility
  • A written, tested failover runbook
Planned
3

Kubernetes for applications

Applications move to a small cluster. Databases and storage stay on their own virtual machines, where they are easiest to run.

  • RKE2 or k3s, installed and upgraded by Ansible
  • Applications deployed from Git with Helm charts
  • Load balancing and certificates for an on-premise network
Planned
4

Everything on Kubernetes

For larger platforms where running data services outside the cluster becomes the bottleneck.

  • PostgreSQL run by an operator, restored from the same backups as stage 1
  • RustFS on dedicated storage nodes
  • Scheduling for GPU workloads
Exploring

Across every stage.

Routine checks

Restore tests, patching with a test group first, certificate and disk checks, and drift detection.

Planned

Works offline

Local mirrors for packages, container images and OpenTofu providers, for networks without internet access.

Planned

Compliance evidence

Configuration evidence saved automatically on every run and mapped to the controls it supports.

Exploring

Hardware setup

Server firmware and BIOS settings through Redfish, before the operating system is installed.

Exploring
In designbeing specified and built nextPlannedcommitted, after the stage before itExploringbeing evaluated, may change

Last updated 25 October 2026.

How it stays simple

Ready for Kubernetes from day one.

Stage 1 runs on Docker Compose, but it follows the same rules a Kubernetes deployment needs. That is what makes moving up a change of runtime instead of a rewrite.

  1. No state on local disk. Data lives in PostgreSQL, RustFS or Valkey, reached over the network.
  2. Configuration from environment variables and secrets, with the same names in Compose and Kubernetes.
  3. Health and readiness checks on every service, and clean shutdowns.
  4. Images from your own registry, with pinned versions.
  5. Logs to standard output and metrics in a standard format, so monitoring carries over.
  6. Backups to S3 storage from the start, so later stages can restore what stage 1 saved.

Want to run it first?

We are looking for a few organizations to pilot TractorStack on their own hardware, with InfraTractor engineers working alongside your team.

Email sales@infratractor.com