Use AddFlyway to mount the migration scripts directory from the host into /flyway/sql in the container. migrationScriptsPath can be absolute or relative to the AppHost working directory, and Docker must be able to access it.
var builder =DistributedApplication.CreateBuilder(args);
var flyway =builder.AddFlyway("flyway","./migrations");
// After adding all resources, run the app...
builder.Build().Run();
The resource uses the flyway/flyway:13 container image, sets FLYWAY_LOCATIONS to filesystem:/flyway/sql, disables Redgate telemetry by default, and bind-mounts the scripts directory read-only.
Place SQL migrations in the directory passed to AddFlyway, following Flyway’s naming and versioning rules. The integration does not copy files into the container; it mounts the host path. Keep the files present and readable for the lifetime of the container.
The generic Flyway package does not add a database connection to the resource. Add the database resource to the AppHost and use the database provider’s Flyway extension to configure Flyway for that engine. The PostgreSQL extension configures Flyway’s connection arguments but does not add a resource dependency. Add an explicit dependency with flywayMigration.WaitFor(postgresDb) in C# or flywayMigration.waitFor(postgresDb) in TypeScript so the database is ready before the migration runs.
Flyway telemetry is disabled by default through REDGATE_DISABLE_TELEMETRY=true. Call WithTelemetryOptIn only when you choose to send Flyway usage data to Redgate:
Flyway is modeled as a container resource. This package does not add an application-level health check or a consuming-app client integration. Use the dashboard logs and state to inspect the Flyway process, and consult the provider-specific extension for its migration lifecycle behavior.