Deploy Ruby on Rails on Nodion

Deploy Ruby on Rails step by step

1. Build from the generated Dockerfile Create an application from your GitHub, GitLab, Bitbucket or Gitea repository in the region EU Central. Rails 7.1 and later ship a Dockerfile, so the form preselects the Dockerfile strategy. This is the path for apps with jsbundling, cssbundling or Vite: the JavaScript build runs in your Dockerfile, just as you set it up.
2. Set the master key and the port Add RAILS_MASTER_KEY with the contents of config/master.key as a secret on the Environment tab. Nodion sets no PORT for Dockerfile apps: the server listens on the web process port, which the form fills from EXPOSE. Rails 7.1 and 7.2 expose 3000 for Puma. Rails 8 exposes 80 for Thruster, which runs in front of Puma; the image runs as a non-root user, so set HTTP_PORT=8080 and make 8080 the web process port on the Processes tab.
3. Attach PostgreSQL Create a PostgreSQL database in the same region and attach it on the Environment tab; Rails uses the DATABASE_URL it gets on the next deploy. The generated bin/docker-entrypoint runs bin/rails db:prepare before the Rails server starts, so pending migrations run when the new version boots. You can also set ./bin/rails db:migrate as the app's release command (API field release_command, see the Docker guide), which runs once per deploy before the new version starts.
4. Use /up as the health check path Rails 7.1 and later answer /up with 200 once the app has booted; set it as the health check path in the app settings. Nodion calls each instance with its internal IP as Host, so if you set config.hosts, exclude /up from host authorization, or the release never goes live. config/environments/production.rb

   config.hosts << "www.example.com"
   config.host_authorization = { exclude: ->(request) { request.path == "/up" } }

5. Or use buildpacks for importmap apps An app with importmap and no package.json can choose Buildpacks in the create form instead. Nodion then runs bundle install without development and test gems and assets:precompile with RAILS_ENV=production and SECRET_KEY_BASE_DUMMY=1, starts Puma with config/puma.rb on PORT and sets RAILS_SERVE_STATIC_FILES and RAILS_LOG_TO_STDOUT. Migrations run from a Procfile: Procfile

   release: bin/rails db:migrate

Good to know

• Solid Queue and SidekiqWith buildpacks, add worker: bin/jobs (Solid Queue) or worker: bundle exec sidekiq to the Procfile together with an explicit web: bundle exec puma -C config/puma.rb; without a web: line the first Procfile entry other than release: becomes the default command. Then add a process named worker without a port on the Processes tab. With the Dockerfile, give that process the command ./bin/jobs or bundle exec sidekiq instead. Valkey in the same region gives Sidekiq its REDIS_URL.
• The extra databases of Rails 8A Rails 8 app generated for PostgreSQL also lists cache, queue and cable databases for production in config/database.yml, and DATABASE_URL only sets the primary one. Give the others a connection as well before the first deploy, or remove the ones your app does not use.
• Ruby versionWith the Dockerfile, Ruby comes from RUBY_VERSION in the Dockerfile. With buildpacks, Nodion reads .ruby-version or the ruby line in the Gemfile and offers 3.3, 3.4 (default) and 4.0.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Heroku Alternatives with EU Hosting: 5 Options Compared A German platform and US clouds with EU regions, compared by headquarters, regions and managed databases.
• Dockerfile vs Buildpacks: Which One Should You Use? Both turn your code into a container image. What differs is who writes the build steps, and that decides control, maintenance and security updates.

Ruby on Rails on Nodion: questions and answers