Git Integration
A git_repository connection ties an Orvanta workspace to a remote Git repository. It’s the connection type used by Git sync — see that page for what the connection does and does not do automatically today.
GitHub App
Section titled “GitHub App”By default, a git_repository connection authenticates with a personal access token. Set its is_github_app flag instead and Orvanta authenticates through the GitHub App integration, which mints short-lived installation tokens rather than relying on a long-lived PAT. This also lets you scope exactly which repositories the Orvanta deployment can reach, independent of any one user’s token permissions.
GitHub App is an Orvanta Enterprise feature.
Only github.com is supported — GitHub Enterprise Server (GHES) is not supported. There’s no Base URL setting: every call this integration makes — minting an installation token, the install callback’s OAuth exchange, listing repositories — goes directly to api.github.com / github.com, and nothing on the backend reads a GHES address.
Configuring the GitHub App
Section titled “Configuring the GitHub App”Each Orvanta instance authenticates through its own GitHub App, which you register on github.com and configure on the instance by environment variable — there’s no Instance Settings form for this:
| Variable | Required | Purpose |
|---|---|---|
GITHUB_APP_ID | Yes | The App’s numeric ID. |
GITHUB_APP_PRIVATE_KEY | Yes | The App’s RS256 private key (PEM). |
GITHUB_APP_CLIENT_ID / GITHUB_APP_CLIENT_SECRET | Yes | OAuth client credentials, used once per install to verify that the person completing it actually installed the App themselves. |
GITHUB_APP_WEBHOOK_SECRET | Only if you use the webhook | Verifies the X-Hub-Signature-256 header on inbound webhook calls; a webhook request is refused without it. |
GITHUB_APP_SLUG | No | Builds the friendlier https://github.com/apps/<slug>/installations/new install link; falls back to the numeric App ID when unset. |
To set one up:
- Register a new GitHub App on github.com.
- In the App’s settings, enable “Request user authorization (OAuth) during installation,” and set its Callback URL to this instance’s
/w/{workspace_id}/github_app/callbackroute — Orvanta uses the OAuth code GitHub appends to that redirect to verify the installer, rather than trusting the installation ID alone. - Set the environment variables above on the Orvanta instance (API server and worker) and restart.
- Install the App to your GitHub organization or account, then start the install flow from workspace settings.
As a workspace admin, you can install the App against multiple organizations and link each installation to one or more Orvanta workspaces you administer. The installation token issued this way is scoped to Git sync only — it isn’t a general-purpose credential.
Network requirements
Section titled “Network requirements”Your Orvanta instance talks to GitHub directly — outbound HTTPS to api.github.com (minting and using installation tokens) and github.com (the install flow and its OAuth callback exchange). There’s no separate relay in this path: if your GitHub organization uses IP allow lists, allow-list your own Orvanta instance’s outbound IP address.
Importing / exporting to/from another Orvanta instance
Section titled “Importing / exporting to/from another Orvanta instance”A GitHub App installation belongs to one GitHub organization at a time, so moving it to a second Orvanta instance means transferring the installation record rather than reinstalling the app. From the source instance, use the “Export” action on the installation to generate a JWT and copy it (the UI copies it to your clipboard automatically); on the destination instance, paste that JWT into the “Import” action to register the installation there.
That JWT carries the right to request installation tokens on the org’s behalf, so treat it like any other credential. To revoke it, uninstall the GitHub App from the organization and reinstall it to re-associate it with an Orvanta instance.