Git providers

Light Cloud deploys from GitHub, GitLab and Bitbucket. All three give you the same thing - every push builds and deploys, every branch can have a preview, and starter templates become a repository you own - through the mechanism each provider offers.

GitHub#

Sign in with GitHub, or connect it later from the GitHub badge in the header. Light Cloud installs a GitHub App: you pick which repositories it may see, and can change the selection any time in GitHub's own settings. One installation can serve several workspaces, and an owner links or unlinks it per workspace.

Pushes arrive as signed webhooks from the App, so nothing is configured per repository. Deploys are also reported back to GitHub as check runs and deployment statuses - see Deployments.

GitLab#

Sign in with GitLab, or connect it from the GitLab badge in the header or from the Create page. GitLab has no App concept, so the connection is an OAuth grant from your GitLab user with the api and read_user scopes: api is what creating push hooks and reading private projects requires, read_user identifies the account.

• Workspace connection. An owner connects GitLab for a workspace; every member can then deploy any project that GitLab user can reach. The same grant can serve several workspaces, and unlinking removes only that workspace's link. Disconnecting removes the grant itself.
• Pushes. When you create an app from a GitLab project, Light Cloud creates a push hook on that project. Pushes to the deployed branch build and deploy; pushes to other branches drive preview environments exactly as on GitHub. Deleting the app removes the hook.
• Branches. The project's branch list is offered at create time, so production can start from any branch, not only the default.
• One GitLab account per Light Cloud user. If the GitLab account you are connecting already belongs to another Light Cloud account, the connect is refused and you are offered to move it - the other account loses the connection, and the workspaces it served keep deploying through yours.
• Revoked access. If you revoke Light Cloud in GitLab, the connection is dropped on the next use and the badge asks you to reconnect. Nothing already deployed stops.
• Empty projects. A project with no commits cannot be deployed - GitLab reports a default branch for it that does not exist yet. Push a first commit, then create the app.
• Deploy feedback. Each deploy posts a commit status named Light Cloud - <environment> (the tick or cross on the commit, in the merge-request widget and in the pipeline view, so it counts toward "Pipelines must succeed"), records a deployment on a GitLab environment (production or preview/<branch> under Operate, Environments, with an Open button on the preview URL), and keeps one note per environment on each open merge request with the preview link. Both are switched per app in Settings, GitLab card. The connected GitLab user needs the Developer role or higher on the project.

Self-managed GitLab instances are not supported yet; the integration talks to gitlab.com.

Bitbucket#

Sign in with Bitbucket, or connect it from the Bitbucket badge in the header or from the Create page. Like GitLab, Bitbucket Cloud has no App concept: the connection is an OAuth grant from your Bitbucket (Atlassian) user, and Light Cloud asks for the account, email, repository (read, write, admin), project (read), pull request (read, write) and webhook scopes. Repository admin and project read are what creating a repository for a starter copy needs; write is what pushing that copy needs; the rest is listing, building and reporting.

• Workspace connection. An owner connects Bitbucket for a workspace; every member can then deploy any repository that Bitbucket user can read, in any Bitbucket workspace they belong to. The same grant can serve several Light Cloud workspaces, and unlinking removes only that workspace's link. Disconnecting removes the grant itself.
• Pushes. When you create an app from a Bitbucket repository, Light Cloud creates a webhook on that repository, signed with a secret it verifies on every delivery. Pushes to the deployed branch build and deploy; pushes to other branches drive preview environments exactly as on GitHub. Deleting the app removes the webhook.
• Branches. The repository's branch list is offered at create time, so production can start from any branch, not only the main one.
• One Bitbucket account per Light Cloud user. If the Bitbucket account you are connecting already belongs to another Light Cloud account, the connect is refused and you are offered to move it - the other account loses the connection, and the workspaces it served keep deploying through yours.
• Revoked access. If you revoke Light Cloud in Bitbucket, the connection is dropped on the next use and the badge asks you to reconnect. Nothing already deployed stops.
• Empty repositories. A repository with no commits has nothing to deploy. Push a first commit, then create the app.
• Monorepos. Bitbucket's push payload does not list the changed files, so an app with a root directory rebuilds on every push to its branch, not only when that folder changed.
• Deploy feedback. Each deploy posts a build status named Light Cloud - <environment> on the commit (the tick, cross or spinner on the commit, in the branch list and in the pull request's Builds column, so it counts toward "minimum successful builds" merge checks), updated on every build step, and keeps one comment per environment on each open pull request with the preview link. Both are switched per app in Settings, Bitbucket card. Bitbucket's Deployments dashboard is fed by Pipelines only, so deployments are not recorded there; the preview URL is in the comment and the status link. The connected Bitbucket user needs write access to the repository.
• Read-only workspaces. A Bitbucket workspace over its plan's user limit is read-only: pushes, including a starter copy, are refused by Bitbucket until the plan or membership is fixed on bitbucket.org.

Bitbucket Server and Data Center are not supported; the integration talks to bitbucket.org.

Starter templates#

A starter template is copied into a repository you own before the first deploy, so pushes to your copy drive the app:

• With GitHub connected, the copy is a private repository under the GitHub account shown on the Create page.
• With GitLab connected, the template is imported into a new private project under your GitLab user.
• With Bitbucket connected, the template is pushed into a new private repository in the Bitbucket workspace you administer.
• With none connected, the app deploys read-only from the shared template and auto-deploy stays off.

When more than one provider is connected to the workspace, the Create page's Repository row lets you choose which account receives the copy; the default is the first connected in the order GitHub, GitLab, Bitbucket. Only connections linked to the Light Cloud workspace are offered - unlinking a provider removes it from the choice. If the copy cannot be created (Bitbucket refusing the push, for example), the create stops with the provider's message instead of deploying the shared template.

Which one is being used#

The provider's mark is shown next to every repository reference - the application header, the environment's Source card, the environments list, each deployment's commit, and the deployer of a webhook-triggered deploy - and the header badges show each connection's state: green connected, amber not connected but you can connect it, grey not connected and only an owner can.

Related#