Rails

Nitroship detects Rails from a rails dependency in Gemfile and config/application.rb. The managed preset installs gems, precompiles assets, and runs Puma. Rails pages and APIs run on compute; public assets are served from the CDN.

DeployCopy Anchor Link

curl -fsSL https://nitroship.co/install.sh | bash
ntro login

Choose a compute region; there is no default. To choose Rails explicitly, put this in the deployment root:

{
  "build": {"framework": "rails"},
  "compute": {"regions": ["kr-icn"]}
}

ntro apps create my-rails-app
ntro deploy . --prod

The managed Rails preset requires the hosted builder. Remove --local from your command. After deploying, open a Rails page and an asset URL printed or referenced by that page.

Build and serverCopy Anchor Link

Ruby version selection reads .ruby-version, then the ruby declaration in Gemfile, then .tool-versions. The builder selects a pinned supported Ruby version nearest your declaration, or a stable default without one. Commit Gemfile and Gemfile.lock.

The build runs bundle install. When the application registers assets:precompile, it then runs SECRET_KEY_BASE_DUMMY=1 bundle exec rails assets:precompile; API-only apps without that task skip asset compilation. Errors from an existing asset task still fail the build. The dummy key is for asset compilation only, not your runtime secret. Puma runs in production and binds 0.0.0.0:$PORT, defaulting to 3000.

For JavaScript-backed assets, commit package.json and your lockfile too. The generated build selects Bun, pnpm, npm, or Yarn from the lockfile, falling back to packageManager, and installs those dependencies before asset compilation.

The generated image packages the application and installed gems. It stages public/ under /nitroship/static, which the builder automatically extracts to the CDN before starting the runtime. public/assets/application.css becomes /assets/application.css. Keep Ruby source, credentials, and private files out of public/. With no public assets, there are no static files to extract; Rails still handles dynamic requests on compute.

Production environment and databaseCopy Anchor Link

Use Environment variables for:

• RAILS_ENV=production and a strong, stable SECRET_KEY_BASE.
• DATABASE_URL when your database configuration uses it; use an external database.
• RAILS_MASTER_KEY when the app needs encrypted credentials. If your asset build reads encrypted credentials, make the key available to the build too.

Do not commit plaintext credentials or use an image-local SQLite database for durable production data.

Runtime limitsCopy Anchor Link

Generated images run as a non-root user. The instance filesystem is ephemeral; Rails temporary, log, and storage paths are directed under /tmp, and application logs go to stdout. Temporary disk space is not persistent storage. Configure Active Storage with S3 or another object-storage service for uploads instead of its local disk service.

Nitroship does not automatically run migrations, queue workers, or schedulers. Run bundle exec rails db:migrate in CI or locally against the external database. Run background workers separately; do not assume a Solid Queue or Sidekiq worker starts with the web process. Use Cron jobs for scheduled HTTP work rather than an in-process scheduler.

Framework selection and Dockerfile escape hatchCopy Anchor Link

build.framework: "rails" explicitly chooses Rails and overrides an automatically found Dockerfile. It cannot coexist with build.dockerfile.

Without an explicit framework, Nitroship detects the build as described in How Nitroship chooses a build. For extra OS packages, a custom process layout, or different asset compilation, remove build.framework and use your own Dockerfile.