v0.1.0 is the first tagged release of Trove KB. Everything on this site was already on main; the tag is the line that says it is ready to run for real. Here is what you get, and why it is shaped the way it is.
Documents that fix their own templates
A client is a company, a site is a location, and every firewall, circuit, tenant, and printer is a document built from a doc type: an ordered set of typed fields. Values are keyed by field id, never by label, so renaming a field touches no document.
The part that matters is what happens when the template is wrong. A tech documenting a switch finds there is no field for the PoE budget. Here that is a button in the document: add a local field, and when the third switch needs it too, promote it to the template with one click. Dropdowns carry a + that writes to the shared list and selects the new option. Every field has a drag handle, and reordering a template field asks whether this document or the template should change.
Every save writes a revision and an audit entry. Archived fields keep their values, so old revisions still render whole. Ten starter doc types ship with the seed: Vendor, ISP, Firewall, Switch, Wi-Fi, Printer, Server, Rack, Domain/DNS, and M365/Google Tenant, with the shared lists they draw on.
A knowledge base beside the documentation
Collections hold reference articles from outside sources and never belong to a company: a vendor’s help center read by its own structure, a website crawled by sitemap, a wiki or an export brought in as a zip, with their pictures and the PDFs they link. Imports upsert on a stable id, and every converter is held to one standard: an imported article reads as its source did, numbered steps included.
A runbook is an article whose lists are a procedure. Each step carries a stable id written into the body, so a ticketing system can keep per-ticket progress by step while the runbook stays here.
The public site publishes the collections you choose on a hostname of its own, with search, favorites, and votes. Behind Cloudflare Access, a visitor from one of a company’s sign-in email domains is placed with that company and sees its collections too. Admin → Portal is the setup page, and your own name goes on the credit.
Credentials stay in your vault
Trove KB never stores a password, TOTP seed, or secure note. A secret field holds a reference plus the non-secret metadata it needs to display and search. In link mode that is a deep link into your web vault and nothing to run. In brokered mode the official Bitwarden CLI runs as a sidecar with no published port, against Bitwarden cloud, self-hosted Bitwarden, or Vaultwarden, and a reveal is a click, a permission check, and an audit entry. 1Password Connect and HashiCorp KV providers are there too, and a company can name its own vault, because an MSP inherits whatever each client already uses.
A revealed secret is colored character by character, with a NATO readback beside it for the phone. Nothing exposed over the API or MCP can ever be a secret.
Any PSA, any assistant
Everything the app does is on /api/v1 with bearer keys, and the OpenAPI spec is generated from the same Zod schemas the endpoints validate with. A key is scoped to every company or a named set, and out of scope answers not found, never forbidden. PUT /external-refs maps a PSA’s client id to a company; GET /lookup and /go/{system}/company/{id} take a ticket straight to that client’s documentation. Webhooks are HMAC-signed and retried eight times.
POST /api/mcp speaks the Model Context Protocol on the same keys. An assistant can search and read documentation and the knowledge base, and a key granted write on a collection can keep that collection current. Secret fields are stripped from every response, and there is deliberately no reveal tool.
Racks and domains
A Rack document draws itself from what is mounted in it: the Switch and Server documents you already have, or plain labels for the patch panel. Printable SVG per face, color per equipment kind with per-client overrides, and a warning when two things claim the same unit.
A Domain/DNS record looks itself up: DNS with TXT records named by kind, the TLS certificate, the registry’s RDAP record, SPF, DMARC and DKIM, and the website’s own branding. The worker re-runs each on its own clock, set in three layers (instance, company, record), compares each run with the last, and sends a domain.changed webhook naming what differs and a domain.expiring webhook once per expiry date. Admin → Notifications lists what was flagged. What a check finds is offered with a Use this button, never applied by itself.
Access and security
Roles are sets of permissions: the built-in admin, tech, and readonly are fixed, and Admin → Roles adds your own with any subset. A user or key sees every company or only the ones granted. Local accounts hash with Argon2id and refuse breached passwords; authenticator apps, passkeys, and recovery codes are a second step that single sign-on in front does not replace. OIDC with discovery covers Entra ID, Google, Authentik, and Keycloak. Attachments are typed by their bytes, HEIC becomes JPEG, macro-enabled Office is refused.
Running it
One container and Postgres 16. No Redis, no queue, no search service.
git clone https://github.com/joshhearne/trove-kb.git
cd trove-kb
cp .env.example .env # POSTGRES_PASSWORD, DATABASE_URL, AUTH_SECRET
docker compose up -dOr the same code as a Cloudflare Worker with Postgres behind Hyperdrive and attachments in R2. The install page generates a .env with fresh secrets; the docs cover the rest, from the environment to backups.
What is next
Tags, multi-tenant, and importers for Hudu and IT Glue CSV are on the list. Resolvd, our issue tracker, already uses Trove KB as its knowledge base over this API, and that integration keeps growing. The changelog follows each tag from here.