Stage 3: Kubernetes for apps

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.

Planned Committed, and built after stage 2. Everything below is the planned design.

Stage 3: on-premise Kubernetes for applications. Applications move from Docker Compose to a Kubernetes cluster of three or more nodes, installed and upgraded with Ansible and fed by Argo CD from your self-hosted GitLab. Databases and object storage don’t move. They stay on their own virtual machines, managed by Ansible exactly as in stage 2.

Self-managed on-premise Kubernetes for applications

TractorStack is built around its own self-managed Kubernetes stack, installed, configured and upgraded by Ansible from the customer repository. There is no vendor distribution in the middle and nothing to license. The nodes are VMs created by OpenTofu on Proxmox VE first, or on the infrastructure you already run, including bare metal.

The Ansible roles are planned to cover the standard pieces: a container runtime, CNI networking, the control plane and worker nodes, and the add-ons below. Upgrades go one node at a time, draining workloads first, and run as a normal change request so the plan is reviewed before anything moves.

Some customers ask about packaged distributions such as RKE2 or k3s. They are reasonable alternatives, but the TractorStack design and its runbooks are written for the self-managed stack.

Why data stays on VMs

Running PostgreSQL and object storage inside Kubernetes is possible, but it adds a lot to learn at once: storage classes, operators, pod disruption budgets, and how all of them behave during an upgrade. Stage 3 changes one thing, the application runtime, and leaves the data where it already works, including the Patroni cluster from stage 2.

This is where the Kubernetes-ready rules pay off. Applications already keep no state on local disk, read configuration from environment variables with the same names, and reach PostgreSQL, RustFS and Valkey over the network. Moving them is a change of deployment format, not a rewrite. The cluster nodes hold nothing you would need to restore.

Deploying with Argo CD from GitLab

Each application gets a Helm chart under k8s/ in the customer repository on GitLab. Argo CD watches the repository and applies what is merged. The change flow is the same as everywhere else in TractorStack: a merge request, a diff of what will change, approval, then Argo CD syncs it. See Git as the source of truth.

A planned example of the layout, illustrative only:

# k8s/ (planned example)
k8s/
  apps/
    billing/        Helm chart and values
    portal/
  argocd/           Argo CD application definitions
  platform/
    metallb/
    ingress/
    cert-manager/

Images come from your own registry with pinned versions, so a deploy is reproducible and works without internet access once the offline mirrors are in place.

On-premise networking

Public clouds hand you load balancers and certificates. On your own network, those need a few extra pieces:

MetalLB gives Kubernetes services real IP addresses from a range on your network, so a service of type LoadBalancer works on VMs or bare metal.
An ingress controller routes HTTP and HTTPS traffic to applications by host name, behind a MetalLB address.
cert-manager issues and renews TLS certificates. On a closed network it can use the internal certificate authority from layer L0 rather than a public one.

Firewall rules and DNS records for these addresses are planned to live in the same repository, under OpenTofu or Ansible, so the network and the cluster stay in step.

Before you move

Stage 3 is worth it when you have two or more of the reasons in Moving between stages. If you have one service and one team, a cluster mostly adds things to patch.

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