Migrating from Heroku
View as MarkdownMove a Heroku app to Atlasflow.
Heroku builds with buildpacks and runs processes defined in a Procfile. Atlasflow builds a container image instead, either from a Dockerfile or via automatic detection.
What maps over
| Heroku | Atlasflow |
|---|---|
| Git push deploy | Push to your default branch |
| Buildpacks | Automatic builds (Railpack) or a Dockerfile |
| Config vars | Environment variables |
web dyno | Your container listening on port 3000 |
| Custom domains | Custom domains |
Steps
- Create a project from your GitHub repository.
- Replace the Procfile. Heroku's
webprocess becomes your container's start command. With a Dockerfile, put it inCMD. With automatic builds, your framework's standard start command is used. - Set the port to 3000. Heroku assigns a dynamic
$PORT; Atlasflow expects port 3000 bound to0.0.0.0. Update your app to listen on 3000. - Recreate config vars as runtime variables. Replace Heroku add-on URLs (such as a database) with your own connection strings.
- Respond on
/. Make sureGET /returns a 2xx status for the health check. - Deploy, test the preview URL, then move your domain.
Things to know
- Each Heroku process type (worker, clock) becomes a separate Atlasflow project running that command.
- Atlasflow doesn't run release-phase commands or one-off dynos. Run migrations as part of your container start or as a separate job.
- Managed Postgres is coming soon; use your own database until then.
Next steps
- Supported frameworks: builds without a Procfile.
- Environment variables: move your config vars.
- Container requirements: port and health check.