Connector

The connector is a small agent that you run on your own machine, in your own network. It does two things:

• git bridge — carries repositories that are not reachable from the internet over to us and brings pull requests back;
• integration host — runs plugins from our catalogue: task trackers, knowledge sources (Confluence, Notion, Google Drive, Figma, folders and network drives), the web — and your own MCP servers.

What it is

The connector’s core is only the git bridge. It is deliberately small: you can read it in full before letting it into your network, and it does not grow with every new integration. Everything else is plugins: signed bundles that the connector downloads from the catalogue, verifies by signature and runs as separate processes under separate OS users.

      your network                              │        our side
                                                │
 your git ◀──locally──┐                         │
                      │                         │
 your tracker ◀locally┤   CONNECTOR             │
                      ├── core: git bridge ─────┼──outbound──▶ Buff platform
 (Jira, GitLab, …)    └── plugin ──┐            │
                          plugin ──┴─ own uids, │
                                     own hosts  │

Three properties of this picture hold everything else up:

1. Outbound connections only. The connector calls out by itself; nothing connects into your network. You do not need to open a port to the outside — not even for tracker events (polling always works). The exceptions are GitLab commit comments and Figma without a list of files and projects: they arrive only by webhook, and the connector’s event receiver must be reachable by whoever sends it; the FILE_COMMENT webhook comes from Figma’s cloud, that is, from the internet (more).
2. Secrets do not cross the perimeter. The git token, the tracker token and the agent’s own key stay on your machine. The plugin does not see them either: the connector builds the outgoing request and inserts the credentials itself — how exactly.
3. Boundaries are declared in advance. Where a plugin may go and which tools it gives the model is visible before installation, in the catalogue, and later — in the app.

What leaves and what does not

Everything that comes to us is then processed by the model according to the organisation’s plan: on OpenRouter plans — a third-party provider; on dedicated capacity and in a custom setup — a dedicated machine, without third-party providers. See Plans.

None of this is collected “just in case”: tracker events are read only in the selected projects and only when the bot is addressed directly, and the status report is exactly what you see in the app in the “Connectors” section.

Where to start

1. Download and install the agent on a machine that has access to your git and outbound internet access.
2. In the Buff app open “Connectors” → “Add connector” and get a one-time pairing code.

3. Set up the agent — through the local page or the terminal: the git provider, token, repositories and the pairing code.
4. Need a tracker — install the integration from the catalogue and create a connection. How it works from the team’s side — in the “Tracker integrations” section.

You can add a repository, change a token or adjust a connection later without a restart — changes apply on the fly.

Pages