Run Liquibase Migrations on Release via Webhook

Schema migrations that run as a manual psql session are invisible, unrepeatable, and easy to skip. This blueprint turns them into an orchestrated release step: your CI pipeline calls a Kestra webhook when a release ships, io.kestra.plugin.liquibase.CLI runs liquibase update against the target database, and Slack confirms the migration in the same channel that watched the deploy. The changelog travels with the task through inputFiles, and the JDBC URL and credentials never appear in the flow because Liquibase reads them from environment variables populated by Kestra secrets.

How it works

1. release_webhook (io.kestra.plugin.core.trigger.Webhook) starts the flow when your release pipeline calls the webhook URL with the configured key. Replace change-me-strong-webhook-key with a strong random value before use.
2. run_migration (io.kestra.plugin.liquibase.CLI) receives the YAML changelog through inputFiles and runs liquibase update in the plugin's container image, which ships with the liquibase binary on the PATH.
3. Connection settings arrive through the standard LIQUIBASE_COMMAND_URL, LIQUIBASE_COMMAND_USERNAME, and LIQUIBASE_COMMAND_PASSWORD environment variables, each filled from a Kestra secret, so the flow file contains no credentials.
4. confirm_migration posts a Slack confirmation with the flow and execution identifiers, and the errors block posts a distinct alert when the update fails.

What you get

• Migrations that run exactly once per release, triggered by the pipeline instead of a human with a database client.
• An execution history entry for every schema change, with full Liquibase logs attached.
• Credentials isolated in Kestra secrets and injected through Liquibase's own environment variable convention.
• A Slack audit trail that pairs each schema change with the release that caused it.

Who it's for

• Platform teams replacing run-this-SQL-before-deploying steps in release runbooks.
• Database administrators who want changelogs applied by automation rather than shared credentials.
• Teams already using Liquibase in CI who want migrations visible in the same orchestrator as the rest of the release.

Why orchestrate this with Kestra

Liquibase knows how to apply a changelog, but not when a release happened, who should be told, or what to do on failure. Kestra supplies the trigger, the secret injection, the retry and error handling, and the notification, all around an unchanged liquibase update command. The webhook makes the migration a first-class release step that any CI system can call with one HTTP request.

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 plugin image bundles the H2 driver. For production, point it at your real database, for example jdbc:postgresql://db-host:5432/app or jdbc:mysql://db-host:3306/app.
• A Slack incoming webhook for confirmations 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 manually once and check that Slack reports the applied migration.
3. Replace the webhook key with a strong value and call the webhook URL from your release pipeline.

How to extend

• Keep changelogs in Git and load them with namespaceFiles instead of inline inputFiles, so the same files drive local development and production.
• Add the pre-deploy gate blueprint before this flow to validate the changelog and check pending changes first.
• Tag each release inside the changelog with tagDatabase, then pair this flow with the tagged rollback blueprint for one-click reversals.
• Route confirmations per environment by parameterizing the webhook payload and Slack channel.

Links

• Liquibase plugin documentation
• Liquibase documentation