Connectors

A connector is an MCP server that the Nimbus Gateway spawns on demand to fetch data from a third-party service. Each connector handles its own authentication (OAuth PKCE or a stored API key / PAT), exposes the standard list / get / search tool surface (write tools such as create, update, move, and delete are available on some connectors but are always gated by HITL consent), and writes its results into your local SQLite index. The Gateway never calls cloud APIs directly — every cloud touchpoint goes through a connector process.

---

Supported services

The table below covers every connector that ships in the current release. The Sync interval column shows the default cadence; you can override it per connector in Settings → Connectors (minimum 60 s, enforced inline). The Auth column summarises how credentials are stored — all of them end up in the OS-native Vault (DPAPI on Windows, Keychain on macOS, libsecret on Linux) and are never written to disk in plaintext.

File and mail

Service	Default sync	Auth	Per-connector docs
Google Drive	30 min	OAuth PKCE (Google)	Connectors overview
Gmail	5 min	OAuth PKCE (Google)	Connectors overview
Google Photos	6 h	OAuth PKCE (Google)	Connectors overview
OneDrive	30 min	OAuth PKCE (Microsoft)	Connectors overview
Outlook	5 min	OAuth PKCE (Microsoft)	Connectors overview

Communication

Service	Default sync	Auth	Per-connector docs
Slack	5 min	OAuth PKCE (Slack)	Connectors overview
Microsoft Teams	5 min	OAuth PKCE (Microsoft)	Connectors overview
Discord	5 min	Bot token (opt-in)	Connectors overview

Source control

Service	Default sync	Auth	Per-connector docs
GitHub	1 min	Personal Access Token (PAT)	Connectors overview
GitLab	1 min	Personal Access Token (PAT)	Connectors overview
Bitbucket	1 min	App password (username + token)	Connectors overview

Project tracking

Service	Default sync	Auth	Per-connector docs
Linear	1 min	API key	Connectors overview
Jira	1 min	Email + API token + base URL	Connectors overview
Notion	5 min	OAuth PKCE (Notion)	Connectors overview
Confluence	10 min	Email + API token + base URL	Connectors overview

CI / CD

Service	Default sync	Auth	Per-connector docs
GitHub Actions	1 min	Same PAT as GitHub	Connectors overview
GitLab CI	1 min	Same PAT as GitLab	Connectors overview
CircleCI	90 s	Personal API token	Connectors overview
Jenkins	2 min	Base URL + username + API token	Connectors overview

Observability

Service	Default sync	Auth	Per-connector docs
Grafana	2 min	Base URL + API token	Connectors overview
Sentry	2 min	Auth token + org slug	Connectors overview
New Relic	2 min	User API key + account ID	Connectors overview
Datadog	2 min	API key + application key	Connectors overview

Infrastructure

Service	Default sync	Auth	Per-connector docs
Kubernetes	2 min	kubeconfig file path	Connectors overview
AWS	2 min	Access key + secret + region (or named profile)	Connectors overview
Azure	2 min	Service principal (tenant + client ID + secret)	Connectors overview
GCP	2 min	Service account JSON key path	Connectors overview
IaC (Terraform / Pulumi)	2 min	Opt-in for local CLI detection	Connectors overview

Incident management

Service	Default sync	Auth	Per-connector docs
PagerDuty	2 min	REST API token	Connectors overview

Local filesystem

Service	Default sync	Auth	Per-connector docs
Filesystem	On change	None (opt-in via [[filesystem.roots]])	Connectors overview

The filesystem connector is disabled by default. Enable it by adding one or more [[filesystem.roots]] blocks to nimbus.toml.

---

How auth works

Nimbus follows a strict credential-injection model:

1. You authenticate a service via nimbus connector auth <service> (or Settings → Connectors → Connect). Nimbus runs the OAuth PKCE flow in a browser window or prompts you for a PAT / API key at the terminal.
2. The Gateway stores the credential in the OS-native Vault under a service-scoped key. No credential is ever written to disk in plaintext or included in a log line.
3. When the Gateway spawns a connector process, it reads the credential from the Vault and injects it as an environment variable into the connector’s process environment. The connector reads process.env — it has no Vault access of its own.
4. When you switch profiles, Nimbus re-binds the Vault namespace for the new profile and re-spawns each connector with the correct credentials.

