Ruby on Rails · Deployment guide · Hosting

Deploy Ruby on Rails with the runtime made explicit.

Database-backed products, APIs, admin systems, and server-rendered Ruby applications. Darwa AI connects the repository, runs bundle install && bin/rails assets:precompile, deploys the result on ruby application server, and keeps domains, HTTPS, releases, logs, and billing in the same workspace.

Ruby application server
Deployment model
bundle install && bin/rails assets:precompile
Build command
Rails application and compiled assets
Expected output
Web Services
Recommended Darwa product
Deployment contract

What a production Ruby on Rails deployment needs.

These are operational requirements, not a generic framework feature list. Confirm them in the repository before the first release.

01

Build

Use bundle install && bin/rails assets:precompile. Commit the lockfile and pin the runtime version so a rebuild installs the same dependency graph.

Review deployment docs →
02

Start

Production start: bundle exec puma -p $PORT. The command must stay in the foreground and report a failed boot with a non-zero exit code.

Explore Web Services →
03

Artifact

Expected deployable output: Rails application and compiled assets. Generated artifacts should come from the build rather than being edited after release.

Configure the build →
04

Configuration

Store secrets and environment-specific values in the service environment. Do not commit production credentials or bake them into frontend bundles.

Manage configuration →
05

Health and logs

Expose a lightweight health endpoint, keep startup logs actionable, and verify the public endpoint after every release.

See runtime operations →
06

Known boundary

Set RAILS_MASTER_KEY securely, run migrations as a controlled release step, and operate Sidekiq or other job processors separately.

Check a workload with Darwa →
Release path

From Ruby on Rails repository to a repeatable release.

A successful first deploy is not enough. The release must be reproducible, observable, reversible, and safe to scale.

Connect source01

Select the repository and production branch. Keep preview work isolated from the production service.

Detect and confirm02

Confirm ruby application server, the build command, output, and production start command instead of relying on a lucky default.

Add environment03

Set secrets and public configuration with the correct build-time or runtime scope.

Deploy and verify04

Watch the build, startup, and health checks; then exercise a real application path rather than only the homepage.

Attach the domain05

Point the domain after the generated endpoint is healthy. Managed HTTPS should complete before traffic is moved.

Plan rollback06

Keep the previous successful release available and make database changes backward-compatible before scaling replicas.

FAQ

Answers before you deploy.

Can Darwa AI host Ruby on Rails?+

Yes. Database-backed products, APIs, admin systems, and server-rendered Ruby applications. The recommended starting product is Web Services, subject to the runtime boundary described on this page.

What build command should I use for Ruby on Rails?+

Start with bundle install && bin/rails assets:precompile. Keep the dependency lockfile committed and test the same command in a clean environment before deployment.

What starts Ruby on Rails in production?+

Use bundle exec puma -p $PORT. A server deployment must listen on the assigned port, stay in the foreground, and exit when startup fails.

Can I connect a custom domain?+

Yes. Deploy to the generated endpoint first, verify health, then connect the domain and wait for managed HTTPS before moving traffic.

Where should secrets be stored?+

Use the service environment and keep production secrets out of Git, build logs, browser bundles, and image layers.

How do I deploy without downtime?+

Use health checks, backward-compatible data changes, a verified new release, and a retained previous release that can be restored quickly.