Vitrinode is a secure management plane for a small Linux estate. It prioritises per-device cryptographic identity, constrained remote operations, explicit trust boundaries, auditability and low operational complexity.
This page compares that approach with the tools it complements — and shows where Vitrinode is not the right fit.
On this page: Compare·Approach·Limitations·Where it fits
Vitrinode combines device identity, Linux inventory, constrained remote operations and auditability in a single management plane. It overlaps with several established tool categories, but is designed to sit alongside them where they solve a different problem better.
| Need | What Vitrinode gives you | Where adjacent tools fit |
|---|---|---|
| Secure Linux estate management | Device identity, mTLS, inventory, typed signed jobs, revocation and auditability in one control plane. | Config-management or access tools can sit alongside it for broader automation or interactive shell access. |
| Controlled remote operations | Fixed typed actions, signed dispatch, privilege separation and replay protection. | Ansible/Rundeck are better when you need broad, arbitrary automation. |
| Host + Proxmox visibility | Correlates guest state with enrolled agent state. | Proxmox remains the system for hypervisor lifecycle management. |
| Human administrative access | FIDO2/WebAuthn-only control-plane authentication and server-enforced step-up capability. | SSH/Teleport/Tailscale remain appropriate for interactive shell sessions. |
| Small single-estate operations | A simple deployment and trust model. | Enterprise RMMs are more appropriate when you need thousands of endpoints, multi-tenancy or broad MSP workflows. |
Vitrinode is currently exercised on a small single-estate fleet and is not positioned as a thousands-of-endpoints platform. Larger limits have not been load-tested. The current architecture keeps deployment simple: one server process, SQLite, and an in-memory job broker.
The main distinction is not the feature list, but what the control plane is allowed to trust and execute. See Architecture and Security for the full design.
The device's private key is generated locally and never transmitted. A CSR is signed during short-lived, single-use provisioning. Server↔agent traffic is mutual TLS, and revocation is checked against server state on every authenticated request — not assumed from the handshake alone.
WebAuthn/FIDO2 only. There is no password authentication path in normal operation.
The current action registry is small and fixed: system.status, systemd.list, systemd.status, apt.list_updates, and systemd.restart. Arbitrary shell execution is a permanent non-goal. Jobs are signed by the control plane and carry a nonce and expiry for replay protection, and systemd.restart only runs when the target device's attestation state is good.
lg-agent runs unprivileged. Anything needing elevated local rights is dispatched to a separate, narrowly-scoped lg-executor process over a local socket, which independently re-verifies each job's signature before executing it — a compromised agent process doesn't, by itself, grant arbitrary root execution.
Server-side FIDO step-up (a freshly re-asserted WebAuthn ceremony, enforced server-side) exists and is wired to device revocation and attestation re-baselining today. Other sensitive actions are named on the roadmap for step-up but are not yet gated by it — don't assume every mutating job currently requires it.
Authentication events and the job lifecycle write to an append-only audit log server-side. There's no dedicated audit UI yet — the trail exists in the backend, not (yet) a browsable view.
Read-only integration against one Proxmox cluster: VM/CT inventory, power state, and correlation against agent connectivity to distinguish hypervisor-reported state from agent-reported state. No start/stop/reboot or other lifecycle actions exist.
A valid device certificate proves which enrolled device is talking — it does not prove the host is untampered or in a known-good, measured runtime state. Vitrinode now tracks that separately: where a hardware TPM is available it takes a genuine vTPM quote over PCR state, with an explicitly weaker "software evidence" fallback where it isn't, and holds the result as a device trust state. "Enrolled and authenticating" and "attested" stay two different claims, and the interface keeps them apart.
Gaps in what's built today, not permanent decisions — see the roadmap for what's next.
Arbitrary shell / general-purpose command execution is outside the typed job model, and the job registry is not intended to accept it. Vitrinode currently targets Debian/Ubuntu and apt/dpkg specifically, not a cross-distro package-manager abstraction.
SSH is the better tool for flexible, interactive administration. Vitrinode handles a narrower set of recurring operations through a typed job model, while centralising device identity, revocation, inventory and audit records. It trades command flexibility for tighter constraints on what the control plane can execute.
Vitrinode can provide identity, inventory and constrained operations alongside tools with a broader or more specialised role:
Keep it for configuration enforcement and broad automation. Vitrinode doesn't compete with desired-state config management.
Keep it for hypervisor management. Vitrinode correlates what Proxmox reports with what the agent reports; it doesn't control the hypervisor.
Keep them for interactive access. Vitrinode's job model is a narrower, typed complement, not a replacement for a real shell session when you need one.