Connecting data sources
How an integration is configured, what has to be installed on the machine that runs it, and the whole catalog with a link to the per-integration steps.
An integration is one data source the agent can read during an investigation. You configure it once in the portal, and every member's desktop app starts it locally on the next sync — the agent's tool calls run on that machine, against your systems, with the credential you supplied.
The catalog entries below ask only for their own credentials: a connection string, an access token, a kubeconfig path. The package, arguments and transport behind each one are derived server-side, so package upgrades and new flags reach existing configurations on their next restart without anyone editing anything.
Databases
MongoDB, PostgreSQL, MySQL, Redis, ClickHouse, Snowflake, BigQuery, DynamoDB, Supabase.
Observability
Sentry, Prometheus, OpenSearch, Elasticsearch, Datadog, Grafana, PagerDuty, Splunk, New Relic.
Infrastructure
Kubernetes, Terraform, Confluent / Kafka.
Cloud
AWS CloudWatch, AWS SQS / SNS, Azure Monitor, Google Cloud Logging, Cloudflare, Vercel.
Code & repos
GitHub, GitLab.
Business systems
Atlassian, Stripe, Slack, Notion, Zendesk, ServiceNow.
Custom MCP server
Anything the catalog does not cover: a raw command, or a remote HTTP endpoint.
The shape of every setup
Each integration's page follows the same four steps. The differences between them are entirely in step 1 — where the credential comes from and what it has to be allowed to do.
Mint a read-only credential in the source system. Every page names the exact screen and the minimum role or scopes. Do not reuse an admin credential; see Use read-only credentials below for why that is the boundary that actually holds.
Add it in the portal. Integrations → Add shared data source → pick the catalog entry. The form becomes that integration's real credential form, with per-field help.
Wait for a desktop to sync. Saving validates the shape of what you typed, never the connection — the portal has no long-lived process to test from. The first desktop to pick the configuration up starts the server and reports back.
Read the reported status. running with a tool count means it works. degraded
carries the error text, and every page below has a table mapping the errors that
integration actually produces to the field that fixes them.
Prerequisites on the machine running Triagic
Most integrations spawn a local process, and which runtime it needs depends on how upstream ships that server. The desktop app checks for all three and reports an integration as degraded, with the reason, when its runner is missing.
| Runner | Install | Integrations that need it |
|---|---|---|
npx | Node.js 18+ | MongoDB, PostgreSQL, Redis, Sentry, Kubernetes, Elasticsearch, Datadog, GitLab, Stripe, New Relic, Azure Monitor, Google Cloud Logging, Confluent, Slack, Notion, Zendesk, ServiceNow, Supabase |
uvx | uv (Python) | MySQL, Prometheus, OpenSearch, AWS CloudWatch, AWS SQS / SNS, ClickHouse, Snowflake, BigQuery, PagerDuty, Atlassian, DynamoDB |
docker | Docker Desktop or Engine | GitHub, Grafana, Terraform |
Three integrations need no local runtime at all because they are hosted endpoints the desktop talks to over HTTPS: Splunk (the app running inside your own Splunk instance), Cloudflare, and Vercel. Those need outbound network access rather than an installed runtime.
Docker's localhost is not your localhost
GitHub, Grafana and Terraform run inside a container, where localhost means the
container itself. A Grafana or Terraform Enterprise running on the same machine has to
be addressed as host.docker.internal (or the machine's LAN address), never
localhost.
Use read-only credentials everywhere
Where a server has a read-only mode, this catalog pins it on and never exposes a switch to turn it off. But that guarantee is only as good as the upstream server's own code, and a handful of servers have no such mode at all.
Five integrations block nothing for you
BigQuery, New Relic, Zendesk, Vercel and Snowflake (whose keyword guard is defense-in-depth only) rely entirely on the credential you supply. For these, a least-privilege user or a read-scoped token is not a best practice — it is the only thing standing between the agent and a write.
Pointing every credential at a read-only role makes the guarantee independent of any bug in the MCP layer. See Security model.
TLS options
Several integrations expose the same two fields, and they mean the same thing everywhere:
- CA certificate path — an absolute path on the machine running Triagic, for an
https://endpoint fronted by a private CA. - Verify TLS certificate — turn off for self-signed certificates or a bare-IP
https://URL. Traffic stays encrypted; the certificate is simply not checked.
Prefer the CA path over disabling verification wherever you have the bundle.
Keys, and more than one of the same thing
Every shared integration's key is prefixed org- (org-postgres, org-sentry), and
personal keys are barred from that prefix. The key prefixes the integration's tool
names, so a member's own postgres and the organization's org-postgres produce
distinct tools (postgres__query vs org-postgres__query) that never collide.
Pick the same catalog entry again to add a second instance — production and replica,
staging and prod. Keys allocate themselves (org-postgres, org-postgres-2), and
because the key is what a playbook scopes to, a playbook can be pointed at exactly one
instance. Two configurations resolving to the same connection are rejected: they would
spawn the same server twice and double the tool count for nothing.
See Integrations for the admin-side detail, including the copy control that starts a new instance from an existing one's non-secret fields.