# Architecture

> Which half of Triagic owns what, why the split exists, and what that means for credentials and network access.

Source: https://triagic.com/docs/concepts/architecture

Triagic is two deployables that trust each other over TLS.

## The split [#the-split]

|                              | Web portal                                                                         | Desktop app                                      |
| ---------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------ |
| Runs on                      | Our hosted service                                                                 | Each member's own machine                        |
| 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**, which run locally alongside the app. More importantly,
your production database 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 portal is reduced to being the place where humans agree on configuration.

## What that means in practice [#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's no merge and no conflict resolution to reason about.

**Credentials flow the same way, and only downward.** A shared integration's secrets
are encrypted at rest 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 [#three-ways-an-install-can-be-running]

Every install is signed in to a Triagic account; there's 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](/docs/concepts/roles-and-access#plans-and-seats) for how
seats are counted, and [How configuration reaches the desktop](/docs/concepts/config-sync)
for what "managed" changes.

## Identity [#identity]

There is one directory, and the portal owns it. The cloud is authoritative; the
desktop keeps a local copy so that sessions, history and attribution keep working on
that machine. 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) is managed on the **Account** page rather than in the
member list. They still appear in every directory view, but their row on the Members
table offers no edit button and points at **Account settings** instead.