Docs / Trust & compliance
Your data stays on site
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 A design principle that shapes every other part. Nothing is released yet.
Data residency with on-premise infrastructure is simple to state: your data lives on hardware you own, at sites you choose, and leaves only when you send it. TractorStack’s design treats that as a starting rule rather than an option. Application data, infrastructure state, backups and logs all stay on your machines, and nothing in the platform needs an outside service to keep running.
Data residency with on-premise infrastructure, item by item
| What | Where it is planned to live |
|---|---|
| Application data | PostgreSQL on your servers |
| Files and objects | RustFS on your disks |
| Infrastructure state | PostgreSQL, encrypted, on site. See Where state lives |
| Backups | RustFS on site, plus an off-site copy at a second site you pick |
| Logs and metrics | The on-site monitoring stack |
| Secrets and keys | The site runner and your secrets store |
| Configuration and history | Your self-hosted GitLab |
The hardware is Proxmox VE first, or the infrastructure you already run: vSphere, another hypervisor or bare-metal servers. Either way, the disks are yours.
Who this matters to
Some organizations have no choice. Health providers, government suppliers, defense contractors and banks often work under rules or contracts that say where data may be stored and who may reach it. Some countries require certain data to stay inside their borders. Others simply don’t want a third party between them and their own records. For all of them, keeping data on site is easier to explain to an auditor than a diagram of someone else’s regions and sub-processors.
No outside service in the running path
The design avoids anything that phones home. There is no hosted control plane, no licence server that has to be reachable, and no telemetry sent to InfraTractor. Plans and applies run on your site runner, pipelines run on GitLab Runners on site, and Argo CD pulls from your own GitLab, not from a public host.
Software still has to arrive from somewhere. Packages, container images and OpenTofu providers come in through local mirrors, which you can fill on a connected machine and carry across. That traffic goes in, not out. For networks with no internet access at all, see Offline and air-gapped.
TractorStack targets on-premise hardware and does not plan public-cloud engines.
Choosing the second site
From stage 2, backups are copied off site so the loss of one building isn’t the loss of everything. The design lets you name that site: a second office, a colocation facility in your own country, or removable media in a safe. The copies are encrypted before they leave, and the keys stay with you.
What residency doesn’t cover
- It isn’t legal advice. Check what your own rules require; we can help map the design to them.
- People matter as much as places. Remote admin access from another country can still count as transfer under some rules, so access control is part of the answer.
- Applications you deploy may call outside services themselves. The platform can show and restrict outbound traffic with firewall rules, but what an app sends is the app owner’s decision.
Proof that data stayed put is part of the audit trail and, later, evidence packs.
Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com