Test
On this page
Most teams run FusionAuth in more places than production:
- A local instance on each developer machine.
- Short-lived instances that start and stop with each CI run.
- A long-lived staging instance that mirrors production.
Each environment needs a reliable way to reach a known configuration.
Choose a Setup Tool#
Use Kickstart for local and CI instances. Kickstart only runs on an instance with no API keys, users, or tenants, so every new instance starts from the same configuration. To reset a local instance, delete the database and restart FusionAuth.
Use Terraform for staging and production. A staging instance lives as long as production does and needs ongoing changes. Kickstart can't apply changes to an instance that already has configuration. Apply the same Terraform configuration to staging first, then to production. For more about keeping environments in sync, see Deploy.
Update Test Instances#
Update local and CI instances whenever you update production. Test against the new version before production does. See Update a Development Instance.
Test Against FusionAuth
Learn how to run end-to-end tests against a real FusionAuth instance, reset the instance between runs, and run the same tests in CI.
Test and Deploy with GitHub Actions
How to use CI/CD with FusionAuth in GitHub.
GitHub Actions
Learn how to use FusionAuth with the GitHub Actions Marketplace.
Related
Learn how to run end-to-end tests against a real FusionAuth instance, reset the instance between runs, and run the same tests in CI.
How to use CI/CD with FusionAuth in GitHub.
Learn how to keep FusionAuth configuration in code and promote changes from one environment to another.
Learn how to create and change FusionAuth configuration with the FusionAuth Terraform provider.