Architecture
Which half of Triagic owns what, why the split exists, and what that means for credentials and network access.
Triagic is two deployables that trust each other over TLS.
The split
| Web portal | Desktop app | |
|---|---|---|
| Runs on | Our hosted service (Next.js + Postgres) | Each member's own machine (Electron) |
| Owns | Organization configuration | Execution |
| Manages | Members, teams, playbooks, shared integrations, AI provider keys, spend cap, audit | Tickets, investigations, Console, history, usage |
| Talks to your infrastructure | Never | Always |
| Stores credentials | Yes, encrypted at rest | Yes, re-encrypted with a local key |
The reason for the split is unglamorous: the agent's data sources are reached through MCP servers, and most of those are long-lived local processes that speak over stdio. A serverless web host cannot keep those alive, and — more importantly — your production Postgres is usually not reachable from the public internet anyway. So the tool calls happen on a machine that is already inside your network, and the web app is reduced to being the place where humans agree on configuration.
What that means in practice
Configuration flows one way: portal → desktop. An admin edits a playbook in the portal, the change is stamped with a new revision, and every connected desktop picks it up on its next sync. Desktop-side admin writes are refused while an install is centrally managed, so there is no merge and no conflict resolution to reason about.
Credentials flow the same way, and only downward. A shared integration's secrets
are encrypted in Postgres with AES-256-GCM, delivered over TLS only to an
authenticated desktop, and re-encrypted there under that machine's own key. The API
never returns a plaintext secret to a browser — the portal shows ••• and treats
that value as "keep what is stored".
Nothing about your infrastructure flows upward. Query results, ticket bodies, investigation reports and LLM spend totals stay on the desktop. The portal cannot show you month-to-date spend for exactly this reason; it can only set the cap that the desktop enforces.
Three ways an install can be running
Every install is signed in to a Triagic account — there is no account-less mode. What differs is what that account is entitled to.
On trial
A new account's 14-day free trial. One seat, everything unlocked: tickets, Console, playbooks, integrations. Inviting a second person needs paid seats.
Licensed
Paid seats. Members, teams and central management are in play; a centrally managed install's local admin pages go read-only.
Expired
The trial ran out or the license lapsed. The app locks to its license screen until the organization subscribes. Nothing is deleted.
See Roles, plans and seats for how seats are counted, and How configuration reaches the desktop for what "managed" changes.
Identity
There is one directory, and the portal owns it. Cloud Postgres is authoritative; the desktop mirrors it into local SQLite so that sessions, history and attribution have a local identity to hang off. The cloud's verdict always wins: sign-in is verified against it on every login, and disabling someone in the portal locks them out of the desktop on their next authenticated call, not on their next sync.
One wrinkle worth knowing because it shows up in the UI: the account owner — the person who signed up and pays — has no membership row of their own. They are projected into the member list so that one human keeps one password and still appears in every directory read. That is why the owner's row on the Members table offers no edit button and points at Account settings instead.