EDITION: ENTERPRISE

If your CI/CD system isn't GitHub Actions, Flyway Desktop can still generate your deployment pipeline — as a Bash or PowerShell script you drop into whatever build server you already run. The generated script is plain Flyway CLI commands, so it works anywhere the CLI does.

Before you start

You'll need:

• A Flyway Desktop project inside a Git repository.
• A Flyway Personal Access Token, to license Flyway on your build agent.
• A CI/CD system that can run Bash or PowerShell, and somewhere to store secrets for it.

The Automate deployment page is a Flyway Enterprise feature, and the guided walkthrough described here is in public preview.

1. Open the Automate deployment page

Select Automate deployment in the left-hand navigation. The page header reads Automated migrations-based deployment or Automated state-based deployment, depending on your project.

The page needs a Git repository. If your project isn't in one yet, Flyway Desktop shows Automated deployments need a Git repository and offers to create one for you.

2. Choose how you want to deploy

On a new project you'll see Automate your deployments and a Get started button. Selecting it asks How do you want to deploy?, with three options:

• GitHub Actions — YAML workflows committed to .github/workflows and run by GitHub.
• Bash — shell scripts you can run from any platform: Jenkins, GitLab, Azure DevOps, or your local machine.
• PowerShell — the same, as PowerShell scripts.

Choose Bash or PowerShell — whichever your build agents run more comfortably — and select Continue. Your choice is saved with the project, so you're only asked once; the Change CI/CD provider link lets you switch later.

A wizard will now open for adding your first workflow file (once you have existing workflow files, you will see a list of files and you can add further files via the Add workflow button).

The wizard has four steps: Workflow, Environments, Review and Checklist.

3. Workflow: what should the script do?

The first step asks What should the workflow do?. The options depend on your project type and edition.

For migrations projects:

For state-based projects:

Undo requires undo migrations support and Generate rollback script requires snapshot comparison, so they only appear if your project and edition provide them.

Select Deployment and continue.

4. Environments: build your deployment pipeline

Select your environments is where you lay out the path your changes take to production, rather than picking a single target database.

Each step in the pipeline becomes a section of the generated script, and steps appear in order. Click a step to open the step editor, where you can set:

• Step name — used as the # === <name> === header in the script, so make it meaningful, like Test or Production.
• Target environments — use Add target environment to deploy to more than one database from a single step.
• Build environment — the temporary database used for deployment checks. This can be a named environment or a Docker container provisioned for the run.
• Manual review required — see step 5.
• What to deploy — All pending scripts (default), Up to a specific version (target), or Specific versions (cherryPick).

Each environment can be one you've configured in flyway.toml, or Defined in script if you'd rather fill in the connection details yourself later.

[!NOTE] Adding several targets to one step produces one commented block per target, prefixed with a note explaining how to run them concurrently — & and wait in Bash, Start-Job and Wait-Job in PowerShell. The script doesn't parallelise them for you: how work runs in parallel is your CI system's business, so the decision is left to you.

5. Adding a manual review pause

A shell script has no native concept of an approval gate, so Manual review required inserts a pause instead — a read -p in Bash, or a Read-Host in PowerShell — letting a reviewer inspect the output before the deployment continues.

If your CI/CD system has its own approval gates, use those and delete the pause from the generated script.

6. Review: check and edit the script

Review your workflow shows the generated script, and it's fully editable — adjust it before saving, or use the copy-to-clipboard button to paste it elsewhere.

The script is a sequence of Flyway CLI commands, each preceded by a comment explaining what it does:

# Run code review on migrations (optional)
flyway check -code -failOnError=true

# Check to see if the target environment has drifted since last deployment (optional)
flyway check -drift -environment="prod" -failOnDrift=true

# Generate a deployment report, containing a list of object changes (optional)
flyway check -changes -buildEnvironment="build" -environment="prod"

# Generate a dry run report to preview what would be executed without modifying the database (optional)
flyway check -dryrun -environment="prod"

# Execute pending migrations against the target environment, baselining if this is the first deployment,
# and embedding a snapshot to enable drift checks
flyway migrate -baselineOnMigrate=true -environment="prod" -saveSnapshot=true

The optional check steps only appear if your project and edition support them — code review, drift analysis, deployment reports and dry runs are all included where available. Delete any you don't want.

Environments appear as -environment="<id>" when you've picked a named environment from flyway.toml. If you chose Defined in script, you get a -url="<JDBC URL>" placeholder to fill in instead. Docker build environments add the provisioner and EULA parameters for you.

7. Checklist: set up your pipeline

The final step lists what your build server needs. These apply wherever you run the script — Jenkins, GitLab CI, CircleCI, an Azure DevOps pipeline, or anything else that can execute your chosen shell.

1. Install the Flyway CLI on your runner. The script calls flyway directly, so the CLI has to be on the agent that runs it.
2. Provide Flyway with credentials. Store them in your CI/CD system's secret store and expose them to the job as environment variables.
3. Add the script to your job. Call it from the relevant stage, once the variables are available.

Which secrets you'll need

Every script needs your Redgate credentials:

Database credentials are scoped to each environment. For a named environment with the ID prod, Flyway reads:

A pipeline covering several environments needs a pair for each, which is what lets one script deploy to several environments with different credentials.

Where a step doesn't use a named environment — because you chose Defined in script, or the environment ID isn't a valid variable name — the script falls back to FLYWAY_USER / FLYWAY_PASSWORD for targets and FLYWAY_BUILD_USER / FLYWAY_BUILD_PASSWORD for build environments. The Checklist shows whichever set applies to you.

[!NOTE] Environment IDs are only scoped when they contain letters, digits and underscores. An ID like pre-prod can't be used in a variable name, so it falls back to the shared FLYWAY_USER / FLYWAY_PASSWORD pair. If you want per-environment credentials, name your environments accordingly.

8. Save the script

Select Finish. Flyway Desktop opens a save dialog in your repository root, suggesting a name based on the script you chose — deployment.sh or deployment.ps1 for a deployment script, migrations_undo.sh for an undo one. Save it wherever suits your project.

Flyway Desktop confirms with Script saved as <name>. Add it to your CI/CD pipeline or run it manually.

Saved scripts are listed on the Automate deployment page. Select one to preview it, edit it in place — Save and Discard appear once you make a change — or use Open in editor to open it in your usual editor. A reminder banner, Don't forget to set up your pipeline secrets, stays on the page with a View setup button that reopens the checklist whenever you need it.

9. Run it

Commit the script, add your environment variables to your CI/CD system's secret store, and call the script from the relevant stage of your pipeline. You can also run it locally to check it end-to-end before wiring it into a job.

After the run, check the deployment reports Flyway generates for the changes applied and any drift detected.

Troubleshooting and further reading

• flyway: command not found — the CLI isn't installed on the agent, or isn't on its PATH. See Flyway command-line.
• Authentication or licensing failures — check FLYWAY_EMAIL and FLYWAY_TOKEN are set on the job and that the token is still valid. See Licensing for other authentication options.
• The wrong database was updated, or all targets used the same credentials — check your environment IDs are valid variable names, as described in step 7.
• A check step fails that you don't want — the optional flyway check commands can be removed from the generated script; only flyway migrate is required.

Useful links

• Common migrations-based deployment scripts — what each command does.
• Automating deployment using a CI/CD tool.
• Tutorial - Generate a GitHub Actions deployment workflow with Flyway Desktop — if you're on GitHub Actions.
• Flyway command-line.