These actions allow you to safely deploy database schema changes to your databases using Redgate Flyway. Supports 50+ databases including PostgreSQL, MySQL, SQL Server, and Oracle.

These actions can be used both for database deployment pipelines, and for validation of your PRs.

Tip: You can generate a ready-to-run GitHub Actions workflow from Flyway Desktop's Automated Deployment page. See also Automating deployment using a CI/CD tool.

• Deployment usage examples — applying changes to target databases (migrations and state, automated and manual-review variants, Enterprise and Community)
• Development workflow usage examples — supporting authoring, e.g. auto-generating migrations on a pull request

GitHub Actions secrets keep sensitive values like database credentials and license tokens out of your workflow files and logs.

• Use repository or organization secrets — navigate to Settings > Secrets and variables > Actions to add secrets. Organization-level secrets can be shared across repositories.
• Use environment secrets for sensitive targets — for production databases, store credentials under a GitHub environment (e.g. production). This scopes secrets to that environment and enables protection rules like required reviewers.
• Never hardcode credentials — keep database URLs, usernames, passwords, and Flyway license tokens in secrets rather than in workflow files, flyway.toml, or source code.
• Rotate secrets regularly — update secrets when team members leave or if a credential may have been exposed.

Reference secrets using the ${{ secrets.SECRET_NAME }} syntax:

- name: Run migrations deployment
  uses: red-gate/flyway-actions/migrations/deploy@v2
  with:
    target-environment: production
    target-user: "${{ secrets.FLYWAY_USER }}"
    target-password: "${{ secrets.FLYWAY_PASSWORD }}"

• Secrets are masked in logs — GitHub automatically redacts secret values from workflow output, but avoid echoing or writing them to files.
• Limit secret scope with environments — attach secrets to environments that have protection rules (e.g. required reviewers, branch restrictions) to control who can trigger deployments that use those secrets.
• Pass secrets explicitly — GitHub does not inject secrets automatically. Each step that needs a secret must reference it via with or env.

See Connecting to Production Databases for guidance on establishing network access between GitHub Actions runners and production databases.

The scripts and documentation in this project are released under the MIT License.

Contributions are welcome! See Code of Conduct

See Breaking Changes for a list of breaking changes.

Find a security issue? Please review our Security Policy.

For support, please see the Support Policy.