Stage 1: Standalone

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.

In design This stage is being specified and built next. Everything below is the planned design.

Stage 1 is one server or one virtual machine, running your applications and their data services with Docker Compose. It is where most organizations should start, and for some it will be enough for years.

What runs where

OpenTofu creates the virtual machine, its disks and network on Proxmox VE or vSphere. On bare metal this step is skipped.
Ansible hardens the operating system (users, SSH, host firewall, time sync, logging), installs Docker and deploys the Compose stacks.
Docker Compose runs the platform services and your applications on that one host.

Data services and applications sit in separate Compose projects on separate named networks. Applications reach PostgreSQL and RustFS by name, as they would in a cluster later.

Planned Compose services

Service	Purpose
PostgreSQL	Application data, and OpenTofu’s state
RustFS	S3-compatible object storage for files, artifacts and backups
Valkey	Optional; only when an application needs a cache or fast queue
Container registry	Your own images, with pinned versions
Reverse proxy	TLS termination using certificates from the internal CA
Monitoring	Metrics in Prometheus format, logs from standard output

A planned example, illustrative only and not from a release:

# compose/data/compose.yaml (planned example)
services:
  postgres:
    image: registry.local/postgres:17.2
    env_file: postgres.env
    healthcheck:
      test: ["CMD", "pg_isready"]
    restart: unless-stopped
    networks: [data]
  valkey:
    image: registry.local/valkey:8.0
    profiles: [cache]
    networks: [data]
networks:
  data: {}

Valkey sits behind a Compose profile, so it only starts when you ask for it. Many setups won’t need it. See Docker Compose and Valkey and Redis.

Backups and the nightly test restore

PostgreSQL is backed up nightly with pgBackRest to a bucket in RustFS, using the standard S3 API. A backup you have never restored is a hope, not a backup, so the design adds a second job: after each backup, restore it into a scratch container, start PostgreSQL, run a few sanity queries and record the result. The scratch container is then thrown away.

Because backups go to S3 from day one, a later stage can restore what stage 1 saved. On one host, though, the backups share the server’s fate. Copy them off the machine; stage 2 makes that part of the design. More in Backups.

The status report

A one-page report, produced on a schedule, is planned to answer the questions an owner actually asks: did last night’s backup and test restore succeed, how full are the disks, when do certificates expire, are there pending security updates, and does tofu plan show anything changed outside Git.

Sizing

We haven’t published sizing figures, and won’t until pilots give us real numbers. As a rough starting point: size the disks for your data plus several copies of its backups, give PostgreSQL enough memory to keep its working set cached, and leave headroom for the test restore, which briefly needs room for a second copy of the database. Mirrored disks are worth having even on one server.

What stage 1 is not

It is not highly available. If the host fails, services are down until it is repaired or rebuilt from backups.
It is not a cluster, and doesn’t pretend to be one.
It is not a dead end. Following the Kubernetes-ready rules from the start keeps stage 2 and stage 3 open without a rewrite.

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