
Overview
Review apps are a great way to preview new features, changes, and bug fixes. This guide will teach you how to automatically generate ephemeral “review apps” on Fly.io for each pull request (PR) using GitHub Actions. This approach can be applied to other Git services and source code versioning software that supports branching and hooks.Quick Start
If you’ve worked with GitHub Actions before and want to jump right in, here are the steps to take:- Create a new repository secret on your GitHub repository called
FLY_API_TOKENand provide it with the returned value offly tokens org <ORG NAME> - Create a new workflow in your project at
.github/workflows/fly-review.ymland add the following YAML code. - Commit and push the changes containing your GitHub workflow.
https://pr-<PR number>-<repository owner>-<repository name>.fly.dev.
The workflow described above will spin up a single application without other resources; if data stores, multiple Fly Apps, or other resources are required, see Customizing your workflow.
For more details about each step, follow the guide below.
Setting up review apps on Fly.io
Set your Fly API token
Your GitHub Action will need a Fly API token to deploy and manage new review apps on Fly.io. You can get this token using the following flyctl command:https://github.com/<username or org>/<repository>/settings/secrets/actions. There, create a new Repository Secret called FLY_API_TOKEN with the value of your token.
Create your GitHub Action
Next, let’s create a new GitHub Action by creating a new YAML file in your app’s repository for our workflow:fly-review.yml file:
deploy step, superfly/fly-pr-review contains the custom Action with a shell script that creates and deploys your review apps. If you’re curious, check out entrypoint.sh for full details on how the script works.
Commit and push your workflow
Finally, commit and push your changes to your GitHub repository. Once pushed, any new PRs will spin up a review app for you to preview your code on Fly.io.Customize your workflow
Often our applications do not operate in isolation and require other resources to function. The sample workflow mentioned above spins up a stand-alone Fly App, but you can customize yourfly-review.yml GitHub workflow to create additional Fly Apps and resources, such as a Redis, Memcached, etc. You can find examples of these in the README for superfly/fly-pr-review-apps.
Customize with inputs
Thesuperfly/fly-pr-review-apps custom GitHub Action also provides a number of inputs that can be added to tweak behavior. See the README for the complete list.
These inputs can be added to the deploy step in your workflow using the with key, like so:
Defining resource specs
You probably won’t need the same specifications for the Fly Machines used by review apps as you do for your production app. There are two ways to override the resources used in review apps. 1. Specifying a differentconfig file: By default, review apps will use the fly.toml in your application root, but you can create a separate TOML file with different specs using the config input, like so:
vmsizecpucpukindmemoryha
Default secrets and environment variables
We recommend setting default values for any secrets or environment variables your review apps require so you don’t have to set them individually. You can do this by defining each secret as either a repository secret or an environment secret in your GitHub repo. If using environment secrets, these should be set on the environment used in your workflow, such asreview.
Once you have your secrets and environment variables set in GitHub, add each of them to your fly-review.yml workflow, separated by a space, like so:
Related Reading
- Continuous Deployment with Fly.io and GitHub Actions Shows how to set up automated CI/CD pipelines using GitHub Actions and Fly.io — a natural complement to per‑PR review deployments.
- Get information about an app A handy guide to inspecting apps, machines, statuses via CLI/API — useful when you’re creating and destroying review apps on pull requests.