Migrating from Railway
View as MarkdownMove a Railway service to Atlasflow.
Railway and Atlasflow are a close match: both deploy from GitHub and both can build your app automatically. Atlasflow uses Railpack, the same open-source build tool Railway created, so auto-detected builds should feel familiar.
What maps over directly
| Railway | Atlasflow |
|---|---|
| Deploy from GitHub | Connect a GitHub repo |
| Nixpacks/Railpack auto-build | Automatic builds (Railpack) |
| Service variables | Environment variables (build/runtime) |
| Custom domains | Custom domains |
| Usage-based billing | Usage and credits |
Steps
- Create a project from your GitHub repository. If you don't have a Dockerfile, Atlasflow auto-detects your stack.
- Set the port to 3000. Railway injects a dynamic
PORT; Atlasflow expects your app on port 3000. Bind to0.0.0.0. See Container requirements. - Recreate your variables. Copy Railway service variables into Atlasflow as runtime variables (and build variables where needed). Replace any Railway-provided references (like a managed database URL) with your own connection string.
- Deploy and test against the preview URL.
- Move your domain to Atlasflow and verify DNS. See DNS configuration.
Things to know
- Atlasflow deploys one container per project. To deploy multiple services from one repo, create multiple projects.
- Managed Postgres, object storage, and queues are coming soon. Until then, bring your own database and point a runtime variable at it.
Next steps
- Supported frameworks: how auto-detection works.
- Environment variables: set runtime config.
- Custom domains: cut over your domain.