GitHub and GitLab

Studios are not meant to manage code versioning. For that, we recommend you use either GitHub or GitLab.

There are two ways to authenticate git inside a Studio. Pick one — they conflict with each other:

• Use the GitHub or GitLab integration (recommended). Every Studio you start is automatically signed in over HTTPS, with nothing to set up per Studio.
• Use your own SSH keys. Choose this if your organization requires SSH. In that case you do not need the Lightning AI git integration at all, and you should disconnect it — see Using your own SSH keys instead.

GitHub integration

You can integrate GitHub during onboarding.

If you want to integrate GitHub after onboarding, go to Global settings > Integrations > Add Git Integrations > Github. Note: Github credentials are on a per-user basis. You can not set up a Github account for an entire organization or a teamspace. If your organization uses GitHub Enterprise, or runs its own GitLab instance, an admin can register it centrally so that members connect their own accounts to it — see Organization-wide Git providers.

GitHub organization approval

If the repositories you need belong to a GitHub organization, that organization may restrict which OAuth apps can access its data. Where that restriction is enabled, connecting your account is not enough on its own — an organization owner also has to approve the Lightning AI OAuth app before your token can see any of the organization's repositories.

Nothing looks broken in this state. gh auth status reports you as signed in, and your personal repositories clone normally, but private repositories owned by the organization behave as though they do not exist: git clone fails with Repository not found, and they are missing from gh repo list.

• If you are an organization owner, approve the app under GitHub > your organization > Settings > Third-party Access. GitHub documents the steps in Approving OAuth apps for your organization.
• If you are not an owner, request it from your own account instead: GitHub > Settings > Applications > Authorized OAuth Apps, select Lightning AI, and click Request access for the organization. An owner then has to grant it. See Requesting organization approval for OAuth apps.

Once it has been approved, retry the clone. If it still fails, disconnect and reconnect the integration in Global settings > Integrations.

What the integration does inside a Studio

Every time a Studio starts, if you have a GitHub integration connected, Lightning AI:

1. Signs the GitHub CLI (gh) in with the token from your integration, and registers it as git's credential helper, so git clone, git pull and git push over HTTPS work without prompting.
2. Sets your git user.name and user.email from your GitHub account.
3. Rewrites GitHub SSH URLs to HTTPS by adding this to the Studio's ~/.gitconfig:

[url "https://github.com/"]
	insteadOf = git@github.com:

That last step is what makes the integration seamless: git@github.com:... is the URL GitHub offers by default and the one baked into most .gitmodules files, so rewriting it means those remotes are fetched over HTTPS with your integration token — no SSH key needs to exist in the Studio at all.

The GitLab integration does the same thing for your GitLab registry URL.

GitLab integration

You can also integrate GitLab during onboarding. If you've already completed onboarding, but want to integrate GitLab, go to Global settings > Integrations > Add Git Integration > GitLab.

This will then ask you to put in your registry URL and your username, take you to GitLab to generate a personal access token which has to be pasted back in the integration setup dialog.

Verify the integration is working

The GitHub and GitLab CLIs are installed in every Studio, and the integration signs them in for you. In a Studio terminal, check that:

gh auth status      # GitHub
glab auth status    # GitLab

Then confirm you can clone. The CLI picks the URL for you, so there's no scheme to get wrong:

gh repo clone your-org/your-private-repo
glab repo clone your-org/your-private-repo

Use a private repository you have access to. Cloning a public repository proves nothing — public repos need no credentials and clone fine even when nothing is signed in. If the repositories you care about belong to a GitHub organization, test with one of those, since an organization with OAuth app access restrictions may also need to approve the integration.

Organization-wide Git providers

The integrations above connect to github.com and gitlab.com. If your organization uses GitHub Enterprise — either Enterprise Server or Enterprise Cloud — or runs its own GitLab instance, an organization admin registers it once for the whole organization, and members then connect their own account to it.

