Docs / Trust & compliance
Data protection
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 Being specified now. Everything below is the planned design, not a released feature.
Data protection and encryption on-premise come down to four plain questions. Is the data encrypted on disk and on the wire? Who can read it? Can you get it back after a mistake or a failure? And can you prove all of that later? This page sets out how TractorStack’s design answers each one for the databases, buckets, backups and configuration it looks after.
Data protection and encryption: what is covered
- Application data in PostgreSQL.
- Files and objects in RustFS buckets.
- Backups of both, on site and off site.
- Infrastructure state from OpenTofu, which can contain addresses and sometimes secrets. See Where state lives.
- The configuration repository in your self-hosted GitLab.
Encryption at rest
The design encrypts the disks that hold data volumes with full-disk encryption at the operating system level, such as LUKS, set up by Ansible. That protects against a disk that leaves the building, whether it failed, was replaced or was stolen. It does not protect against someone who already has access to the running server, which is why access control matters as much.
On top of that, two layers encrypt their own output. pgBackRest encrypts the database backups it writes to RustFS, and OpenTofu encrypts its state on the client side before it is stored (a feature added in OpenTofu 1.7). Both keys are planned to be held by the site runner and copied to a safe place outside the server. Lose the key and the backup is useless, so the runbook treats key escrow as part of setup, not an afterthought.
Encryption in transit
Traffic between services is planned to use TLS everywhere, including inside your own network. Certificates come from the internal certificate authority set up at the network layer, so nothing depends on a public CA.
- Applications connect to PostgreSQL over TLS, and replication between database nodes uses TLS too.
- Clients talk to RustFS over HTTPS with the standard S3 API.
- Ansible and OpenTofu reach hosts and hypervisors over SSH or HTTPS only.
Access control
The rule is least privilege, written down as code. Each application gets its own database role and its own bucket with its own access keys, so one compromised app can’t read another app’s data. People sign in with named accounts, never a shared admin login, and SSH uses keys. Credentials are kept in the secrets store on the site runner and rotated on a schedule.
Who can see what
| Who | Can see | Can’t see |
|---|---|---|
| An application | Its own database and bucket | Other applications’ data, infrastructure credentials |
| Operators | Hosts, logs, run output | Application data, unless granted for a task |
| Approvers | Change requests and plans in GitLab | Secrets, which are masked in plans |
| The backup job | What it backs up, write-only to the backup bucket | Delete rights on old backups |
| InfraTractor | Nothing by default | Everything, unless you open a support session |
Every grant and every change to a grant goes through a change request and lands in the audit trail.
Backups as protection
Encryption and access control don’t help if data is deleted by mistake. Nightly backups, an automatic test restore and an off-site copy from stage 2 are covered in Backups.
Where your data physically lives, and why none of it needs an outside service, is covered in Your data stays on site.
Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com