Zero to Production: FastAPI on Fly.io and GitHub Actions
You push code to main. Tests run. Your API goes live a few minutes later.
This is how you build a professional deployment pipeline. You do not need a database or Redis for this setup. You only need one FastAPI app, one Docker image, one YAML config, and one GitHub Actions workflow.
The workflow looks like this: git push → GitHub Actions → run tests → build image → deploy to Fly.io → live
There are three parts to this system:
- Your FastAPI app. You package it in a Docker image so it runs the same way everywhere.
- Fly.io. It runs your image on small machines. It handles routing and health checks for you.
- GitHub Actions. It watches your code and deploys automatically on every push.
To make this secure, use a scoped deploy token. Do not use your personal Fly API token. Create a token that only has permission to touch one specific app. Store this token in GitHub Secrets as FLY_API_TOKEN.
Key technical details for your setup:
- Use a Dockerfile with a non-root user. This improves security.
- Bind your app to 0.0.0.0 in your Dockerfile. If you use 127.0.0.1, Fly cannot reach your app.
- Use a fly.yaml file. This file is your source of truth. It defines your region, memory, and port.
- Set up a health check endpoint in FastAPI. Fly uses this to ensure your app is running before it sends traffic to it. This allows for zero-downtime deployments.
In your GitHub Actions workflow, use the "needs: test" command. This ensures your app only deploys if your tests pass. If your code is broken, the pipeline stops before it reaches production.
This setup scales with you. You can add staging and production environments by using different config files like fly.stg.yaml and fly.prod.yaml.
Stop deploying manually. Move from "runs on my laptop" to "ships on every merge."
Source: https://dev.to/devded/zero-to-production-fastapi-on-flyio-and-github-actions-1ejo