Credentials stay per user — the organization provider defines the host everyone connects to, and for GitHub the OAuth app used to do it. An organization can register at most one GitHub provider and one GitLab provider.

Register a provider (organization admins)

1. In your organization's settings, find the Git providers section and click Add Git provider.
2. Choose GitHub or GitLab.
3. Enter the Hostname where your organization reaches it — github.example.com for a GitHub Enterprise Server, or the hostname your GitHub Enterprise Cloud enterprise is served on. Enter the host only — no https://, and no path.
4. For GitHub, create an OAuth app under Settings → Developer settings → OAuth Apps → New OAuth App on that instance, with these values:

• Application name: Lightning AI
• Homepage URL: https://lightning.ai
• Authorization callback URL: https://lightning.ai/v1/auth/oauth/github/complete

5. Paste the resulting OAuth client ID and OAuth client secret into the dialog. GitLab providers need only the hostname; members authenticate with a personal access token instead.
6. Leave OAuth hostname blank unless your instance is not reachable from the public internet — see Network access below.

The client ID and secret cannot be edited later. To change them, disconnect the provider and register a new one — which invalidates every member's connection to it, so they will each have to reconnect.

Network access

If your instance is reachable from the public internet, there is nothing to configure. Leave OAuth hostname blank, and Studios can reach it from any cluster.

If it is not — for example it sits behind a VPN — then two independent paths need access, and they are reached from different places:

1. The OAuth flow, when a member connects their account. This has two hops:

• The member's browser is redirected to https://<hostname>/login/oauth/authorize. This happens on the member's own machine, so their normal VPN access is enough.
• Lightning AI's servers then exchange the authorization code at https://<hostname>/login/oauth/access_token. This is the only request our backend makes to your instance, and it must be able to reach that one endpoint.

If you don't want to expose your main hostname for that exchange, set OAuth hostname to a public front for it. It has to resolve in public DNS, and our backend must be able to reach the token endpoint on it. Requests still carry the TLS SNI and Host header of your main hostname, because a GitHub Enterprise Server only recognizes its own configured hostname.

2. Studios, for everything else. Cloning, pushing, API calls and gh or glab commands all run from the Studio itself, not from our backend. To give Studios access to an instance that isn't publicly reachable, run them on your own cloud account and configure network access from that cluster to your instance.

Connect your account (organization members)

Go to Global settings > Integrations > Add Git Integrations and choose your organization's provider rather than the public GitHub or GitLab option. GitHub Enterprise sends you through your organization's OAuth app; a self-hosted GitLab asks for a personal access token generated on that instance. Accounts connected this way are listed under the organization they belong to, separately from any personal github.com or gitlab.com account.

How it behaves in a Studio

In a Studio belonging to that organization:

• gh and glab are pointed at your instance through the GH_HOST and GH_ENTERPRISE_TOKEN (or GITLAB_HOST and GITLAB_TOKEN) environment variables, so those CLIs target your own instance by default.
• SSH URLs for your host are rewritten to HTTPS exactly as described above, using your hostname: git@github.example.com: becomes https://github.example.com/.
• The organization provider takes precedence. If you have connected one, any personal github.com or gitlab.com credentials you also have are not configured in Studios belonging to that organization.

Using your own SSH keys instead

If your workflow requires SSH — for example your organization mandates SSH keys, or you use deploy keys — then you don't need the Lightning AI git integration for that provider at all. Use your own keys instead of the integration, not alongside it.

Disconnect the integration first

Leaving the integration connected while using SSH is the most common source of confusion. The integration re-applies the insteadOf rewrite on every Studio start, so unsetting it from inside the Studio does not stick:

# This is undone the next time the Studio starts
git config --global --unset url."https://github.com/".insteadOf

To switch to SSH properly:

