Docs / Build your stack

Docker Compose

Docker Compose runs a group of containers from one YAML file. In TractorStack it is the runtime for stage 1 and stage 2: one or two hosts, a handful of services, and a team that wants to read the whole setup in one sitting.

Why Compose first

Most small and mid-sized deployments don’t need a cluster scheduler. Compose is easy to debug, needs nothing extra running, and every engineer who has used Docker can follow it. The roadmap moves to Kubernetes only when there is a clear reason, and the Compose files are written so that move is a translation, not a rewrite.

Role in each stage

• Stage 1: applications run in Compose. PostgreSQL and RustFS are planned to run either in Compose or directly on the host via Ansible; the design is still being settled. In design
• Stage 2: the same files, with the data services split onto their own host or disks. Planned
• Stage 3 and later: applications move to Helm charts. Compose files stay in the repository as the reference until the move is done.

What the planned files include

• Healthchecks on every service, so depends_on can wait until a dependency is actually ready rather than just started.
• Restart policies, usually unless-stopped, so services come back after a reboot or crash.
• Named networks that separate the public-facing proxy from the data services.
• Env files and secrets: plain settings in an env file, passwords as Compose secrets mounted as files, never baked into images.
• Pinned images from your own registry, by version tag or digest, never :latest.

Planned configuration

A short planned example of one application service. It is illustrative and not from a release.

# Planned example only: compose/app.yaml
services:
  app:
    image: registry.example.internal/app:1.4.2
    env_file: app.env
    secrets: [db_password]
    networks: [front, data]
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:8080/healthz"]
      interval: 15s
      retries: 3
networks:
  front: {}
  data: {}
secrets:
  db_password:
    file: ./secrets/db_password

How it maps to Kubernetes later

This only works cleanly if the app follows the Kubernetes-ready rules from day one, above all keeping no state on local disk and reading the same variable names in both places. See moving between stages.

What stays yours

• The compose/ directory and your application images
• Secret files, which stay on the host and out of Git

Limits and caveats

• Compose has no rolling updates. Restarting a service means a short outage for it.
• It does not move containers between hosts. If the host dies, recovery is the failover runbook in stage 2, not an automatic reschedule.
• Compose secrets from files are not encrypted at rest. Host permissions and disk encryption matter.

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