---

Connector health

Every connector reports one of six health states:

State	Meaning
healthy	Last sync succeeded within the expected window.
degraded	Sync is failing intermittently; partial data may be stale.
error	Sync has failed enough times to reach the error threshold.
rate_limited	The upstream API returned a rate-limit response; connector is backing off.
unauthenticated	The stored token is expired or missing; re-auth required.
paused	Connector is manually paused or waiting for a scheduled window.

The Tauri app tray reflects the worst state across all connectors. The CLI shows per-connector state:

nimbus connector list

github          healthy   last sync 43s ago
gitlab          healthy   last sync 1m ago
slack           degraded  last sync 11m ago  (rate limited, retrying in 4m)
jira            unauthenticated  → re-auth: nimbus connector auth jira

---

Sync intervals

Each connector runs on its default sync cadence (shown in the tables above). Connectors that support delta APIs — Google Drive, Gmail, OneDrive, Outlook — only fetch changes since the last sync token, so each incremental sync is fast regardless of the total corpus size.

Override the interval per connector in Settings → Connectors — click the connector row and adjust the interval field. The minimum is 60 seconds, enforced inline; you cannot set a shorter cadence.

---

Indexing depth

Each connector has an indexing depth that controls how much of an item’s text is written to your local index. It is set per connector and enforced on every sync — not only when you run reindex — so a connector below full never accumulates bodies between reindexes.

Depth	What lands in the index
full	Title, metadata, and the item body — up to 16,384 UTF-16 code units for prose-heavy types (mail, chat messages, tickets, wiki pages).
summary	Title, metadata, and the body clamped to 512 UTF-16 code units. Never marked complete.
metadata_only	Title and metadata only. The body and its preview are both suppressed.

Limits are counted in UTF-16 code units, not bytes — 16,384 units is 16 KiB of plain ASCII, but up to four times that in UTF-8 for scripts outside the Basic Multilingual Plane. Clamping never splits a surrogate pair.

Set it with reindex:

nimbus connector reindex slack --depth metadata_only
nimbus connector reindex gmail --depth full

Two behaviours worth knowing before you choose:

• There are two different “defaults” here — do not confuse them. A newly added connector persists full, so it indexes bodies from its first sync. But nimbus connector reindex persists metadata_only when you omit --depth — the CLI passes that explicitly rather than leaving the setting alone. So running reindex without the flag lowers a connector from its starting point. Pass --depth full to reindex without changing the setting.
• Deepening is not retroactive. Lowering the depth strips or clamps existing rows immediately; raising it cannot bring back text that was never stored, so it reports 0 items affected and applies to future syncs only. To recover discarded bodies, force a fresh sync (nimbus connector sync <name> --full) or run nimbus index rebody --service <name> on the connectors that support it.

If you deliberately chose summary, re-apply it

Depth was not enforced for body content before schema V49. Every connector’s stored depth was whatever the column default happened to be, and summary had always behaved identically to full in practice — so the V49 migration resets summary to full rather than silently truncating every existing index to 512 UTF-16 code units on its next sync. Connectors you had set to metadata_only are untouched and need no action.

---

Adding a connector

See Connect your first service for the full OAuth flow walkthrough, including how to handle the browser redirect on Windows and WSL.

---

Removing a connector

Go to Settings → Connectors, click the connector row, and choose Remove. The remove action is HITL-gated — you will be prompted to approve it before anything is deleted. On approval, Nimbus:

1. Removes the connector’s Vault credentials (OAuth tokens or API keys).
2. Deletes all indexed items that came from that service.
3. Removes the connector’s sync state and scheduler entry.

The action is logged in the audit log and can be reviewed with nimbus audit verify.

---

Where to next

Connect your first serviceStep-by-step OAuth flow for your first connector.

ProfilesSeparate work and personal connectors with named profiles.

HITL & safetyHow Nimbus asks for your approval before any write action.