Ruby is officially supported by Scalingo. Furthermore, custom support is added for the Rails framework in all its versions.
The buildpack is based on Bundler and will install the dependencies defined in
Gemfile.lock of your project (source of the
Presence of a
Rack Based Application
Presence of a
When a Rack application is detected, the following environment variable will automatically be set by the platform:
Rails Application Detection
Scalingo automatically detects the use of Rails, whatever the version used. All Rails versions are supported.
Starting with Rails 5.1,
yarn will be automatically installed if the gem
webpacker is installed.
When a Rails application is detected, the following environment variables will automatically be set by the platform:
Our deployment system is automatically using the latest available bundler version.
- Bundler 1: 1.17.3
- Bundler 2: 2.3.10
If your application fails to boot with the following error logs:
Activating bundler (2.0.1) failed: Could not find 'bundler' (2.0.1) required by your /app/Gemfile.lock.
It means you need to update bundler in your project:
$ gem update bundler $ bundle update --bundler $ git add Gemfile.lock $ git commit -m "Update bundler to new version" $ git push scalingo master
Specifying a Custom Ruby Runtime
If your need to install a custom version of Ruby, you can achieve that by specifying it in your Gemfile:
Ruby MRI 2.7.4
List of the Compatible Runtimes
Only last patch version of each major release is listed here, but other minor version are also present if your require them for specific tests.
Older versions, see https://www.ruby-lang.org/en/downloads/branches/
Ruby Application Web Server
Ruby contains a default application web server named
WEBrick. As it is always
present, most web framework use it by default. It’s good enough in development,
but it has never been thought to be a production server.
Do not use WEBrick
WEBrick has the following characteristics:
- Single threaded
- Single process
It can’t handle several request in parallel, they are all in a single request queue. As a result, very poor performance can be expected. To get the best of your containers, you need to use a real production-ready application server.
Using Puma as a Production Server
To handle several requests in parallel, we recommend puma.
To use it, add it as dependency in your
And configure how to launch your app by defining a
web: bundle exec puma -C config/puma.rb
The configuration file looks like the following:
workers Integer(ENV['WEB_CONCURRENCY'] || 2) threads_count = Integer(ENV['MAX_THREADS'] || 5) threads threads_count, threads_count preload_app! rackup DefaultRackup port ENV['PORT'] || 3000 environment ENV['RACK_ENV'] || 'development' on_worker_boot do # Worker specific setup for Rails 4.1+ ActiveRecord::Base.establish_connection end
Thus you can change the global settings by modifying the environment
MAX_THREAD and restarting your app.