Skip to content
lube

Release

GitHubCIDeploymentsFlags

Watch a change travel into production.

Bring repositories, pull requests, CI runs, services, environments, deployments, API contracts, and feature flags into one release view instead of five browser tabs.

  1. 01

    Pull request

    Commits and review context from GitHub

  2. 02

    CI run

    Checks and test evidence attached

  3. 03

    Deployment

    Which service, which environment

  4. 04

    Rollout

    Feature flag state per environment

One change, one release view

Its place in the loop

Release is where engineering work becomes production.

One connected loop, held on the stage this capability serves. The other stages stay as context so you can see what feeds in and what comes next.

BD
Discovery
Feedback
Product
Engineering
Release
Reliability
Evidence

Stage inventory

Release

Carry the change into production.

Deployment history

Review deployment evidence beside the service and environment it affected.

Available now

Feature flags

Keep rollout controls visible beside release context.

Available now

Automatic changelogs

Carry the change into production.

Coming later

Coming later reflects product vision, not a delivery commitment.

One change, end to end

Follow the artifact down the pipeline.

A single change moves from commit to pull request to deployment to flag to uptime. Each stage lights as the artifact arrives, so the release reads as one continuous path instead of five disconnected tools.

release artifact · one change

in flight
01Commitpushed to main
02Pull requestreviewed, merged
03Deployservice · env
04Flagrollout state
05Uptimeheld after ship
A change travels the release pipeline

Every surface a change touches

The whole change, in one view.

Reach

One change lights up many surfaces.

A merge is not one event. It touches the repo, CI, the service, its environments, the deploy record, the flag, and the monitors, in that order.

source controldeliveryrollout

one change · surfaces touched

  • 01Repositorycommit + PR
  • 02CI runchecks green
  • 03Servicecheckout-v2
  • 04Environmentproduction
  • 05Deploymentrecorded
  • 06Feature flagrollout state
  • 07API contractinspectable
  • 08Uptimemonitored
Surfaces one change touches, in order

Where it ran

Which build reached which environment.

The deployment grid shows the live version per service and environment, so a stale prod or an in-flight deploy is obvious at a glance.

servicesenvironmentslive version
servicedevstagingprod
api-primarynode2.4.12.4.12.4.0
webnext.js8.18.18.0
workernode3.33.33.3
Deployed version per service and environment

The switch

Rollout state, beside the deploy.

The feature flag that gates the change sits next to the deployment it affects. The percentage ramps through its stages without leaving the release view.

per environmentscheduled rampone view

checkout-v2

scheduled
  • Canary10%
    done
  • Half50%
    current
  • Full100%
    queued
The rollout, in the release view

Why it matters

1

release view instead of five scattered tools

GitHub

supported source-control integration

Per-env

feature-flag rollout visibility

Full

history from commit to deployment

An honest limit

GitHub is the supported source-control integration today. The release view reflects the systems lube connects to, not every tool in your pipeline.

Inside release

Go deeper into the release surfaces.

Stop reconstructing a release by hand.

Start free

GitHub is the supported source-control integration.