If you manage more than a handful of servers, you've probably hit the same wall I did: you remember roughly what's on each box, but the details — kernel version, what's listening on which port, that one container that's been running for six months and nobody can remember why — drift out of your head. The usual answer is "log in and check," which works for one server and falls apart at twenty.

Servonaut now has a feature for this called Server Memory, available on Solo and Teams plans. It's an inventory of every box you manage, refreshed automatically every time the CLI probes them, surfaced as a drift timeline on your dashboard. The unusual part is the privacy posture:

The backend cannot read your inventory. Not "won't" — cannot.

How it works

When the CLI builds a snapshot, it does the work locally:

  1. Probes the host for OS, runtimes, listening ports, services, containers, disk usage, log paths, git checkouts.
  2. Encrypts each module's payload with AES-256-GCM under a per-envelope random key (DEK).
  3. Wraps that DEK with your passphrase-derived key (libsodium Argon2id + XChaCha20-Poly1305) so only you can open it.
  4. Uploads the ciphertext + a small block of safe metadata — counts, hashes, anomaly markers — and nothing else.

If our database leaks, the worst an attacker recovers is "this server has 14 enabled units and a kernel hash of 7c3a…" — never the unit names, never the log paths, never the kernel string.

Drift and anomaly detection without seeing the data

The dashboard shows every probe and the deltas between them — a new listening port, an upgraded runtime, a service that vanished, a sudden disk-usage jump. Seven hand-coded rules run server-side and only ever look at the safe metadata:

  • Disk usage jumps more than 20% in 24h → high severity
  • A new listening port appears → medium
  • Service count drops → medium ("did puppet just nuke nginx?")
  • Container count swings 50%+ in one snapshot → medium
  • A runtime version (kernel hash, php version, etc.) changes → info
  • And two more around server liveness

It's a rule engine, not ML. Fast, deterministic, explainable. You can tune thresholds without a deploy.

AI summaries — the one place plaintext leaves your browser

When you click "Summarise this server," and only then, your browser submits your decryption passphrase to a one-shot job. The backend decrypts in memory, summarises with Gemini, re-encrypts the result with your key, and wipes the passphrase before the job exits. There is no background summarisation. There are no analytics on your plaintext. The full flow is in the Server Memory docs.

Team sharing without us holding the key

On the Teams plan, sharing a server's memory with a colleague is a client-side ceremony: your browser re-wraps the relevant DEKs against each authorised member's public key. The backend sees encrypted blobs change hands; we never see the key. Grants are revocable, and the audit log records who unlocked what.

What you keep

  • Compliance-ready exports — every snapshot can be downloaded as a signed bundle (auditors verify against our published Ed25519 public key, served at /api/v1/memory/export-signing-key)
  • Drift timeline you can reason about — every event is one of seven labelled rules, not a black box
  • Plan-driven retention — Solo gets 30 days of history per server, Teams gets 180

What we give up

  • We can't help you when you forget your passphrase. There is no server-side recovery; we don't have the key. If that bothers you, a passphrase manager is the right answer.

Read the full Server Memory docs →