Deploy Rails | Rails 8.1 on Ruby 3.4 with Postgres
Rails 8.1 on Ruby 3.4 with Postgres, in the container Rails generates
Just deployed
/var/lib/postgresql/data
Just deployed
Deploy and Host Rails on Railway
Rails 8.1 on Ruby 3.4, in the production container Rails generates for itself.
About Hosting Rails
The Rails template on Railway deploys a starter pinned to Rails 7.0.3 and Ruby 3.1.2 - both from 2022. About one deployment in six fails.
It also deploys Redis from bitnami/redis with no tag. Bitnami restricted its public catalogue in 2025: that repository now carries digests and metadata but no version tags, so a plain bitnami/redis reference is a pull waiting to fail. This template does not ship Redis at all - add it when you actually need Solid Queue or Action Cable at scale, and use the official redis image.
Common Use Cases
- A Rails application with a real database, migrations and background jobs ahead of it
- An internal tool where Active Record and the generators are most of the work
- A starting point that boots correctly behind a proxy, on the assigned port
Dependencies for Rails Hosting
- Postgres, included in this template, on a persistent volume
- Nothing else.
Deployment Dependencies
- Rails guides: https://guides.rubyonrails.org
- Source: https://github.com/ak40u/rails-railway-starter
Implementation Details
This is a rails new scaffold on current Rails, with four changes:
| Change | Why |
|---|---|
| HTTP_PORT bridged from PORT | Thruster defaults to 80; the platform assigns the port |
| railway.json | Health check on /up, restart on failure |
| Encrypted credentials removed | The master key is gitignored, so a template cannot rely on it - SECRET_KEY_BASE is used instead |
| A root route | A fresh Rails app has no root, so a deployed template would greet you with a 404 |
Everything else is Rails own production Dockerfile: multi-stage, non-root user, jemalloc, bootsnap precompiled, assets built at image time.
/up is Rails built-in health endpoint - it returns 200 only if the app boots without raising, so a red check means the application genuinely cannot start. Migrations run through Rails own bin/docker-entrypoint, which calls db:prepare before the server starts: it creates the database on the first deploy and migrates on later ones.
| Variable | Why |
|---|---|
| SECRET_KEY_BASE | Generated; signs sessions and cookies |
| DATABASE_URL | Wired to the bundled Postgres over the private network |
| RAILS_LOG_TO_STDOUT | Logs reach the platform rather than a file nobody reads |
Why Deploy Rails on Railway?
A database, a domain and TLS from one deploy, and the container Rails itself recommends - so you are not maintaining a bespoke Dockerfile that drifts from the framework.
Template Content
