The six sections of the agent’s page: overview, connection, repositories, catalogue, integrations, your own MCP.

The agent serves its setup page only on a local address (127.0.0.1). It is not visible from the network, and nothing leaves it: providers, tokens and integrations are set up on the same machine where all of them stay.

connector setup --config /etc/connector/connector.yaml

The command prints an address with a token in the link — open it in a browser. The token is needed because this page installs code and writes secrets: 127.0.0.1 alone is not enough for that. By default it is generated on every start; in automation it can be pinned with the BUFF_ADMIN_TOKEN variable. Setting up a remote server — forward the port:

ssh -L 8765:127.0.0.1:8765 user@your-server

Checking access and picking repositories with checkboxes — the token is entered once and stays on this machine.

For the page to work together with the agent (edits apply on the fly, without a restart), start it like this:

connector run --config /etc/connector/connector.yaml --admin 127.0.0.1:8765

The “Catalogue” and “Integrations” sections appear only with a running agent (run --admin): installing a plugin and starting connections is the agent’s job, not the page’s. setup without the agent configures the git bridge and performs the pairing.

Overview

The first thing the page shows is the state: whether the agent is paired, how many providers and connections are set up, what gets in the way. Two warnings also appear here that are better seen before installing an integration than after:

“Integrations will not be started” — the process lacks the privileges to place an integration under a separate OS user (why).
“There is nothing to run integrations on” — the machine has no suitable Python (which one). When it does, the page shows exactly which interpreter is used.

The git bridge keeps working in both cases.

Connection

Three things that concern the agent as a whole rather than an individual integration.

The link to the platform. The relay address is already built into the agent — you only need to change it for your own installation. Next to it is the state directory (state_dir): it holds the agent’s key, tokens, installed integrations and their working directories. It must survive restarts.

Receiving events. The optional webhook receiver is one for the whole connector, not one per connection:

“Listen on” — the address and port on this machine (for example 0.0.0.0:8766). Empty — the receiver is off, and that is a working state: polling always runs. The exceptions are Figma without a list of files and projects and GitLab commit comments: they arrive only by webhook. For Figma the address must be reachable from the internet, because FILE_COMMENT comes from Figma’s cloud (more).
“The address your tracker can reach it at” — how this port is seen from outside. The agent cannot guess this: behind NAT or a reverse proxy the address is different.

The event receiver belongs to the connector: one address for all connections.

Pairing. Paste the one-time code from the Buff app and click “Pair and connect”. The code is valid for 15 minutes and is used once; after that the agent gets its own key and needs no more codes.

Repositories

The git bridge section. Add a provider — the type (GitLab, GitHub, GitHub Enterprise, Gitea, Bitbucket, Bitbucket Server), the address and an access token — and click “Check access”: the agent goes to your provider and shows what it sees.

Then tick the repositories you need from the list it got — you do not need to type anything by hand, so typos are ruled out. “Add provider” saves the selection.

The token is written to a file with 600 permissions in the state directory; the config gets only a reference to the file. It does not reach us — the platform sees only the list of repositories you selected and an “access yes / no” flag.

Catalogue

The list of integrations you can install. Each card shows before installation what the integration will get: the addresses it may go to, which credentials it will ask for, whether it accepts webhooks, how many tools it has and how many of them only read.

The catalogue: what the integration will be able to do is visible before it ends up on the machine.

“Install” downloads the signed bundle, verifies the signature and unpacks it locally. More — “Catalogue and plugin installation”.

Integrations

This is where connections live — links to specific systems. One installed integration can serve several: production and a sandbox, two sites, two development projects.

“Add connection” opens a form built from the integration’s own schema: the connector knows nothing about the fields of Jira or GitHub; it draws what the integration declared about itself.

The form is built from the schema the integration declares about itself.

Fields common to all:

Field	What it is
Name	what the connection is called at your place. Renaming breaks nothing: neither charges nor the webhook link are tied to the name
Development project	a project or space in Buff: questions and tasks from this system go there, and its “Ask” and research get the system’s tools. The project name within your organisation, without the organisation and without a slash
Credentials	a token, and where the tracker signs in with a pair (Jira Cloud, Bitbucket Cloud) — also the account. They are written to a file with `600` permissions; the form never shows them back
Sign-in method	where the integration offers several (Google Drive): a service account — you paste the JSON key; your own account — the client ID and client secret of your own OAuth client, and after saving, a “Sign in” button: the browser goes to the service and returns to this page; if the browser is on another machine, the return address is pasted into the field next to it
Accept webhooks	a toggle; the connector issues the link with the secret itself
Notes for the AI	free text about what the model should know about this system. It goes to the model together with the description of the connection’s tools — see “Tools and the model”
Who may ask the bot	for questions from comments in the system itself. Rules one per line: a login, an address, a domain (`@company.ru`) or a regular expression (`/…/`); the “Buff organisation members” checkbox — by the member’s address, and with single sign-on — any address on the verified domains. Empty and unticked — everyone may ask. To others the bot politely replies that they can ask in Buff, and starts nothing — see “Who may ask the bot”

The other fields come from the integration: the system’s address, the list of repositories or project keys, the bot’s alias and so on.

Notes for the AI are limited to 2048 characters — characters are counted, not bytes, so Russian text is no shorter than English. The “No length limit” checkbox lifts the limit, but only after you confirm in the window that opens that you understand the risk: excess text in the prompt makes instruction-following worse and costs more. While the limit is lifted, the connection settings show a card about the risks, and the connection list — a mark with a tooltip on hover. The connector truncates nothing: a lifted limit is your decision about the volume.

A saved connection starts right away as its own process and shows what it gave the model and where it may go:

The connection is running: its own process, its own set of tools, its own allowed address.

Each connection has four actions: “Check connection”, “Log”, “Configure” and “Delete”; when a newer version appears in the catalogue — also “Update to …”. What they do is in the “Management and removal” section.

Your own MCP

An MCP server you bring yourself: drop an archive, paste the address of a GitHub repository or the address of a server that is already running. The connector reads from the package how the server is started, installs the dependencies and shows a draft — what exactly will run and what the server asks for. It is saved only with your consent: nobody has checked the code, and it goes to the network by itself. The tools of such a server are checkboxes: the model gets only those marked as read-only. In detail — on the “Custom MCP servers” page.

An empty field means “do not change”

The page does not show secrets: in the form they are always empty. An empty field on save means “keep as it was”, not “erase”. So you can fix the project name or the list of repositories without entering the token again.

Local setup page