Per-Site Git Tokens: Connect Each Client Site to Its Own GitHub Account

The agency Git problem

Here's a scenario every web agency knows: you manage 20 client sites. 8 of them are on GitHub under the client's own organization. 6 are on your agency's GitHub. 4 are on GitLab. And 2 clients insist their repos live in their own GitLab instance.

Until now, SiteBrief DevLab worked with a single connected GitHub account and a single GitLab account per user. That meant all PRs opened from one identity — your account — regardless of which client the site belonged to.

That's a problem for multiple reasons:

• Clients see your personal account opening PRs into their repos, not their own team
• You can't open PRs into repos where you don't have push access under your own account
• Organizations with strict access control block external contributors from creating branches

The fix: per-site tokens

DevLab now supports a separate GitHub or GitLab token per site. When you connect a site-level token, every DevLab operation for that site — generating fix PRs, rollback PRs, dependency bump PRs, autopilot — uses that token instead of your account-level one.

The account-level token still works as a fallback for sites that haven't been configured with a site-level token.

How to connect a site-level token

For GitHub

Open any site → DevLab tab → scroll to the GitHub repository panel. If your account-level GitHub is already connected, you'll see a link: “Using your account-level token. Connect a different account just for this site.”Click it, authorize via OAuth, and that's it.

Once connected, you'll see a blue badge showing the GitHub username this site is linked to: Site token: @client-github-handle.

For GitLab

Same flow — open the site's DevLab tab, scroll to the GitLab project panel, and click “Connect a different account just for this site.” Authorize via OAuth.

What operations use the site token

• Generate fix PR — security headers, WP_DEBUG, SEO tags, dependency bumps
• Rollback PR — revert a deploy that introduced issues
• Recovery pipeline — automated AI-driven fix when site is down
• Close PR — dismiss a PR from the DevLab UI
• Autopilot — scheduled PRs opened automatically for critical issues
• Dependency audit — vulnerability bump PRs for npm packages
• Stale PR notifications — checking open PRs for review activity

Mixing account-level and site-level tokens

You don't have to migrate everything at once. The most practical setup for agencies:

• Keep your agency GitHub account connected at the account level — covers all your own repos by default
• For each client site that lives under the client's GitHub org, connect the client-specific token
• Sites with no site token fall back to your account — so nothing breaks for existing setups