Ethica Capital
EthicaDocumentation

Rollback

How to undo a bad production release when the fix is to revert rather than ship a forward patch. For normal shipping order and environments, see Deployment.

Default approach

Ethica uses git revert on main: revert the bad commit(s), push, and let CI/CD redeploy automatically—the same pipeline that runs on merge to main.

This applies to:

  • ethica-api (DigitalOcean) — revert on main, redeploy via CI/CD.
  • Frontends (Netlify sites) — revert on main, redeploy via CI/CD.

Using Netlify’s “publish deploy” to pin an older deploy is possible for emergencies, but the documented path is revert + CI/CD so main matches what is running.

When to rollback vs forward-fix

Use judgment: rollback when the bad change is isolated and safe to undo quickly; forward-fix when reverting would break dependencies or data, or when a small patch is faster than untangling history. Formal criteria are not defined here—see Incident response when customer impact needs coordination.

Order after a revert

Match forward deployment order when it matters: API first, then frontends (see Deployment). If your pipeline deploys everything in one pass, you may not need to coordinate manually—only step in when a partial rollout would leave API and clients out of sync.

Database

Database rollback procedures are not defined yet. Production uses app-driven schema sync (dbSync with alter: true); reverting code does not automatically imply a matching schema story. Treat risky schema changes with extra care and document learnings when you formalize DB rollback or restore steps.