# Deploy board for every environment, with one-click redeploys

> One screen showing what shipped to staging and production, who shipped it, and a button to deploy or roll back without leaving the board.

- Workflow type: app
- Services: Buildkite, GitHub
- Categories: Engineering, Operations
- Published: 2026-08-14

## What it does

- Lays your environments out side by side, each column listing recent deploys with the branch, commit message, author, how long the build took, and whether it passed
- Shows a health strip for every pipeline: how often deploys pass, how long they typically take over the last 30 days, and how long it has been since the last successful deploy
- Puts the matching pull request next to each deploy, so the title, the reviewer, and the size of the change sit beside what actually shipped
- Lets the team deploy a branch or redeploy a known-good build in one click, with an extra confirmation step on production and a record of who pressed the button

## What you'll need

- A Buildkite account containing the pipelines you deploy from
- Permission to start builds in Buildkite, not just view them. View-only access still shows the whole board, but the deploy buttons stay disabled
- A GitHub account with access to the repository your pipelines build, so deploys can be matched to pull requests
- Five minutes in the app settings to map each pipeline to an environment name your team recognizes

## Prompt

I want a deploy board my whole engineering team can open to see what shipped to each environment, and to ship again without leaving the screen. Build it as an app backed by Buildkite for the builds and GitHub for pull request context.

Start with a settings view where someone maps Buildkite pipelines to environments. Resolve the organization slug first with List Organizations, then populate a pipeline picker with List Pipelines. Each mapping row holds an environment name the team chooses (staging, production, canary), one or more pipelines that deploy to it, a flag for whether deploying there requires a confirmation step, and the GitHub owner and repository name used for pull request matching. Persist these mappings for the whole app so everyone opens the same board. Default the confirmation flag to on for any environment whose name contains production.

The main surface is a column per environment, in the configured order. Each column header shows the pipeline name plus two stats covering the last 30 days: the pass rate and the median build duration. Compute both in the handler by paging List Builds for a Pipeline with a created-from date 30 days back and reducing the returned build states and start and finish timestamps. Under the header, show the time since the last successful deploy, taken from the most recent passed build. Give the board a manual refresh control.

Below the header, list recent deploy builds for the mapped pipelines, newest first, using List Builds for a Pipeline. Each entry shows the commit message, branch, author, duration, state with a color, and relative time. Take the commit SHA, message, and author straight off the Buildkite build object. Important constraint: the GitHub catalog has no commit lookup operation, so do not design any view that fetches commit detail from GitHub. Clicking an entry opens a detail panel that calls Get a Build for the full record including per-job state. Note that builds are addressed by their per-pipeline sequential number, not by their UUID.

For each entry, match the build branch to its pull request. Call List Pull Requests on the mapped repository filtered by head branch, take the best match, then call Get a Pull Request for the title, the reviewers, and the diff size in additions, deletions, and changed files. Show that beside the deploy so the reviewer and the size of the change sit right next to what shipped, and link out to the pull request on GitHub. When no pull request matches the branch, show the branch name alone and skip the panel quietly rather than showing an error.

Deploy actions live in the board itself. A Deploy button opens a dialog where the user picks a pipeline mapped to that environment and a branch, then triggers Create a Build. Every past build in a passed state gets a Redeploy button that calls Rebuild a Build, so rolling back to a known-good build is one click. Builds still running get a Cancel button backed by Cancel a Build. When the target environment is flagged as requiring confirmation, add a confirmation step to the dialog that makes the user type the environment name before the deploy button enables.

Every deploy, redeploy, or cancel started from inside the app records who did it: the signed-in user, the environment, the pipeline, the branch or source build, the resulting build number, and the timestamp. Show that attribution inline on the matching board entry, reading something like "Redeployed by Priya from the board", and add a Deploy log view listing those records newest first so the board doubles as an informal deploy log. Builds triggered outside the app simply carry no attribution line.

In the setup and empty states, explain that viewing the board only needs read access to builds and pipelines, while the Deploy, Redeploy, and Cancel buttons need a Buildkite token with build write access. If the connected token cannot write, keep those buttons visible but disabled with a short inline explanation rather than hiding them.

## How to customize

- Choose which environments appear as columns and which pipelines belong to each one, named the way your team talks about them (staging, canary, production)
- Decide which environments demand a typed confirmation before anyone deploys, rather than production only
- Change how many recent deploys each column shows, and the time window behind the pass rate and typical duration stats

## FAQ

### Can anyone on the team deploy from the board?

Anyone who can open the app and whose Buildkite access allows starting builds. Every deploy and redeploy started from the board records the person who pressed the button, so the team can always see who shipped what.

### Does this replace Buildkite?

No. The board reads live from Buildkite and starts real builds there, so your existing pipelines, steps, and notifications keep working exactly as they do today. It is a shared view and a deploy button on top of what you already run.

### What if we have more than two environments?

Map as many as you like. Each environment you configure becomes its own column, so teams running staging, canary, and production side by side see all three at once.

### How does it know which pull request goes with a deploy?

It matches on branch name. When a build ran on a branch that has an open or recently merged pull request, the board pulls that pull request in and shows its title, reviewer, and diff size. If a branch has no matching pull request, the entry simply shows the branch on its own.

### Can we use it to roll back?

Yes. Every past deploy that passed gets a Redeploy button that re-runs that exact build, so returning to a known-good version is one click rather than a hunt through build history.

Use this prompt in General Input: https://www.generalinput.com/prompts/deploy-board-for-every-environment-with-one-click-redeploys