Services and environments
Carry the change into production with connected service context.
ServicesEnvironmentsDORARollback
A deploy record that remembers its context.
Record every deploy of a service into an environment, with the status trail, health verdict, and commit range that produced it. The four DORA metrics fall out of that record automatically.
Deploy frequency
14/day
Lead time
3.2h
Change failure
6%
MTTR
41min
Deployments sit at the heart of Release.
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
Release
Carry the change into production.
Available now
Deployment history
Review deployment evidence beside the service and environment it affected.
Feature flags
Keep rollout controls visible beside release context.
Automatic changelogs
Carry the change into production.
Every service, every environment, one version grid.
Read what is live where at a glance: each cell is the deployed version, colored by health, so a stale prod or a stuck staging jumps out.
servicedevstagingprodpreview
api-primarynode2.4.12.4.12.3.92.5.0
webnext.js8.18.18.08.2
billing-apigo1.91.91.8—
workernode3.33.33.33.4
More than a green checkmark.
Many CI labels, one service.
Aliases fold github_actions, gitlab, and api labels into a single stable service, each with its own typed environments.
aliasestyped environmentspreview URLs
- api-primarynode · 4 envsgithub_actionsapiapi-primary
- webnext.js · 4 envsgithub_actionsvercelweb
- billing-apigo · 3 envsgitlabapibilling-api
- workernode · 3 envsgithub_actionsworker
A rollback is just a linked deploy.
When you revert, the restoring deploy links back to the one it brought back and pins itself as current. The trail stays append-only.
append-onlysupersededrestored
checkout-v2 · production
#4819
2.3.9 ok
#4820
2.4.0 bad
rolled back
#4821
2.3.9 back
current
#4821 restored the last healthy deploy and superseded #4820
Every deploy ships a receipt.
Each deploy captures the commit range since the last success, with the author and pull request behind every change.
commit rangeauthorpull request
checkout-v2 → production#4821
- feat: new checkout flow#4821 · dana
- fix: tax rounding#4818 · sam
- chore: bump deps#4815 · renovate
since last success3 commits
Modeled on how deploys really vary.
A deployment is not one shape. lube records the strategy, trigger, provider, and health so the record matches reality.
Status
The lifecycle.
queuedin_progresssuccessfailurerolled_backinactive
Strategy
How it rolled out.
basicblue_greencanaryrolling
Trigger
What kicked it off.
pushmanualapipromoterollbackschedule
Provider
Who reported it.
github_actionsgitlabapimanual
Health
Post-deploy verdict.
unknownhealthydegradedfaulty
Timing
Recorded per deploy.
queuedAtstartedAtfinishedAtdurationMs
Honest scope
lube records and analyzes deploys. It does not perform them. Deployment data arrives from GitHub Actions, GitLab, or the API. There is no orchestration or rollout execution here, so first-class CI adapters beyond those flow in through the generic API.
See what surrounds a deployment.
Give every deployment its service and environment context.
Start free
Start with one service and follow it through.