Repository navigation
[FR] GitHub authentication using a GitHub App #470
Description
Activity
- added a parent issue
on Aug 19, 2025 Heya - yea this is something that could be supported in Sourcebot. Good callout w.r.t., service accounts being included in seat pricing for GHEC.
Since the token is scoped to either a repository or an organization, this means that it will need to be generated per-org (unlike the PAT that works across all orgs), so this is likely additional logic to be implemented.
Off the top of my head, it sounds like the flow will be (1) Admin creates a GitHub app and links it to Sourcebot, and (2) for that GitHub app, admin creates N app installations for the repos and orgs they want to index. There will need to be some relationship between the app installation and our
Connectionrepresentation.Thanks for the quick reply and putting it on your roadmap!
Off the top of my head, it sounds like the flow will be (1) Admin creates a GitHub app and links it to Sourcebot, and (2) for that GitHub app, admin creates N app installations for the repos and orgs they want to index. There will need to be some relationship between the app installation and our
Connectionrepresentation.I believe you are correct. The GitHub API does provide an endpoint to get all installations of an app, so those don't need to be manually configured.
Exactly @markszabo, @brendan-kellam . We are using this type of integration already for some other custom apps. We have an Enterprise app installed across all target organizations. A central service uses this GitHub App; after installation and authentication (using the key):
import { createAppAuth } from '@octokit/auth-app'; import { Octokit } from '@octokit/rest'; ... let octokit: Octokit; ... octokit = new Octokit({ authStrategy: createAppAuth, auth: { appId: secret?.app_id, privateKey: secret?.private_key, }, }); ...
It retrieves the installations:
const installations = await octokit.paginate(octokit.rest.apps.listInstallations);
This is something which would be super useful in our case. We are looking for some workaround for this issue.
Sourcebot could help with that, especially if the configuration of organizations is automatically updated when new organizations have the Enterprise app installed and are therefore included in the index as well. Within our GHEC, only short-lived PATs are allowed, which makes it impossible to maintain in the current setup across all our organizations.
Reacted by Mark SzaboHey @markszabo @lvthillo we shipped GitHub app auth recently and I just added it to the docs: https://docs.sourcebot.dev/docs/connections/github#authenticating-with-github
Please note that this was released as an EE feature and requires a license to use. Let me know if you have any questions! Closing this out for now
- added and removedenhancementNew feature or requestNew feature or request
on Mar 9, 2026
Summary
Looking at the docs it seems that currently only personal access tokens (either fine-grained or classic) are supported as a way to authenticate to GitHub and retrieve private repositories.
Would it be possible to support authenticating via GitHub Apps as well?
Details
The GitHub docs recommend using GitHub Apps over PATs for this type of long-lived integration.
Moreover for GitHub Enterprise Cloud setups, GitHub is charged per user account (which includes service accounts), so many companies will limit the number of service accounts and use GitHub Apps instead for automations.
A GitHub App can be installed on either entire GitHub organizations (including new repos within those orgs) or a selected set of repositories. This would help control the access SourceBot has (compared to a PAT, unless the PAT belongs to a dedicated service account).
The GitHub App has a private key, which can be used to create a temporary access token scoped to either an org or a repository, and then this token can be used to call the GitHub API. This is likely the logic that SourceBot would need to implement. Something like:
Since the token is scoped to either a repository or an organization, this means that it will need to be generated per-org (unlike the PAT that works across all orgs), so this is likely additional logic to be implemented.