> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.hodi.host/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# 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?](https://help.hodi.host/en/article/how-do-i-deploy-my-site-in-a-subfolder-18c8ag/).

## 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**.

## See also

* [What can I deploy on Hodifly?](https://help.hodi.host/en/article/what-can-i-deploy-on-hodifly-czlbyz/)
* [Can I roll back after a bad deployment with Hodifly?](https://help.hodi.host/en/article/can-i-roll-back-after-a-bad-deployment-with-hodifly-1w3uadl/)