Rails 2.x Application Behavior on Heroku
Last updated September 17, 2024
This article is a work in progress, or documents a feature that is not yet released to all users. This article is unlisted. Only those with the link can access it.
Table of Contents
This article describes the behavior of Heroku apps using Rails 2.X or higher. For other versions, see:
Rails 2.X applications behave like Ruby applications with the following additions.
Auto-Detection
Heroku detects that an app is a Rails 2.x app when:
Gemfile.lock contains a rails gem
the rails gem version is 2.0.0 or later, and earlier than 3.0.0.
When Heroku recognizes a deployed app as a Rails application, we respond with -----> Ruby/Rails app detected at deploy time.
$ git push heroku main
-----> Ruby/Rails app detected
Config Vars
We set the following environment variables, in addition to the ones we set for Ruby Application Behavior on all Ruby apps.
RAILS_ENV=> “production”RACK_ENV=> “production”
Add-ons
Adds the same add-ons as a pure Ruby app.
Process Types
If you don’t include a Procfile, Rails 2 apps define a web process type at deploy time:
web: bundle exec ruby script/server -p $PORT
On Heroku, we recommend Puma as the web server. Regardless of the web server you choose, always specify it explicitly in the Procfile on production apps.
As a special case to assist in migration from Bamboo, Ruby apps that bundle the thin gem get this web process type:
web: bundle exec thin start -e $RAILS_ENV -p $PORT
Additional process types are declared for Rails 2:
console: bundle exec script/console
And if the app has a jobs:work rake task:
worker: bundle exec rake jobs:work
Plugin Injection in Rails 2
We inject the the rails_stdout_logging gem as a plugin to ensure that your logs get sent to standard out.
Heroku treats logs as streams of events, rather than files. By piping logs to stdout, your logs get captured and consolidated across multiple dynos by Logplex, which makes them available from the command line, $ heroku logs --tail, or from logging add-ons.