Tagged Database Rollback with Liquibase

Rolling back a database at 2 a.m. usually means someone with production credentials improvising SQL under pressure. This blueprint replaces that with an auditable one-click operation: the operator supplies a Liquibase tag and an explicit confirmation, io.kestra.plugin.liquibase.CLI runs liquibase rollback to revert every change set applied after that tag, and Slack records who rolled back what. Without the confirmation, the flow refuses to run at all.

How it works

1. The flow takes two inputs: tag, the Liquibase tag to return to, and confirm, a boolean that defaults to false.
2. require_confirmation (io.kestra.plugin.core.execution.Fail) uses its condition property to fail the execution immediately when confirm is false, with an error message demanding explicit confirmation. Nothing touches the database on that path.
3. rollback_to_tag (io.kestra.plugin.liquibase.CLI) connects through the standard Liquibase environment variables filled from secrets. The demo changelog creates a table, tags the database v1.0, then adds a column, and the task first runs liquibase update so the rollback has a seeded state to revert. Against a real database you remove that update line and keep only the rollback command.
4. liquibase rollback --tag={{ inputs.tag }} reverts every change set recorded after the tag, using Liquibase's automatic rollback for operations like createTable and addColumn.
5. audit_rollback posts the tag and execution identifier to Slack, and the errors block alerts when the rollback is refused or fails partway.

What you get

• Rollbacks as a repeatable operation with a required confirmation, instead of ad hoc SQL.
• A Slack audit trail naming the tag, the flow, and the execution for every attempt, successful or not.
• Tag-based targeting, so on-call staff reason about releases, not individual change sets.
• A refusal path that makes it impossible to revert a database by accident.

Who it's for

• On-call engineers who need a safe revert button during an incident.
• Database administrators formalizing who may roll back production and how it is recorded.
• Teams already tagging releases in their changelogs with tagDatabase who want those tags actionable.

Why orchestrate this with Kestra

Liquibase can rewind to a tag, but the command alone has no confirmation step, no audit trail, and no record of who ran it. Kestra adds typed inputs with a boolean guard, a Fail task that encodes the confirmation policy in the flow itself, secrets that keep production credentials away from terminals, and an execution history where every rollback attempt, refused or completed, is preserved.

Prerequisites

• A database reachable from the Kestra worker. For a zero-dependency demo, set the DB_URL secret to jdbc:h2:file:./demo-db with username sa and an empty password; the seeded update makes the rollback self-contained. For production, use your real JDBC URL, such as jdbc:postgresql://db-host:5432/app, and remove the seeding update command.
• Changelogs that tag releases with tagDatabase, so there is always a named point to return to.
• A Slack incoming webhook for audit messages and alerts.

Secrets

• DB_URL: JDBC URL of the target database.
• DB_USERNAME: database username.
• DB_PASSWORD: database password.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the four secrets to your Kestra namespace, using the H2 URL above if you just want to see it run.
2. Execute the flow with the defaults and watch it refuse: confirmation is false, so the Fail task stops it.
3. Execute again with confirm set to true; the demo seeds the tagged state, rolls back to v1.0, and Slack posts the audit record.

How to extend

• Remove the seeding liquibase update command and point the secrets at a real database whose changelog already contains tags.
• Load production changelogs with namespaceFiles synced from Git instead of the inline demo changelog.
• Pair with the migrate-on-release blueprint so every release tags the database it migrates, making this flow its undo button.
• Add a second approval layer by running this flow from a parent flow that requires a different operator to trigger it.

Links

• Liquibase plugin documentation
• Liquibase rollback documentation