Deploy Ruby and Rails
Deploy a Ruby web application with a production server, database, assets, and background workers.
Openstead recognizes Ruby projects from Gemfile. Commit Gemfile.lock and your intended Ruby version configuration so the build uses a compatible runtime and reproducible dependencies.
Prepare a Rails application
Confirm that the application includes its production server, commonly Puma, and a driver for the managed database you intend to use. Configure production credentials, database settings, asset storage, and allowed hosts for your application's Rails version.
Add these environment values as appropriate:
RAILS_ENV=production
RAILS_LOG_TO_STDOUT=true
DATABASE_URL=<private-postgresql-url>If the application uses encrypted Rails credentials, add its RAILS_MASTER_KEY as a secret. If it reads SECRET_KEY_BASE directly, configure that securely and preserve it between deployments. Do not commit production keys or assume that setting an unused environment variable changes your application configuration.
Configure the web service
Choose Web Service and Railpack. A conventional Rails configuration can use:
| Setting | Value |
|---|---|
| Build command | bundle exec rails assets:precompile when the app serves compiled assets |
| Pre-deploy command | bundle exec rails db:migrate |
| Start command | bundle exec rails server -b 0.0.0.0 -p $PORT |
| Port | 8000 |
The pre-deploy command requires a paid instance. API-only Rails applications may not have an asset pipeline; omit the asset build in that case. Applications using a separate JavaScript asset tool must also run its required production build.
Ensure the web server and required gems are available in the production bundle. Avoid initialization that queries the private runtime database while assets are being compiled in the isolated build environment.
Health and host checks
Use the application's implemented health route, such as /up in Rails versions that provide it, and set that exact path in Openstead. Confirm it responds to a direct instance probe without login or a domain-only redirect. Do not assume every Rails version or application defines /up.
Configure allowed hosts and trusted proxy handling for the generated hostname and custom domain. Keep production security checks on normal application routes.
Files and background work
Use object storage for Active Storage in applications that need multiple instances. A local persistent disk requires a paid service and one replica, and is not automatically shared with worker services.
Deploy Sidekiq or another queue consumer as a separate background worker. For Sidekiq, a common command is bundle exec sidekiq; supply the correct private Key Value connection and application variables.
When to use Docker
Use a Dockerfile when the app needs a specific Ruby build, native system library, image-processing package, or a custom asset sequence. Rails-generated production Dockerfiles can be a useful starting point, but review the image's startup migrations, port, credentials, and storage assumptions before deploying.
Validate the homepage or API, compiled assets, login, a database write, and a queued job after deployment.