Docs / Start

Your first pilot

TractorStack is still in development, so there is nothing to download yet. Getting started with TractorStack: how a pilot works is the honest answer today. We take one of your sites, build the first stage of the platform on your own hardware with you, and keep every line of it in a Git repository you own. This page explains what we need, what the first weeks look like and what you have at the end.

Getting started with TractorStack: how a pilot works

A pilot is a small, fixed piece of work on one site. It usually aims at stage 1: one server or VM running Docker Compose, with PostgreSQL, RustFS and a nightly backup that is restored and checked automatically. If you already know you need more, we can plan towards stage 2 from the start, but we’d rather get one site right before adding hosts.

Because the platform is being built alongside the pilots, you will see parts of the design change. We tell you when something you rely on moves, and the roadmap shows what is built, in design, planned or still being explored.

What we need from you

• Hardware or hypervisor details. The design targets Proxmox VE first, or the infrastructure you already run. Tell us what you have: a Proxmox VE cluster, VMware vSphere or another hypervisor, or bare-metal servers, with models, specs and the resources you can set aside for the pilot.
• Your network layout. VLANs, address ranges, DNS, firewall rules between segments, and whether the site can reach the internet or needs to work offline.
• Who approves changes. At least one named person on your side who reviews and signs off changes before they are applied. See change requests for how that works.
• A home for the repository. A self-hosted GitLab instance if you have one. If you don’t, setting one up on site is part of the pilot.
• One or two applications to move. Something real but not your most critical system, so the pilot tests actual workloads without putting the business at risk.

The first weeks

1. Survey. We go through the hardware, network and applications with your team and write down what exists, including the things nobody wrote down before.
2. Repository and runner. We create the environment repository and set up the site runner, so changes run from your site with credentials that stay there.
3. Build. On Proxmox VE, OpenTofu creates the VM. On vSphere it manages what that platform exposes, and on existing machines Ansible starts directly. Ansible then hardens the OS and installs the data services, and your applications move into Compose stacks that follow the Kubernetes-ready rules.
4. Prove recovery. We run a full backup and restore and record the result, then hand over the runbooks under runbooks/.

The exact length depends on the site. A single server with a tidy network goes faster than three buildings with undocumented VLANs, and we would rather agree a realistic plan than promise a date we can’t keep.

What you get at the end

• A working stage 1 site, with backups that have been restored at least once.
• The environment repository, with every VM, setting and stack written as code.
• Runbooks for the common problems, and a one-page status report.
• A written view of whether and when moving to a later stage makes sense for you.

Everything stays yours. If you stop working with us, the repository, the state and the running services stay on your hardware and keep working.

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