Stephanie Herr

26 September 2025

New in Flyway: Pre and post deployment scripts for state-based deployments via callbacks

Flyway provides a lot of flexibility for releasing database changes in a safe and repeatable manner. Earlier this year, we added the ability to automate state-based deployments. This means the structure of the database is defined in version control and Flyway handles updating a target database to match it. The Flyway comparison engine does all the hard work of identifying what’s different and creating a script that will run on the target database to alter it so it matches the latest state. This is also referred to as a declarative approach, “make the target look like this.” The Flyway comparison engine makes sure no change is missed and will script the changes in the right order accounting for any dependencies. The state-based approach can get you automating your database deployments quickly.

With our latest release, we are introducing callback scripts for state-based deployments, which lets you execute custom logic before or after your state-based deployments. In this release, we have 3 callbacks that work for state-based deployments:

1. beforeDeploy – this script runs when the flyway deploy command is called and before any changes are deployed.
2. afterDeploy – this script runs after the flyway deploy command completes successfully.
3. afterDeployError – this script runs after the flyway deploy is called and fails.

These callbacks can be pure SQL scripts or advanced code scripts using Python, Bash, Java, or more, providing you with a lot of options when scripting out your release process.

Callback Examples

1. Take a backup of the target database before you deploy to it
If your database is small, you could write a simple SQL script as your beforeDeploy callback to take a full backup before a deployment is executed.

2. Update transactional data
If you need to update some transactional data, you can put that in an afterDeploy callback script. Running flyway deploy will update your schema and static data in the target database based on the state in version control. The afterDeploy callback will then run and update the transactional data you need. Since this callback is run after every deployment, scripts must be written idempotently using guard clauses to make sure the script won’t fail the next time flyway deploys your changes.

3. Log failed deployments
An afterDeployError callback script can be used to log problems with a deployment. Here’s an example afterDeployError.sql script that will log that an error occurred during a deployment to a table in your database.

Flyway user is a built-in placeholder that will be replaced with the current database user. The deploymentScriptName can be passed in using the placeholder parameter passed in as part of the command (eg. flyway deploy -scriptFilename=”myDeploymentScript.sql” -placeholders.deploymentScriptName =”myDeploymentScript.sql”).

4. Log execution time of a deployment
You can combine beforeDeploy and afterDeploy callback scripts to capture how long a deployment takes to execute. In beforeDeploy, insert an entry into a table with a start time. In afterDeploy, update that table entry with an end time. The execution time could be calculated as the difference between these two times. You may also want to write an afterDeployError callback script that will update the table entry with an end time and error information as well.

Supported databases

These callbacks will work for SQL Server, Oracle, PostgreSQL, MySQL, and all their cloud variants. These are the databases that Flyway provides state-based deployments for. The migrations-based deployment approach in Flyway works for more than 50 other databases and have even more callback options. Check out all the supported databases on our documentation site.

Things to know

If you create a new project using Flyway Desktop or the CLI (flyway init), a “callbacks” folder will be created in the root of the project. If needed, you can customize this location by using the new callbackLocations parameter.

You can have multiple callback scripts of the same type. They will execute in alphanumeric order. For example, two callback scripts (beforeCallback1.sql and beforeCallback2.sql) will execute in that order.

If you start with a state-based deployment approach and later move to a migrations-based approach, where the SQL scripts applied are stored in version control, these 3 callbacks also work for migrations-based deployments, making changing to a migrations approach easier later.

These callbacks are run in their own transactions every time flyway deploy is called:

Summary

The new beforeDeploy, afterDeploy, and afterDeployError callbacks give you even more control over the automated release process you define with Flyway. Let us know what you’re using callback scripts for in the comments below. Get in touch with us if you’re interested in learning more about how Flyway can help your database deployment processes.