# 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.

Source: https://triagic.com/docs/integrations

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](/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](/docs/integrations/databases): MongoDB, PostgreSQL, MySQL, Redis, ClickHouse, Snowflake, BigQuery, DynamoDB, Supabase, Neon.
- [Observability](/docs/integrations/observability): Sentry, Prometheus, OpenSearch, Elasticsearch, Datadog, Grafana, PagerDuty, Splunk, New Relic, PostHog, Dynatrace, Honeycomb.
- [Infrastructure](/docs/integrations/infrastructure): Kubernetes, Docker, Terraform, Confluent / Kafka.
- [Cloud](/docs/integrations/cloud): AWS CloudWatch, AWS SQS / SNS, Azure Monitor, Google Cloud Logging, Cloudflare, Vercel, Okta.
- [Code & repos](/docs/integrations/code): GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI.
- [Business systems](/docs/integrations/business): Atlassian, Stripe, Slack, Notion, Zendesk, ServiceNow, Linear, Intercom, HubSpot, Salesforce, Freshdesk, and PostHog, which the picker files here.
- [Knowledge & memory](/docs/integrations/knowledge): Neo4j, Neo4j knowledge graph memory, Memgraph, Graphiti, Mem0, Cognee.
- [Custom MCP server](/docs/integrations/custom): Anything the catalog does not cover: a raw command, or a remote HTTP endpoint.

## The shape of every setup [#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.

1. **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](#use-read-only-credentials-everywhere) below for why that
   is the boundary that actually holds.

2. **Add it in the portal.** [Integrations](/docs/admin/integrations) → **Add shared data
   source** → pick the catalog entry. The form becomes that integration's real credential
   form, with per-field help.

3. **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.

4. **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 [#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](/docs/desktop/install#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.

> **Warning:** 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 [#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](/docs/admin/integrations#the-environment-tag).

## Use read-only credentials everywhere [#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.

> **Warning:** 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](/docs/admin/security#read-only-guarantees).

## TLS options [#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 [#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](/docs/admin/integrations#multiple-instances-of-one-integration) for
the admin-side detail, including the **copy** control that starts a new instance from
an existing one's non-secret fields.