Triage logo
Triage Data flow

Data flow & trust boundary

Your payloads never leave your network.

Triage is self-hosted software. It runs inside your VPC, against your brokers, your database and your keys. No message payload ever reaches us — and with default configuration the product makes no outbound connection off your network at all.

This page exists so a security reviewer can finish in ten minutes rather than three weeks. It lists every outbound path the binary can open, including the single one that can carry a payload, which is disabled unless you turn it on.

Zero egress by default Offline licence validation No vendor access to production No sub-processors

The boundary

Everything that touches a message body sits inside the dashed line. Everything outside it is optional, operator-configured, and — with one exception — metadata only.

Triage trust boundary The operator browser, the Triage server, PostgreSQL, Redis, message brokers, object storage and peer Triage instances all sit inside the customer network. Outside it, Triage optionally sends metadata to alert destinations, spans to an OpenTelemetry collector, and a wrapped data key to the customer's own cloud KMS. AI diagnosis is off by default and is the only path that can carry a message payload. There is no connection of any kind to the vendor. YOUR NETWORK / VPC all payload data stays inside this line Operator browser no CDN · no fonts · no analytics Triage API · UI · workers transform engine Brokers SQS · RabbitMQ Anypoint MQ Service Bus · Pub/Sub ActiveMQ Object storage S3 · GCS Azure Blob · R2 MinIO · Wasabi Backblaze B2 PostgreSQL audit trail + optional encrypted payload snapshots Redis leader election, alert state Peer Triage instances federation — mTLS or OIDC OPTIONAL — OFF UNTIL YOU ENABLE IT Alert destinations metadata only — never a message body Slack · Teams · PagerDuty · Opsgenie BigPanda · SNS · SMTP · webhook Your OpenTelemetry collector spans and metadata only no-op unless an OTLP endpoint is set Your cloud KMS wrapped data key only AWS · GCP · Azure — your own account AI diagnosis provider The only path that can carry a payload. Needs an API key and a licence feature, then one message per operator click. JCR Stack — the vendor No connection. No telemetry, no phone-home, no update check, no remote access.
Solid lines are internal traffic that never leaves your network. Dashed lines are optional outbound paths, each off until you configure it.

Every outbound path, exhaustively

This is the complete list. There are no others in the binary.

Licence validation

No call
Trigger
—
Carries payload?
No network call at all. Keys are ECDSA-signed and verified locally, in-process, offline.
Destination
none

Usage telemetry / analytics

Absent
Trigger
—
Carries payload?
Does not exist. No product analytics, no phone-home, no update check.
Destination
none

Alert destinations

Off by default
Trigger
An alert rule you configured fires
Carries payload?
Metadata only — rule label, target, metric, value, timestamp. Replay alerts add failure counts, error stage and error strings. Never a message body.
Destination
Slack, Teams, PagerDuty, Opsgenie, BigPanda, SNS, SMTP or a webhook — whichever you configure

OpenTelemetry traces

Off by default
Trigger
Only when an OTLP endpoint is set — otherwise the tracer is a no-op
Carries payload?
Spans and metadata. No bodies.
Destination
Your collector

Cloud KMS

Off by default
Trigger
Only when snapshot encryption uses a KMS key provider
Carries payload?
The wrapped data key, nothing else. Unwrap happens at startup; steady-state encryption is local AES-256-GCM with no KMS call on the hot path.
Destination
Your own AWS, GCP or Azure account

AI diagnosis

Off by default
Trigger
Requires both an API key and the diagnose licence feature, then an operator explicitly clicking Diagnose on one message
Carries payload?
Yes — this is the one path that can carry a payload. See below.
Destination
Anthropic, or any OpenAI-compatible endpoint you nominate — including one inside your own VPC

Support bundle

Manual
Trigger
An admin downloads a zip to their own machine
Carries payload?
No payloads. Sanitised config with secrets excluded, health probes, system info, recent log lines. Nothing is transmitted anywhere — sending it to us is a separate human decision.
Destination
none automatic

Container image pull

Install time
Trigger
docker pull at install or upgrade
Carries payload?
No.
Destination
Your registry, or GHCR

The one honest exception: AI diagnosis

If — and only if — an operator sets an AI API key and the licence includes the diagnose feature, a per-message Diagnose action becomes available to admin and operator roles. Invoking it sends the selected message body and attributes, the queue name and message ID, and — only if the operator ticks "include recent failures" — up to three other recent bodies from the same queue.

Nothing is sent in the background, on a schedule, or on any other action. Leave the key unset and the path does not exist: the endpoint returns 404 and no client is ever constructed. To keep the capability without the egress, point the base URL at an OpenAI-compatible model running inside your own network.

Payload data at rest

Two tables hold message bodies — the before/after snapshots that power the diff view, the trace, and the remediation audit log. Everything else Triage stores is metadata: queue names, object keys, actor, timestamps, transform scripts, trace identifiers.

All of it lives in your PostgreSQL instance, under three controls that are entirely in your hands.

Never persist

Turn snapshot capture off and bodies are dropped at insert time — they never touch the database. The audit trail of who did what, when, and to which queue is preserved either way.

Retention

Snapshot bodies age out on a schedule you set, independently of the audit records they belong to.

Envelope encryption

AES-256-GCM per row, with the data key wrapped by a raw master key or by AWS KMS, GCP KMS or Azure Key Vault in your own account. This defends a live database breach — which volume-level encryption does not.

The browser tier, and credentials

No third-party origin in the UI

The interface is a static app served by the Triage binary itself. It loads no CDN scripts, no web fonts, no analytics and no tag manager — the page head contains one inline theme script and one local module, and nothing else. The only external references anywhere in the frontend are documentation links, followed solely when a user clicks them.

Transforms run locally

Browser-side transform testing executes in a Web Worker on the operator's own machine. Server-side execution uses an embedded JavaScript interpreter in the Triage process. Neither calls out to anything.

Credentials stay server-side

Broker, storage and database credentials are held by the server and never sent to the browser. Federation between your own instances authenticates with mTLS or OIDC bearer tokens; membership of that mesh is the trust boundary.

What we do receive

Exactly one thing, and it comes from a web form rather than from the product: licence issuance details — name, email, organisation, team size, queue provider and use case, submitted when you request an evaluation or buy a licence. No product data, no telemetry, no payloads, and no connection from a running instance.

Air-gapped operation

With AI diagnosis unset and no OTLP endpoint, alert destination or cloud KMS configured, a Triage instance runs with zero egress from your network. Licences validate offline against an embedded public key, so an air-gapped deployment needs no exception, no allow-list entry and no outbound firewall rule.

The only network access ever required is pulling the container image at install time.

Questionnaire shortcuts

The lines that usually take three weeks of back-and-forth, answered up front.

Do you process or store our data?
No. Triage is self-hosted; we never receive customer data.
Is a DPA or BAA required?
Arguably not — no personal data or PHI reaches us. We will sign one anyway.
Where is data hosted?
Wherever you deploy it. We have no hosting role.
Who are your sub-processors?
None for customer data.
Data deletion or return on termination?
Not applicable — we hold nothing to return.
Encrypted in transit and at rest?
TLS in transit; volume encryption plus optional per-row AES-256-GCM envelope encryption under your own KMS key.
Do you have access to production?
No. No remote access, no support tunnel, no default credentials.
If the vendor is breached, what is our exposure?
Your licence contact details. No payload, configuration or credential of yours exists on our side.

Need the detail behind any line here?

Retention, encryption, RBAC, federation and deployment are covered in full in the administrative guide.

Administrative guide →