Every destructive action needs a second device.
Valtrix is a control plane for virtual infrastructure — Proxmox nodes and Hetzner projects under one roof. Routine work stays fast. Deleting a VM, rotating provider credentials, or exporting the inventory stops and waits for a cryptographic approval from a device that is not the one you are working on.
Why a second device
A cloud console is a single point of total failure. One stolen session, one compromised laptop, one mistaken command — and the whole fleet is gone, including the backups that lived in the same account. Valtrix assumes the admin device will eventually be compromised and designs around that, instead of hoping it will not.
Stolen session is not enough
An attacker with full access to the control device can list, start and reboot machines. They cannot delete a node, touch provider credentials, or export the inventory — those need a signature from a key that never leaves the guardian device.
Mistakes get a pause
The same gate catches the human version of the problem: the wrong VM id at 2 a.m. The approval screen shows customer, project, node and IP before anything is destroyed.
Deletion is not immediate
Every destructive operation writes a protected backup first, with its own retention. An approved, executed deletion is still reversible for days — not gone the moment the API returns 200.
Three devices, three roles
Separation is physical, not a permission checkbox. Each device holds a different key with a different purpose, and no device can quietly grant itself the rights of another.
Daily operations
The machine you actually work from: inventory, provisioning, networking, billing, monitoring.
- Cannot change security policy on its own
- Cannot register another trusted device
- Cannot bulk-export data
Approval of critical actions
A separate phone whose signing key is generated inside the secure element and cannot be exported or cloned.
- Approves or rejects, with full context shown
- Can freeze the whole platform (incident mode)
- Never receives customer data or unrelated secrets
Used once, then gone
For the day both other devices are lost. Authorises re-enrolment, then de-authorises itself automatically.
- No standing rights, no daily presence
- Recovery itself is a critical, logged event
- Triggers rotation of every derived key
What happens when you press delete
Two paths through the same engine. The policy decides which one an action takes, and the policy is one central, auditable place — not a condition scattered across handlers.
Routine action — start, stop, reboot
Critical action — delete, credentials, export
What it manages
One inventory across your own hardware and rented capacity, with the provider API hidden behind a domain model instead of leaking into business logic.
What is guaranteed, and against what
Each line below names the attack or failure it addresses. Nothing here is described as "unbreakable" — that word is a marketing claim, not an engineering one.
Build status
Valtrix is in active development and is not accepting customers. This page lists what is actually written and running, not what is planned — the roadmap below is honest about the difference.