For the administrator: how to open Buff Code sign-in to the team through the company connector — configuration, certificate, who it admits, what is visible.

A developer’s Buff Code does not come to us directly but to your company’s connector. For this the connector turns on the developer gateway — an address in your network that receives sign-ins, model requests and tool calls. The platform already works with your repositories and systems through the same connector; the gateway is one more of its modes, not a separate program.

You need a connector v0.17.0 or newer (the minimum versions for individual features are on the overview page).

Turn it on

In the connector configuration add the block:

developer_gateway:
  listen: 0.0.0.0:8767                          # where to listen
  host: https://connector.company.local:8767    # how developers reach it
  tls_cert: /etc/connector/gw.crt               # your company’s certificate
  tls_key: /etc/connector/gw.key

and restart the connector. The log shows the line developer gateway: listening on 0.0.0.0:8767 (https), and in the workspace, on this connector’s card, a “Buff Code sign-in” line appears with the address and a copy button.

Key	What it means
`listen`	the address and port on which the connector listens for the gateway
`host`	the address developers enter; if not set, the connector shows `listen` as is
`tls_cert`, `tls_key`	the certificate and key for HTTPS; without them the gateway works over HTTP

Certificate

The certificate is yours. The gateway needs a certificate the developers’ machines trust: issued by your internal certificate authority or a public one. We do not issue certificates and add nothing to the system store of developers’ machines.
Without a certificate the gateway works over HTTP. On every start the connector writes a warning to the log, and the workspace shows next to the address: “The gateway runs without TLS — developers’ tokens cross the network in plain text”. This is acceptable only for a test on a single machine.

Who the gateway lets in

Only members of the organisation the connector is bound to who signed in from Buff Code. The connector checks each of them through Buff on the first request and repeats the check once a minute, so a device revoked in the workspace loses access to tools within a minute at most, and to models immediately.

If a developer signed in to another organisation, the gateway refuses with the message этот коннектор работает для организации X, а вход выполнен в другую (“this connector serves organisation X, but the sign-in is to another one”).

What passes through the gateway

What	Where it goes next
Sign-in with a code and token refresh	to Buff
The developer’s list of organisations and projects	to Buff
Model requests	to Buff, to the organisation’s model; the connector neither reads nor stores them
Connection tool calls	to this connector’s connections, on the developer’s behalf
Reading the knowledge base and the project’s repositories	to Buff

Buff goes to the model; the connector only passes the request on: on OpenRouter plans — to a third-party provider with Buff’s key; on dedicated capacity and in a custom setup — to the model on a dedicated machine, and nothing goes to third-party providers. The model keys stay with Buff. Tracker tokens and the other connection secrets stay on the connector. Buff Code receives neither.

What the administrator sees

In the workspace, on the connector’s card: the gateway address and a warning if it runs without TLS.
On the connector’s local page — the “Buff Code” section: which developers called tools, how many times, how many with an error and when for the last time. While nobody has called anything, it says so.
In the connector’s call log — every tool call, marked as made by a developer, with the developer’s name.

Mass rollout of the address

You can hand the host address to developers in advance with the BUFF_CONNECTOR_URL variable — then the sign-in form does not ask for it (see Installation).

Developer gateway