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.

Every integration also has a public overview page with real Console prompts and the exact tool list at /integrations; these docs pages are the setup reference each one links back to.

The catalog entries below ask only for their own credentials: a connection string, an access token, a pasted kubeconfig. 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, Neon.

Observability

Sentry, Prometheus, OpenSearch, Elasticsearch, Datadog, Grafana, PagerDuty, Splunk, New Relic, PostHog, Dynatrace, Honeycomb.

Infrastructure

Kubernetes, Docker, Terraform, Confluent / Kafka.

Cloud

AWS CloudWatch, AWS SQS / SNS, Azure Monitor, Google Cloud Logging, Cloudflare, Vercel, Okta.

Code & repos

GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI.

Business systems

Atlassian, Stripe, Slack, Notion, Zendesk, ServiceNow, Linear, Intercom, HubSpot, Salesforce, Freshdesk, and PostHog, which the picker files here.

Knowledge & memory

Neo4j, Neo4j knowledge graph memory, Memgraph, Graphiti, Mem0, Cognee.

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.

In practice only the third row is your problem. npx and uvx ship inside the installer, a portable Node LTS and a portable uv, placed ahead of the app's own PATH so every integration runs on the same runtime whatever the machine has installed. Docker cannot be bundled and has to be installed. See Runtimes are bundled.

Runner	Install	Integrations that need it
`npx`	bundled (Node LTS)	MongoDB, Sentry, Kubernetes, Elasticsearch, Datadog, GitLab, Stripe, New Relic, Azure Monitor, Google Cloud Logging, Confluent, Slack, Notion, Zendesk, ServiceNow, Supabase, Azure DevOps, Bitbucket, CircleCI, HubSpot, Salesforce, Freshdesk, Dynatrace
`uvx`	bundled (uv, with its own Python)	Redis, Prometheus, OpenSearch, AWS CloudWatch, AWS SQS / SNS, ClickHouse, BigQuery, PagerDuty, Atlassian, DynamoDB, Docker, Okta
`docker`	Docker Desktop or Engine	GitHub, Grafana, Terraform

MySQL, PostgreSQL and Snowflake are in none of those rows. Their servers are part of Triagic itself, ship inside the app and run on the same bundled Node, so there is no package to fetch.

Eight 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, Vercel, Neon, PostHog, Linear, Intercom and Honeycomb. 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.

The Docker integration is the other way round and does not need Docker installed at all: it runs under uvx and talks to an engine's API socket, local or remote.

Which environment it points at

Every integration carries an Environment tag: production, staging or development, defaulting to production. It is purely a label: nothing routes on it and no tool is blocked because of it. What it does is make a list of four Postgres connections legible, as a badge on the card, in the portal and in the desktop alike.

The field sits alongside the credential on both forms, the portal's and the desktop's, and a shared integration's tag syncs down with everything else. See Integrations.

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.

Seven integrations block nothing for you

BigQuery, New Relic, Zendesk, HubSpot, Freshdesk, Vercel and Snowflake (which has no read-only session, so its statement 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's the only thing standing between the agent and a write.

CircleCI is the odd one out: its personal tokens can't be scoped, so Triagic's tool allowlist is the only boundary. Mint the token from a user who follows only the projects the agent should read.

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.