Management and removal

Where to see what

In the app (the “Connectors” section) — the owner’s view: agents online or offline, which repositories they serve, which connections are running, what they gave the model and where they may go. The status updates itself.

On the agent’s local page — the operator’s view: the same plus everything that can be changed, and the logs. Management lives only here: installing code in your network is your decision, and the app does not make it for you.

Connectivity check

A connection’s “Check connection” goes to your system right now and answers not with “ok” but with what it found: the server’s version and edition, the account it signed in with, the number of repositories or projects in scope. This shows that exactly what you need has been set up — not merely that “there are no errors”.

The same with a command:

connector instance check jira_prod

The connection’s log

“Log” shows what happened in the connection: start-up, errors, outgoing requests (method, address, response code, duration and the name of the credentials — not the value). The first place to look when the bot is silent.

connector instance log jira_prod

Changes without a restart

Adding a repository, changing a token, fixing the list of projects — everything applies on the fly. Only what has really changed is restarted: the connector compares the connection’s fingerprint and touches only the processes whose settings changed.

Renaming restarts nothing and breaks nothing: neither the webhook link nor the charge history is tied to the name.

Updating an integration’s version

A connection is pinned to a version. When a newer one is installed, the connection gets an “Update to …” button. Before switching, the connector checks that this connection’s settings fit the new version, and refuses if something is missing — instead of a connection that falls over after the update.

connector install jira@1.4.1 --config /etc/connector/connector.yaml
connector instance set jira_prod --version 1.4.1 --config /etc/connector/connector.yaml

The old version stays on disk: a rollback is switching the version back.

Turning off without deleting

connector instance disable jira_prod --config /etc/connector/connector.yaml
connector instance enable  jira_prod --config /etc/connector/connector.yaml

A turned-off connection stays configured but does not work: the process stops, events are not read. Handy when the tracker is under maintenance.

Deleting a connection

“Delete” on the local page, or:

connector instance rm jira_prod --config /etc/connector/connector.yaml --dry-run
connector instance rm jira_prod --config /etc/connector/connector.yaml

The connection disappears from the config and the process stops. The secret files and the working directory stay on disk — the connector does not delete what may turn out to be needed: remove them yourself if the connection will not be needed any more.

Updating the agent

Download the new version, check the signature and replace the executable (or pull the fresh image and restart the container). The state directory and the config are kept: installed integrations, connections and secrets stay in place. The version is shown in the app.

Revoking access

In the “Connectors” section — “Revoke” on the agent you need. The link to the platform ends and the agent is disconnected. Revocation cannot be undone: the agent can be brought back into service only with a new pairing.

Revoking a connector is not the same as revoking an integration version: the latter concerns code, the former — this agent’s access.

Removing the agent

1. Revoke the connector in the app.
2. Stop and remove the agent:
   • binary — stop the process (systemctl stop …) and delete the file;
   • Docker — docker rm -f buff-connector and, if you like, docker volume rm for the state volume.
3. Delete the state directory and the config: they hold the agent’s key, git tokens and connection secrets.

The copy of the imported code stays with us — deleting it at the organisation owner’s written request is described in “Security”.