1. Go to Global settings > Integrations and Disconnect the GitHub (or GitLab) integration. Nothing is re-applied at startup after this.
2. In each existing Studio, remove the rewrite that a previous startup already wrote, by running git config --global --unset url."https://github.com/".insteadOf. This time it stays removed. For GitLab, use your registry URL instead, for example url."https://gitlab.com/".insteadOf.
3. Add your SSH key to the Studio and to your git provider (see below).
4. Verify. git config --global --get-regexp '^url\.' should print nothing, and ssh -T git@github.com (or git@gitlab.com) should greet you by name.

Disconnecting only stops the automatic sign-in. The gh and glab CLIs stay installed, and you can still sign them in yourself with gh auth login if you want them for non-git tasks such as opening pull requests.

Add SSH keys to a Studio

Keys stored in ~/.ssh persist across restarts of the same Studio, but they are deliberately not copied when a Studio is duplicated or published, so anyone using your template does not inherit your private key. To have a key available in every Studio you create, store the private key as a user Secret and load it from your .studiorc:

1. Generate an SSH key pair
2. In a Studio terminal, run ssh-keygen
3. Press enter to accept the default file location
4. Leave the passphrase empty, and use a dedicated key rather than reusing a personal one. The steps below load the key with no prompt, which a passphrase-protected key cannot do — if you set one, you will have to run ssh-add and type it yourself in every session, and startup clones will not work at all.
5. Copy the public key to GitHub or GitLab
6. cat ~/.ssh/id_rsa.pub
7. On GitLab, paste it into User Settings --> SSH Keys --> Add new key. On GitHub, paste it into Settings --> SSH and GPG keys --> New SSH key.
8. Store the private key as a user secret
9. Run cat ~/.ssh/id_rsa and copy the whole key, including its header and footer lines.
10. Go to Global settings > Secrets > New Secret, name it GIT_SSH_KEY, and paste the key as the value. Secrets are encrypted at rest, and user secrets are available as environment variables in every Studio you create.
11. Edit ~/.lightning_studio/.studiorc in your Studio and add the line that loads the secret into the ssh agent: eval "$(ssh-agent -s)" > /dev/null && echo "$GIT_SSH_KEY" | ssh-add -. The key itself never goes in this file.
12. Restart terminal and clone your repository
13. After opening a new terminal you can run git clone git@gitlab.com:your-username/your_repository.git

This ensures you will be authenticated to use your repo in each new Studio you create under your current user id.

Base Studios that clone at startup

A Base Studio whose on_start.sh clones a repository needs git credentials to be ready before the script runs. That is the case when either:

• You use the GitHub or GitLab integration, which is set up during startup, before on_start.sh runs.
• You already set your SSH key up from another Studio, as described above. Both the GIT_SSH_KEY secret and .studiorc apply across Studios, and .studiorc is sourced before on_start.sh runs, so the key is loaded in time. The key must have no passphrase — nothing can type one during startup.

A Base Studio cannot provide the SSH key for you: ~/.ssh is excluded when a Studio is duplicated or published, and a user secret belongs to the user who created it. Each user has to have done that setup themselves beforehand.

Troubleshooting

Organization repositories are missing or won't clone

You are connected, gh auth status looks fine, and your own repositories work, but private repositories owned by a GitHub organization act as though they do not exist — git clone reports Repository not found.

The organization restricts OAuth app access and has not approved Lightning AI. See GitHub organization approval.

"Host key verification failed" when cloning

The full error usually looks like this:

Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Despite the last line, this is usually not about permissions. It means the clone went over SSH — so if you are using the integration, the insteadOf rewrite is not in place for that host. Check it:

git config --global --get-regexp '^url\.'

If nothing is listed, the rewrite has been removed, by hand or by a startup script. The integration re-applies it every time the Studio starts, so restarting the Studio restores it. You can also clone over HTTPS directly with git clone https://github.com/your-org/your-repo.git, or let the CLI pick the URL for you with gh repo clone your-org/your-repo.

If you are using SSH deliberately, see Using your own SSH keys instead. Your Studio will also need the host's key in ~/.ssh/known_hosts, which is what this particular error is complaining about.