9. CI/CD & Pipelines

Pipelines are how Build.io models the journey your code takes from a pull request to production. Rather than deploying directly to your live environment and hoping for the best, a pipeline gives your team a structured workflow: review changes in isolation, validate on staging, and promote to production with confidence.

This section covers how to set up and use pipelines, review apps, promotion, GitHub integration, and automated testing.

9.1 Setting up pipelines

A pipeline connects multiple Build.io apps into a single deployment workflow. Each app in the pipeline represents a stage—review, staging, or production—and code flows through them in order.

Creating a Pipeline

From the dashboard, locate the New + dropdown and select New Pipeline. Give the pipeline a name (typically the name of your project or service), then add your existing apps to the appropriate stages.

![][image47]

If you’re starting fresh, create your staging and production apps first (see Section 1.3), then group them into a pipeline.

Pipeline Stages

A pipeline has three stages:

Review — Temporary apps created automatically from pull requests. Used for testing and code review before merging. (See Section 9.2.)

Staging — Your pre-production environment. Code that’s been merged to your main branch deploys here automatically. This is where you run final QA, integration tests, and demos.

Production — Your live environment serving real users. Code reaches production by promotion from staging, not by a fresh build. (See Section 9.3.)

You don’t have to use all three stages. Some teams skip review apps and deploy straight to staging. Others have a single app and no pipeline at all. Use the stages that match your team’s workflow.

Pipeline Visibility

The pipeline view in the dashboard gives you a single screen showing what’s deployed at each stage, which commits are running where, and whether staging is ahead of production. This makes it easy to see at a glance whether there’s unreleased work waiting to go out.

![][image1]

9.2 Review apps

Review apps are temporary, isolated environments that Build creates automatically when you open a pull request. Each PR gets its own app with its own URL, so your team can see and test changes in a real running environment before merging.

How Review Apps Work

When review apps are enabled for a pipeline:

1. A developer opens a pull request against the connected repository.
2. Build detects the PR and creates a new app from the branch.
3. The review app is built, deployed, and given a unique URL.
4. The URL is posted back to the pull request on GitHub, so reviewers can click through directly.
5. When the PR is merged or closed, the review app is destroyed automatically.

This means every pull request becomes a live, clickable demo. No more “pull the branch and run it locally” for reviewers—they can see the change running in an environment that mirrors staging and production.

Configuring Review Apps

Enable review apps from your pipeline’s settings in the dashboard. You can configure:

![][image48]

Automatic creation — Whether review apps are created for every PR, or only when triggered manually. Automatic creation is convenient for teams that want every PR to be reviewable, but if your repo is high-traffic you may prefer manual creation to control resource usage.

Automatic destruction — Review apps are destroyed when their PR is closed. You can also set a staleness threshold—if a review app hasn’t been updated in a set number of days, it’s cleaned up automatically.

Config Variables — Review apps have their own set of config variables that can be accessed by clicking the Reveal Environment button

9.3 Staging and production promotion

Promotion is how code moves from staging to production. Instead of rebuilding your application against the production branch, Build takes the exact container that’s running on staging and deploys it to production. What you tested is what goes live.

How Promotion Works

When you promote, Build doesn’t trigger a new build. It takes the slug (the compiled, packaged version of your app) that’s currently running on staging and releases it on production. This eliminates an entire class of deployment issues—if it worked on staging, it will work on production, because it’s the same artifact.

Config vars are the only difference between environments. Your staging app might point at a staging database and a sandbox payment provider, while production points at the real ones. The code and dependencies are identical.

Promoting from the Dashboard

From the pipeline view, you’ll see a Promote button next to your staging app when staging is running a slug that hasn’t been promoted yet. Click it, confirm, and the promotion happens in seconds.

![][image49]

When Not to Promote

If staging is running code you’re not ready to release, simply don’t promote. Staging can accumulate multiple merged PRs before a promotion—there’s no requirement to promote after every merge. Some teams promote several times a day; others batch changes and promote once a week. Use whatever cadence works for your release process.

