Skip to content

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.

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.

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:

VariableRequiredPurpose
GITHUB_APP_IDYesThe App’s numeric ID.
GITHUB_APP_PRIVATE_KEYYesThe App’s RS256 private key (PEM).
GITHUB_APP_CLIENT_ID / GITHUB_APP_CLIENT_SECRETYesOAuth client credentials, used once per install to verify that the person completing it actually installed the App themselves.
GITHUB_APP_WEBHOOK_SECRETOnly if you use the webhookVerifies the X-Hub-Signature-256 header on inbound webhook calls; a webhook request is refused without it.
GITHUB_APP_SLUGNoBuilds the friendlier https://github.com/apps/<slug>/installations/new install link; falls back to the numeric App ID when unset.

To set one up:

  1. Register a new GitHub App on github.com.
  2. 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/callback route — Orvanta uses the OAuth code GitHub appends to that redirect to verify the installer, rather than trusting the installation ID alone.
  3. Set the environment variables above on the Orvanta instance (API server and worker) and restart.
  4. 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.

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.