Redgate Flyway GitHub Actions

Set up, check, and deploy changes with Redgate Flyway

---

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.

Actions

Action	Description
setup-flyway	Install Flyway CLI in your GitHub Actions workflow
migrations/checks	Run pre-deployment checks on migrations and target database
migrations/deploy	Deploy pending migrations against target database
migrations/generate	Generate migrations from your schema model
migrations/undo	Undo migrations on target database
state/prepare	Generate deployment script and run pre-deployment checks
state/deploy	Deploy state-based changes to target database

Usage

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

Best Practices for Secrets

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

Storing Secrets

• 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.

Accessing Secrets in Workflows

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.

Production Database Connectivity

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

License

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

Contributions

Contributions are welcome! See Code of Conduct

Breaking Changes

See Breaking Changes for a list of breaking changes.

Security Policy

Find a security issue? Please review our Security Policy.

Support

For support, please see the Support Policy.