Product overview
Vitrinode combines host connectivity, inventory collection and controlled remote operations for small Debian and Ubuntu estates. The table below separates implemented capabilities from work in development and planned features, including the full inventory UI.
Discuss these capabilities in a technical evaluation →
On this page: Overview·Capabilities·Environments
The problem
A handful of Debian and Ubuntu systems is easy to keep in your head. Twenty or thirty, spread across bare metal, VMs and containers, is not — what's running where, which packages are behind, which host is actually reachable, tends to live in one engineer's memory and a scattering of SSH sessions and ad-hoc scripts. Generic RMM tools solve this for fleets of thousands, with a trust model sized for that scale. Vitrinode targets the estate in between: too large to track by hand, too small and too security-sensitive to hand to a heavyweight platform.
Capabilities
Status reflects the codebase, not intent. Available is built, tested and running against real hosts today. In development means implementation work has begun but the feature is not complete end-to-end. Planned is roadmap or design work with no implementation yet.
| Capability | Status | Scope |
|---|---|---|
| Identity & access | ||
| Secure device registration | Available | One-time provisioning token, CSR signed by an internal device CA. The device's private key is generated on the device and never transmitted. |
| Mutual TLS transport | Available | Every agent–server connection authenticated in both directions against Vitrinode's own certificate authority. |
| Certificate revocation enforcement | Available | Revocation status checked on every authenticated request, not assumed from a valid handshake. |
| Passwordless administrator login | Available | WebAuthn/FIDO2 only; an account can register multiple hardware keys. |
| Step-up authentication | Available | Sensitive actions re-require a fresh FIDO ceremony, enforced server-side. Wired to device revocation today; more actions are being added. |
| Inventory & visibility | ||
| Host inventory & heartbeat | Available | Registered devices, liveness, last-seen state. |
| System facts | Available | CPU, memory, load averages, uptime. |
| Storage facts | Available | Mounted filesystems with usage, raw block devices. |
| Network facts | Available | Interfaces and listening TCP/UDP sockets. |
| systemd unit health | Available | Per-unit load/active/sub state. |
| APT package & update state | Available | Installed package count, upgradable set, reboot-required flag. |
| Docker presence & objects | Available | Daemon reachability, containers, images. |
| Consolidated per-host inventory view | Planned | The facts are collected and stored today, but rendering them in the device detail and change timeline is assigned to Phase 9 and has not started. |
| Operations | ||
| Typed remote operations | Available | Signed, replay-protected job dispatch (host status, systemd list, APT update list) to agents. |
| Privileged executor separation | Available | A narrowly-scoped local process for anything needing elevated rights, reachable only over a local socket — so a compromised agent process doesn't imply root. |
| Change / diff timeline | Planned | Per-host history of composition changes, not just current state. |
| Platform integrations | ||
| Proxmox VE correlation | Available | Read-only VM/CT inventory with periodic sync, state and staleness indicators, plus admin-confirmed links to managed devices. |
| VMware correlation | Planned | Read-only VM inventory and power-state correlation, following the same admin-confirmed linking model as Proxmox VE. |
| Device attestation | Available | vTPM quote over PCR state where hardware supports it; explicitly weaker "software evidence" elsewhere, never presented as equivalent. The result is held as a device trust state, and systemd.restart only runs when it is good. |
| SSH access via short-lived certificates | Planned | Step-up-gated, internal SSH CA. No centrally stored admin private keys, no proprietary shell protocol. |
| SSH CA key on dedicated hardware (Vitrinode-HSM) | In development | RP2350 signing prototype verified through successful OpenSSH authentication. Persistent CA storage is in development; hardware acceptance and server integration remain outstanding. See Hardware signing. |
Supported environments
Narrow today — Debian/Ubuntu and their APT tooling, plus Docker — rather than a thin abstraction layer over distributions that aren't actually in use. The list is expected to grow; nothing beyond what's below is currently targeted.
- Debian Available Primary agent target; system, storage, network, systemd and APT collectors run here.
- Ubuntu Available Same APT-based collector path as Debian.
- Docker Available Container and image inventory. No lifecycle actions (start/stop/remove) yet.
- Proxmox VE Available Read-only VM/CT inventory, power-state correlation and admin-confirmed device linking against one cluster.
- VMware (vSphere / ESXi) Planned Read-only VM inventory and correlation, mirroring the Proxmox VE integration; no integration exists yet.
Assess the fit for your environment
Technical evaluations are scoped individually around the implemented capabilities above. Start with a lab or isolated test environment; exact platform compatibility and permitted operations are agreed before access.
How evaluation access is arranged · What to include in an enquiry