Skip to main content

Documentation Index

Fetch the complete documentation index at: https://paper.brimble.io/llms.txt

Use this file to discover all available pages before exploring further.

If a new deployment breaks production, roll back to a previous one. Rollbacks reuse the previous artifact, no rebuild, and finish in seconds.

​
Prerequisites

  • A project with at least two completed deployments.
  • The previous deployment must have been Active at some point, Brimble can only redeploy artifacts that finished building successfully.

​
Roll back

  1. Open the project.
  2. Click Deployment history.
  3. Find the deployment you want to restore. Each row shows the commit SHA, the message, the timestamp, and the status.
  4. Click ⋯ → Redeploy this version.
  5. Confirm. Brimble re-runs that deployment’s image and flips traffic to it within ~30 seconds.
Deployment history page showing several deployment rows with status chips, commit messages, branches, deployer avatars, timestamps, and the row-level
The rolled-back deployment becomes the new active one. Your deployment history adds a new row pointing at the same commit SHA.

​
What carries over and what doesn’t

A rollback restores the code artifact only. It does not roll back:
  • Environment variables. If you changed a variable since the old deployment, the rollback uses the current value, not the historical one.
  • Database schema. If a migration ran on the new deployment, the rolled-back code may be incompatible. Either roll back the migration manually, or write migrations that are forward- and backward-compatible.
  • External state. Side effects (emails sent, payments processed, files written) stay in place.
For migrations specifically, prefer additive changes: add columns before reading them, never drop a column in the same release that stops writing to it. This keeps rollbacks safe.

​
Troubleshooting

“Redeploy this version” is greyed out. The deployment never finished building, or the artifact has been pruned. Pick a more recent successful deployment. The rollback failed to start. Open the new deployment row. The logs show the same phases as a normal deployment; usually the failure is in the deploy phase, not the build, since there’s no rebuild. Check the runtime logs for startup errors. Traffic still goes to the broken version. Edge routing flips on health-check pass. If the rolled-back deployment is failing its health check, the edge keeps the previous one. Check Logs for startup errors and compare to a known-good deployment. The old version doesn’t run with the current database schema. A migration ran on the broken deployment and the old code can’t read the new schema. Roll the migration back manually, or write a forward-fix in a new deployment.

​
Cancel a stuck deployment first

If a deployment is hanging in pending or in progress and you want to roll back without waiting for it to fail, click Cancel on the deployment in the dashboard. Once cancelled, you can roll back to the previous active deployment.

​
Next steps

Last modified on May 9, 2026