git push with buildpacks
The default. Flynn detects the language, builds with Heroku-compatible buildpacks, and discovers your process types. Custom or multiple buildpacks are one file away. Cancel a build with Ctrl-C.
Ship
Four ways in, one release model
Bring the repo you have. Flynn turns it into a release, keeps the last good one ready, and lets you scale each process type on its own.
Deploy paths
Pick the input. The output is always a release.
git push with a Dockerfile
Set the app's stack to container and the same push builds your Dockerfile on the cluster with BuildKit. Switch back to buildpacks whenever you like.
Push a built image
Deploy an image from your machine with flynn docker:push. Its entrypoint, command, and environment become the release.
GitHub App
Operators register one GitHub App for the cluster. App owners connect a repository, deploy any branch, turn on auto-deploy, and wait for Checks to pass before rolling out.
01 / Releases
Releases you can trust — and undo
- Zero-downtime by default. New processes start and come up before old ones stop.
- Automatic rollback. If the new release does not come up, the previous one keeps serving and the deploy is marked failed.
- Manual rollback. Roll back to any earlier release from the CLI when the bug only shows up in production.
- Config is a release too. Changing environment variables creates a new release with the same history and the same rollback path.
- Deploy history. List releases and deployments, tune batch size and timeout per app.
02 / Scale
Scale by process type, size by runtime
Declare the process types your app has — web, worker, clock — and scale each one independently. Additional web-facing process types get their own routes, so an admin UI can live beside the public site.
Each process type runs under a named runtime: small, medium, or large CPU and memory out of the box, plus any runtime your operators define. Those amounts cap the process. Operators can optionally reserve them on the host at schedule time. Under load, CPU is shared proportionally, so a large process gets twice the time of a medium one.
$ flynn scale web=3 worker=2 $ flynn limit:runtime worker large
03 / Jobs
One-off work without SSH
Run a migration, open a console, or execute any command inside a fresh container built from the app's current release — same code, same configuration, same database credentials.
Install the scheduler plugin and each app can own cron or interval jobs that run the same way, on a schedule, cluster-wide.
$ flynn run bin/rails db:migrate $ flynn scheduler:add --command "bin/rake reports" --type worker --cron "0 6 * * *"
04 / Environments
Staging from the same repository
Create a second app from the same repo with its own git remote, its own environment, and its own database. Push a branch to staging, push main to production. Both are just apps on the cluster.
Next
Ready to push?
Installing the CLI and connecting to a cluster takes a few minutes.