Docs / Grow in stages
Moving between stages
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.
TractorStack is planned so that moving from one stage to the next is a reviewed change in your repository, not a rebuild. This page covers when a move is worth it, how each component would move, and how to rehearse it and roll it back. It describes the planned design; nothing here is released yet.
When to move
Stay on Compose (stage 1 or 2)
Docker Compose is the right place if you run a handful of services, one team deploys them, and a short maintenance window for updates is acceptable. Add the second host of stage 2 as soon as losing one server for days would hurt.
Move to stage 3 when two or more apply
- More than about ten services, or several teams deploying independently.
- You need zero-downtime rolling updates.
- Your workloads need more than one or two hosts.
- You need to schedule GPU workloads.
- A contract expects Kubernetes.
One reason on its own usually has a simpler fix. Ten services from one team can still run happily on Compose.
Move to stage 4 only when
Running PostgreSQL or RustFS outside the cluster has become the bottleneck. See stage 4 for what that looks like. Most organizations won’t reach this point.
How each component moves
| Component | Stage 1 to 2 | Stage 2 to 3 | Stage 3 to 4 |
|---|---|---|---|
| Applications | No change | Compose service becomes a Helm chart with the same images and environment variable names | No change |
| PostgreSQL | Add a streaming replica on the second host | No change; stays on VMs | Operator-managed cluster, seeded from S3 backups or a replica, then cut over |
| RustFS | Move to its own disks; add off-site copies | No change; stays on VMs | StatefulSet on storage nodes; copy buckets with S3 tools |
| Valkey | Optional replica, or accept a cold restart | No change; stays on VMs | Runs in the cluster; usually safe to start empty |
| Ingress | Reverse proxy on the active host | MetalLB address, ingress controller and cert-manager replace the reverse proxy | No change |
| Storage | Local disks on each host | Nodes hold no data | Longhorn, Rook-Ceph or local volumes |
The pattern is deliberate: each move changes one kind of thing. Stage 3 moves applications and leaves data alone. Stage 4 moves data and leaves applications alone.
What makes this possible
The Kubernetes-ready rules apply from stage 1. If an application writes files to local disk or reads a config file baked into its image, fix that first, while it is still on Compose and easy to test. Backups go to S3 from the start, so a later stage can restore what an earlier one saved.
Rehearse first
Every move is planned to be rehearsed in a test environment built from the same repository on a branch:
- Build the target stage alongside the current one.
- Restore the latest production backup into it.
- Deploy the applications and run their smoke tests.
- Time the cutover steps, and write down anything the runbook missed.
Repeat until the cutover is boring.
Roll back
Keep the old stage running until the new one has been live for an agreed period. For stage 2 to 3, rolling back means pointing DNS back at the Compose host; the data never moved, so there is nothing to copy back. For stage 3 to 4, keep the PostgreSQL VMs as a replica of the new cluster, or at least keep their final backup, until you are confident. Decide in advance what would trigger a rollback, and who makes the call.
If you are weighing a move, email sales@infratractor.com.
Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com