The Automated Deployment page in Flyway Desktop can generate a ready-to-run GitHub Actions workflow that deploys your project. You pick a template, set a few options, click Save workflow, and Flyway Desktop writes the YAML into .github/workflows/ for you.

This tutorial walks through both the standard workflow and the variant with a manual approval step before deployment.

Before you start

You'll need:

• A Flyway Desktop project open.
• The project folder inside a git repository that is pushed to GitHub.
• A Flyway Personal Access Token. The Automated Deployment page has a Create one on Redgate link that takes you to the right place; the token will be one of the GitHub secrets you create later.
• Permission to add Secrets and Environments to your GitHub repository.

1. Open the Automated Deployment page

In Flyway Desktop, with your project open, go to the Automated Deployment page from the project navigation.

You'll see two dropdowns at the top of the recommended-commands section, a sample YAML preview below them, and a row of buttons (Save workflow, Copy to clipboard, Open repository in browser) underneath the preview.

2. Choose the GitHub Actions template type

In the Template type dropdown, choose GitHub Actions. The preview switches from a Bash shell script to a YAML workflow definition.

When GitHub Actions is selected, a banner appears reminding you that the workflow secrets include a Flyway Personal Access Token, with a link to create one.

3. Choose a sample script

In the sample script dropdown, choose one of:

• Deployment — a single-job workflow. For migrations projects it runs deployment checks and then deploys in the same job; for schema-model projects it prepares and then deploys.
• Deployment with manual approval — splits the workflow into two jobs. The first job runs the checks (migrations) or prepares the deployment script (schema-model); the second job deploys, but only after a reviewer approves it.

The options available depend on whether your project is a Migrations project or a Schema Model project — Flyway Desktop picks the right set for you.

4. Configure the variables

To the right of the sample script dropdown, fill in the variables. The preview rewrites itself as you change them, so you can see exactly what will be saved.

• Target environment — the database the workflow will deploy to. Pick one of the named environments configured in your project to have the workflow refer to it by name (the generated YAML will contain target-environment: <your-environment-name> and Flyway will look the connection up from the project's TOML at run time).
• Build environment (migrations projects only) — the throwaway database used by the deployment checks. Pick a named environment the same way. The workflow comments note that this environment will be erased during checks.

Each environment dropdown also has an (defined in script) option at the bottom of the list. Pick this when you don't want the workflow to depend on a named environment from your project's TOML — for example, when the deployment target only exists in your CI environment, or when different branches need to deploy to different databases. Choosing (defined in script) changes the generated YAML to use an inline URL placeholder (target-url: <target url> instead of target-environment: <name>); after you save the workflow, edit the YAML to fill in the real URL or, more commonly, replace the placeholder with a ${{ secrets.SOMETHING }} or ${{ vars.SOMETHING }} reference so the connection string lives in GitHub rather than in the committed YAML. Use Manage environments at the top of the dropdown if you'd rather add a new project environment than go the inline route.

5. Review the generated YAML

Scan the preview. The top of the YAML is a comment block from Flyway Desktop:

• A note about where workflows live in your repository, with a link to GitHub's workflow docs.
• A note about creating secrets and referencing them as ${{ secrets.NAME }}, with a link to GitHub's secrets docs.

If you picked Deployment with manual approval, there's an extra comment block at the top of the workflow explaining which GitHub Environments to create. Read that — step 9 below covers what to do with it.

6. Save the workflow

Click Save workflow. Flyway Desktop will:

1. Create the .github/workflows/ folder in your repository if it doesn't already exist.
2. Open a save dialog defaulting to workflow.yml inside that folder. You can change the filename if you want to keep multiple workflows side by side (for example deploy.yml and deploy-with-approval.yml).
3. Write the YAML to disk and confirm the file path.

After the save, a short commit walkthrough may appear, prompting you to commit and push the new file. Either follow it through, or commit and push the change yourself in your usual git client.

7. Open your repository on GitHub

Click Open repository in browser under the YAML preview. This opens the GitHub page for your repository in a new tab.

The remaining steps happen on GitHub.com.

8. Add the repository secrets

In your GitHub repository, go to Settings → Secrets and variables → Actions → New repository secret and add the secrets the workflow references.

Every generated workflow uses the same names:

• FLYWAY_EMAIL — the Redgate account email that owns your Flyway PAT.
• FLYWAY_TOKEN — the Flyway Personal Access Token itself.
• FLYWAY_USER, FLYWAY_PASSWORD — credentials for your target database.
• FLYWAY_BUILD_USER, FLYWAY_BUILD_PASSWORD — credentials for your build database. Only the Migrations workflows reference these (the build database is used during deployment checks); schema-model workflows don't need them.

9. (Manual-approval workflow only) Set up GitHub Environments

The manual-approval workflows gate the deploy job behind a GitHub Environment that requires a reviewer to approve before the job runs.

In your GitHub repository, go to Settings → Environments → New environment and create two environments:

1. production-read-only — used by the first job (checks or prepare). No protection rules needed.
2. production-write — used by the deploy job. Open the environment, add yourself (or a team) as a Required reviewer, and save.

You can give the environments different names if you prefer, but the names you pick must match the environment: lines in your YAML. If you change them in GitHub, update the YAML to match (and commit the change).

10. Run the workflow

In your GitHub repository, go to the Actions tab. Pick the workflow you just added from the left-hand list and click Run workflow on the right.

• For the standard workflow, the job runs straight through.
• For the manual-approval workflow, the first job (checks or prepare) runs, then GitHub pauses with a Review deployments prompt at the top of the run page. Click it, select the gated environment, and click Approve and deploy to release the second job. If anything in the first job looks wrong, you can reject instead.

When the run finishes you'll see green check marks on both jobs (or, for the standard workflow, on the single job).

Troubleshooting and further reading

• The Automated Deployment page has a Learn more link above the dropdowns — click it for the official Redgate help topic.
• Workflow fails on Setup Flyway — check that your FLYWAY_EMAIL and FLYWAY_TOKEN secrets exist and that the PAT is still valid.
• Workflow fails when connecting to the database — check the FLYWAY_USER / FLYWAY_PASSWORD secrets, and that the database is reachable from GitHub-hosted runners (or use a self-hosted runner if it isn't).
• Manual-approval workflow runs straight through without prompting — check that the deploy job's environment: value matches an Environment that has a Required reviewer configured. No reviewer means no gate.
• The Flyway GitHub Actions in the marketplace (red-gate/flyway-actions) have a README with additional samples, including the "Manual review between..." workflow that these generated workflows are based on.

Useful links

• Redgate Flyway GitHub Actions — the marketplace listing for the red-gate/flyway-actions/* actions used in the generated workflows, including sample workflows for blue/green deployments, drift checks, and the manual-review pattern.
• Flyway licensing and authentication — what the PAT does, how Enterprise licensing works, and how to troubleshoot auth errors from Setup Flyway.
• GitHub Actions: workflows and GitHub Actions: using secrets — the same GitHub docs the generated YAML comments link to, kept here for convenience.