Build Rails web apps and Ruby back-ends on the leading PaaS

Heroku manages Ruby dependencies using Bundler, the standard package manager for the Ruby ecosystem. When you deploy a Ruby application, the Heroku buildpack detects your Gemfile and Gemfile.lock files. It then runs the bundle install command, which uses your Gemfile.lock to install the exact versions of every gem your project needs, ensuring that the production environment on Heroku is a perfect match for your local development environment.

The fastest way to get started is by following the official Getting Started on Heroku with Ruby guide in the Heroku Dev Center. This tutorial provides a sample application and walks you through the steps of cloning the repository, provisioning a Heroku app, and deploying your code with a simple git push heroku main command.

Once you’re done with that, we recommend you learn how to build a Rails 8 app from scratch and deploy it to Heroku.

Heroku’s Ruby support aligns with the official Ruby Core support policy, providing support for all modern, stable versions (including Ruby 3.3 and 3.4). You can specify the exact Ruby version your application requires in your Gemfile.

Heroku highly recommends specifying a Ruby version and not relying on the default, as the default can change over time. For best performance and security, it is recommended to run the latest patch release of a supported Ruby version and to upgrade before a version reaches its official End-of-Life (EOL). For a complete list of currently supported and unsupported Ruby versions, please see the official documentation in the Heroku Dev Center.

The most popular framework on Heroku, and in the broader Ruby ecosystem, is Ruby on Rails. For developers building smaller applications or APIs, lightweight microframeworks like Sinatra and Hanami are also an excellent and popular choice. Because Heroku’s support for Ruby is deep and long-standing, the platform can accommodate almost any Ruby-based web framework.

Heroku is designed to work seamlessly with the Rails Asset Pipeline. Assets can be compiled locally or automatically during deployment (the default and also Heroku’s recommended approach). When you deploy a Rails application, the buildpack runs the rake assets:precompile task to compile and compress your assets (like CSS and JavaScript) for production.

For the best user experience, Heroku recommends pairing the asset pipeline with a Content Delivery Network (CDN). This speeds up asset delivery to your users and reduces the load on your Heroku app.

Note: If you want to skip asset compilation on Heroku, you can precompile locally and check in a .manifest.json or similar manifest file is detected in your app, Heroku will assume you are handling asset compilation yourself and will not attempt to compile your assets.

Yes. This is a common and powerful feature of the Heroku platform, handled by the Heroku CLI. Using the heroku run command, you can start a new instance of your application’s environment (called a one-off dyno) to execute commands. For example, you can open an interactive Rails console with heroku run rails console or run a database migration with heroku run rails db:migrate. This is extremely useful for debugging, running administrative tasks, and managing your database schema.

You can also get a plain interactive shell by running heroku run bash that will allow you to inspect the contents of your application using common terminal commands such as cat and ls -la.

For modern Ruby applications, especially those built with Ruby on Rails, the recommended and most commonly used web server on Heroku is Puma. Puma is a fast and highly concurrent web server that is the default for Rails. It is well-suited for Heroku’s dyno architecture, allowing your application to efficiently handle multiple requests at once. Your application’s Procfile will typically define a web process to start the Puma server.

You can run background jobs with tools like Sidekiq or Resque by declaring a new process type in your Procfile. While a web process handles HTTP requests, you can define a worker process to handle your background jobs. The Procfile entry would contain the command to start the Sidekiq process.

Background job systems like Sidekiq require a queuing backend, and the standard choice on Heroku is Heroku Key-Value Store, which can be attached as an add-on. Once you’ve defined your worker process and configured your Key-Value Store add-on, you can then scale your worker dynos independently from your web dynos to process your jobs with the heroku ps:scale worker=<count>:<dyno-type> command

No. Heroku applications use an ephemeral disk that does not persist between application restarts and SQLite relies on local disk writes to persist data. Instead, Heroku recommends using PostgreSQL. Read more about the differences between PostgreSQL and SQLite.

While not directly supported, it is possible (though not recommended for a production-grade system) to use a streaming replication system for sqlite that would allow you to back up the database to a data store such as S3 between restarts. You will also need to use a buildpack such as the Aptfile buildpack to install sqlite and libsqlite3-dev packages, which are required to build a native library that binds with sqlite. This will limit your ability to scale horizontally, and downloading a database copy on application boot will degrade your performance over time.