This article is also available in:

How do I deploy a Ruby on Rails or Sinatra application?

Hodifly deploys Ruby applications from GitHub or GitLab the same way it deploys Node, Python or PHP ones: you push, Hodifly installs the gems, builds and puts the release live.

⚠️ Note: a Ruby application runs permanently behind Passenger. It therefore requires SITE PRO web hosting or above, like Node and Python applications. Static sites and PHP applications work on every plan.

What is detected automatically

Hodifly recognises a Ruby application from the Gemfile and config.ru:

Ruby on Rails: recognised by bin/rails or config/application.rb.
Sinatra: recognised by the sinatra gem.
Any Rack application: a config.ru is enough.

A repository that only has a Gemfile and a _config.yml is treated as a Jekyll site, so as a static site, which is what you want for a blog.

The entry point: `config.ru`

Passenger starts your application from the config.ru file at the project root. That is a Rack convention: there is no "startup file" to fill in, unlike Node applications.

So your config.ru has to exist and end with a run:

require_relative "config/environment"
run Rails.application

What Hodifly does on every deploy

Bundler installs the gems into a space dedicated to your application. The development and test groups are skipped, and that choice is recorded so the running app starts with exactly the gems that were installed. Commit your Gemfile.lock.
SECRET_KEY_BASE is generated once and kept outside the deployed releases, so your sessions and signed cookies survive deploys. You can override it with a project environment variable.
Assets are precompiled (assets:precompile) for Rails.
Migrations run before the new release goes live. A failed migration leaves the previous release serving: the site does not break. Set HODIFLY_SKIP_MIGRATIONS=1 as an environment variable to turn that off.
Persistent data: storage/ (Active Storage uploads) and log/ lives outside the releases and is linked into each one, so it survives deploys and rollbacks. A SQLite database in db/ or storage/ is kept too.

⚠️ Note: a rollback restores the code, but not the database schema.

Environment variables

The project's variables are passed to the running application: Rails reads them from ENV as usual. There is no generated .env file (that is a PHP-mode feature). If your application expects one, add the dotenv-rails gem.

Ruby version

Choose it under Runtime in the project settings. It is pre-filled from your .ruby-version or from the ruby "3.3.0" line in your Gemfile.

As with Python, changing those files after the project is created is not enough: the gem space is created before the build. The deploy log warns you, and the fix is to change the Runtime in the project settings.

Deploying into a subfolder

Set config.relative_url_root in config/application.rb so Rails generates the right URLs. See How do I deploy my site in a subfolder?.

What is not available

WebSockets (Action Cable in persistent mode) and permanent background processes (Sidekiq, Solid Queue as a dedicated worker). For deferred work, use a cron job from cPanel > Cron Jobs.