If you need to roll back production to a previous release, you can do so from the Activity tab of your production app. Each release is recorded, and you can roll back to any previous one.

9.4 GitHub integration

Build.io integrates directly with GitHub to connect your repositories to your apps, enable automatic deployments, and power review apps.

Connecting a Repository

From your app’s Deploy tab, find the Connection section. Select your GitHub organization, search for the repository, and click Connect. Once connected, Build can respond to pushes and pull requests on that repository.

![][image50]

Each Build.io app connects to one GitHub repository. Multiple apps can connect to the same repository if needed (for example, staging and production apps in the same pipeline both connect to the same repo).

Automatic Deploys

Once a repository is connected, you can enable automatic deploys for a specific branch. When code is pushed to that branch, Build triggers a new build and deploys the result automatically.

![][image51]

The most common setup is automatic deploys from your main branch to your staging app. This means every merged PR deploys to staging without any manual step. Production deploys then happen via promotion (see Section 9.3) rather than automatic deploy, giving you an explicit gate before changes reach users.

Manual Deploys

If you prefer to control exactly when deployments happen, you can trigger them manually from the Deploy tab. Select the branch you want to deploy and click Deploy Branch. This is useful for production apps where you want a human to initiate each deploy, or for deploying a feature branch to a staging environment for ad-hoc testing.

Deploy Status on GitHub

Build reports deployment status back to GitHub. When a deploy is in progress, succeeded, or failed, the status appears on the relevant commit and pull request in GitHub. This gives your team visibility into deployment results directly from their normal code review workflow.

9.5 Automated testing

Build.io includes a built-in CI testing solution so you can run your test suite as part of the same platform that builds and deploys your code. If you already have an external CI provider you’re happy with, that works too—Build integrates with both approaches.

Build.io CI

Build.io CI runs your test suite automatically as part of the pipeline workflow. When a build is triggered—whether from a pull request, a push to your main branch, or a manual deploy—Build can run your tests before the deploy proceeds.

This keeps your entire workflow in one place: code is pushed, built, tested, and deployed on Build.io without needing to configure a separate CI service, manage CI runner infrastructure, or coordinate between multiple systems.

Configure CI from the Settings tab of your app in the dashboard by ticking the Enable CI checkbox and setting the necessary config variables behind the Reveal Environment button:

![][image52]

Using an External CI Provider

If your team already uses GitHub Actions, CircleCI, or another CI service, Build.io integrates cleanly with it. Build watches for GitHub commit status checks and can gate deployments on those results.

Typical Workflow

Whether you use Build.io CI or an external provider, the workflow looks the same:

1. A developer opens a pull request.
2. The test suite runs—either on Build.io CI or your external provider.
3. Build creates a review app so the team can see the change running.
4. The PR is reviewed—both the code on GitHub and the running review app.
5. Once tests pass and the PR is approved, it’s merged.
6. The merge triggers an automatic deploy to staging.
7. Any additional integration or smoke tests run against staging.
8. When the team is satisfied, staging is promoted to production.

Wait for CI Before Deploying

If you’re using automatic deploys, you can configure Build to wait for CI to pass before deploying. This ensures that a broken build never makes it to staging automatically. Enable this from the Deploy tab under Automatic Deploys—check the option to wait for CI status before deploying.

![][image53]

When using Build.io CI, this is handled natively—tests run as part of the build and a failure stops the deploy. When using an external provider, Build watches for GitHub commit status checks and only proceeds when all required checks pass. If CI fails, the deploy is skipped and the failure is visible in both GitHub and the Build dashboard.

Running Post-Deploy Checks

After a deploy to staging, some teams run a lightweight smoke test or integration test suite against the live staging environment to catch issues that only appear in a production-like setting (network dependencies, real add-on connections, environment-specific configuration).

This can be triggered from Build.io CI as a post-deploy step, or from your external CI provider using a webhook or scheduled job that hits your staging URL and verifies critical paths. If the smoke test fails, you know not to promote to production.