How do I rotate a GitHub token used by several Tares sources and MCP servers without editing each one?

Tares stores a GitHub token once, by name, under Settings, GitHub, so you rotate it in one place. Sources reference it as credential: name and MCP servers as credential:github/name, and every user of the token follows on its next poll or connection. The token is never returned by the API and never included in a catalog export.

How it works

Settings sits in the console footer. Its GitHub tab holds a GitHub token stored once under a name you choose. Nothing else keeps a copy of the token. Everything that needs it points at the name.

• Sources of the github connector set credential: name in their config instead of carrying a token each.
• MCP servers use credential:github/name as their auth value.
• Test on the stored token shows the GitHub login it belongs to, so you can confirm you pasted the right account’s token.
• The row for the token lists which sources and MCP servers use it, so you see what a rotation touches before you do it.
• Rotate replaces the token in that one place. Each source picks up the new token on its next poll, and each MCP server on its next connection.

The token is never returned by the API and never included in a catalog export. You can export and share a catalog without leaking the token, and a script that reads the API cannot read it back.

This is the same Settings area that holds your API keys and model providers. It is part of how an AI SRE setup keeps its credentials out of individual source definitions.

Set it up

1. Open Settings in the console footer and go to the GitHub tab.
2. Store your GitHub token under a name, for example github. Use a fine-grained token with these permissions:
   • Contents: read, plus write on a repository an agent should update.
   • Pull requests: read, plus write only if your agents write to pull requests.
   • Metadata: read.
3. Select Test. Tares shows the login the token belongs to. Check that it is the account you expect.
4. Point each github source at the name with credential. The source carries no token of its own:

- name: checkout-api
  connector: github
  poll: 2m
  config:
    repo: acme/checkout-api
    credential: github
    labels:
      - { name: repo, field: repo, primary: true }

5. In each MCP server that needs GitHub access, set the auth value to credential:github/github. That is the form credential:github/name with the name you stored.
6. Check the token’s row in Settings, GitHub. It lists the sources and MCP servers that use the name, so you can confirm every one is wired to it.
7. When the token expires or you need to replace it, create the new token on GitHub with the same permissions and select Rotate on the row. Paste the new token and save. Select Test again to confirm the login.

You do not open any source or MCP server again. Sources follow on their next poll, which for a github source defaults to every 2 minutes. MCP servers follow on their next connection.

What you get

• One place to replace a GitHub token, however many sources and MCP servers use it.
• No edits to source configs or MCP server entries during a rotation. They keep referencing the same name.
• A quick check of whose token it is, with Test, before and after the change.
• A visible list of everything that depends on the token, on the token’s row.
• A token that stays out of API responses and catalog exports, so sharing a catalog does not share the secret.

The tokens in Settings, GitHub are separate from Tares API keys. Rotating the GitHub token does not change any key you minted for a producer or an agent.

When something else fits

• If a source uses the GitHub App path, the github_app type, Tares manages that credential itself, so there is no token for you to rotate by hand.
• If you give each source its own token on purpose, for example to scope access per repository, store each under its own name in Settings, GitHub and rotate them separately.
• For the commands and setup of a local or server install, see Deployment.

Related