Git automation

Three toggles under Advanced decide what happens between a git push and a running deployment. All three default to on, and all can be changed later in the application's settings.

Branch#

The branch production deploys from - the repository's default branch unless you pick another (GitLab and Bitbucket sources offer the full branch list at create time).

Example: main

Deploy on push#

Every push to the deployed branch builds and releases automatically, delivered by the GitHub, GitLab or Bitbucket webhook. For apps with a root directory, only pushes touching that folder rebuild (on Bitbucket every push rebuilds, as its payload lists no files).

Turned off, nothing deploys by itself - you release manually with Redeploy from the dashboard, which suits apps where releases are scheduled rather than continuous. See Rollbacks and redeploys.

Deploy every branch#

Every branch other than the production one gets its own preview environment: an isolated deployment with its own URL -

{branch}-{app}-{org}.light-cloud.io

• rebuilt on every push to that branch. Previews are how a change is reviewed running, before it merges. They carry their own environment variables and can differ from production. Full story: Preview environments.

Remove stale environments#

When a branch is deleted - typically after its merge - its preview environment is deleted with it. Previews never pile up; nothing keeps billing for a branch that no longer exists.

Turned off, previews out-live their branches until you delete them by hand.

The full loop#

With all three on, the lifecycle of a change looks like this:

1. Push a branch. A preview environment appears at its own URL.
2. Push again while the review runs. The preview redeploys each time.
3. Merge. Production builds and releases the merge commit.
4. Delete the branch. The preview environment is removed.

Nothing in that loop needs the dashboard - it is all driven by Git.

Related#