Orbit

Orbit Deployment Pipeline

The Pipeline tab is a single page that answers "what happens when we push". It shows every way a deploy can be triggered, every gate that can stop one, the state of each environment, and which build features are switched on, all read from your project's real configuration.

Where the Pipeline Lives

Open Orbit, click the project, and choose Pipeline under the Deployments group in the project tab strip. The page is labelled Deployment pipeline.

It is a read-only dashboard. Nothing is configured here; every section links through to wherever the setting actually lives. That is its value: one screen to understand the project, rather than reading eight settings cards.

Deployment pipeline overview for an Orbit project

Alerts At the Top

Two banners appear when they apply:

  • Deploy lock active, with a Manage link. Push-triggered deploys are being skipped.
  • N deployments awaiting approval, with a Review link. Someone needs to approve or reject them.

If either is showing and you are wondering why a push has not deployed, you have your answer without reading further.

Build Stats

A compact panel shows, over the recent builds: success rate, average build time, and how many succeeded. It is a health check rather than an analysis. For the full picture, see Orbit Project Analytics and Orbit Build Insights.

Trigger Sources

This section lists every route into a deploy for this project:

SourceWhat it shows
Git pushThe connected repository, or No repo connected
Branch previewsWhether previews are created automatically on any branch
Git tagThe tag pattern, if one is configured
Manual deployAlways available

Read this whenever you are surprised by a deployment. If a build appeared and nobody pushed, one of these is the explanation: a tag, a deploy hook, or someone pressing a button.

Gates and Safety

The largest section is the list of gates, each showing its current state with a Configure link to the relevant settings card.

GateWhat it does
Approval gateProduction deploys require explicit approval
Staging prerequisiteProduction waits for staging at the same commit
CI checksRequired checks that must pass, or No checks required
Freeze windowWeekends blocked, custom hours, or no freeze schedule
Deploy lockActive, or no lock
Health checkThe path checked after deploy, or Disabled
Auto-rollbackReverts on health check failure
Skew protectionThe retention window for old assets
Auto retryHow many times infrastructure failures are retried

Most of these gates apply only to push-triggered deploys. Manual deploys from the panel and deploy hooks pass straight through. The exception behaves differently, and the detail of each gate is covered in Deploying Your Project. Read that before you rely on a gate as a control.

Reading the Gates As a Checklist

For a project that matters, a sensible baseline is:

  • Health check: set, pointing at a path that exercises the app rather than a cached shell.
  • Auto-rollback: on. Without a health check it has nothing to act on, so the two go together.
  • Auto retry: one or two. It re-queues builds that failed on infrastructure errors such as a network blip, and does not retry code errors, so it costs you nothing but time saved.
  • Approval gate: on for anything where a bad deploy is expensive, off where it slows you down more than it protects you.

If the page shows Health check Disabled and Auto-rollback on, that combination does nothing. It is one of the easiest misconfigurations to carry for months without noticing, and this page is where you spot it.

Environment Flow

The Environment flow section draws each environment as a card with its current state: LIVE, BUILDING or PAUSED, the branch it tracks, and the retry number if the current deployment is a retry.

Badges on each card show what is enabled for that environment:

  • Smoke tests, GET requests run against chosen paths after each successful deploy.
  • Auto-promote, promoting staging to production after a number of healthy hours.
  • Canary, the percentage of traffic on a canary deployment.
  • Inherits prod vars, where staging merges production environment variables at lower priority.
  • Scheduled rebuild, where production rebuilds on an interval.

Each card links to that environment's deployments. If an environment says No deployments yet, it exists in configuration but nothing has shipped to it.

Active Features

The last section summarises build-level settings:

FeatureValues
Server modeSSR enabled or static only
Auto-create on pushWhether branch pushes create environments
Health checksOn or off
Build retryA maximum, or off
Deploy groupsGrouped with other projects, or standalone
Build timeoutThe per-build limit
Preview expiryDays before previews are paused, or never

Server mode is the one people get caught by. A framework that renders on the server needs it on; a static export does not. If your project builds fine and then serves a blank page or a 404 on every route but the home page, check this first. See Frameworks Orbit Supports.

Preview expiry is the housekeeping one. Set to never, preview environments accumulate indefinitely.

Using the Pipeline Page

When onboarding someone. Send them here first. It is a faster and more accurate briefing than any document, because it is generated from the live configuration.

When a deploy did not happen. Work top down: banners, then trigger sources, then gates. One of the three will explain it.

Before a risky release. Check the gates section reads the way you think it does. It is the difference between believing you have auto-rollback and having it.

During an incident. The environment flow tells you what is live where, and whether anything is mid-build.

Troubleshooting

The page shows No repo connected. The project has no repository. Connect one: see Connecting a GitHub Repository.

A gate is on but deploys still go through. It is push-triggered only. A deploy hook or a manual panel deploy is not affected.

An environment shows PAUSED. Preview environments pause automatically once past their expiry. Redeploy to bring one back.

Auto-promote is shown but nothing promotes. It requires the configured number of healthy hours with smoke tests passing, and is evaluated periodically rather than instantly.

Where To Go Next

Still need help?

Email us at support@kapsulehost.com or open a chat in KPanel.

Open KPanel