GuidesAdvancedDatabase Migrations

Database Migrations with Flightcontrol

Flightcontrol supports running database migrations as part of your build and deploy process.

These migrations would be specific to your application framework, but generally speaking, there is a command that you can run to apply the migrations. For instance, with Rails projects, it would be:

rails db:migrate

Flightcontrol supports three different ways of running these migrations, depending on your needs.

Pre-Deploy Command

To run a migration as part of the deployment lifecycle but as a standalone process before deploying your application, you can add a preDeployCommand to your flightcontrol.json service definition, or supply a Pre-Deploy Command for the service in the dashboard.

We recommend only putting the migration command for one service in each environment, for instance, the web server service, and not the worker service. Generally speaking, most migrations are meant to only be run once, and not on every instance of your application.

For more details check the Pre-Deploy Command section.

Build Command

To run a migration as part of the Nixpacks build process, you can add a buildCommand to your flightcontrol.json service definition, or supply a Build Command for the service in the dashboard.

We recommend only putting the migration command for one service in each environment, for instance, the web server service, and not the worker service. Generally speaking, most migrations are meant to only be run once, and not on every instance of your application.

One important thing to note is that supplying a new build command replaces the default build command for the service. So, if you are using a build command to precompile assets, you will need to include that command in your new build command.

For instance, if your default build command is:

rails assets:precompile

The new build command would be:

rails assets:precompile && rails db:migrate

If you need help with your build command, please contact Flightcontrol support.

Procfile

When you use the Nixpacks build type, Flightcontrol will run the release phase of your Procfile after the build process is complete, if it exists.

This is not actually a great place to run migrations with Flightcontrol, especially if you have more than one service that uses the same code base - such as a web application and a queue processor. This is because both services get built in parallel, so both release phases will run.

For some web applications, this can trigger locks or other errors, as the migrations are meant to be run only once.

We recommend using the build command approach instead. Remove the migration command from the release phase of your Procfile with Flightcontrol.