Skip to main content

Ruby

A Ruby application serving its own HTTP through Puma — Rails, Sinatra, Hanami

A Ruby application serving its own HTTP through Puma — Rails, Sinatra, Hanami or any other Rack application. Like Node and Python it is the web server as well as the application, and it replaces PHP-FPM and Nginx rather than joining them. In front of it is the platform's proxy, which terminates TLS and routes the hostname.

The image is the official Ruby image on Debian, slim, with a compiler, the PostgreSQL, MySQL, SQLite, YAML and FFI headers, and libvips for Active Storage's image variants — so pg, mysql2, psych and the rest of a Rails bundle build. Choose the version with runtime.ruby in vallic.yaml:

version: 1
type: ruby

runtime:
  ruby: '4.0'

build:
  steps:
    - name: Gems
      run: bundle install
  cache:
    - vendor/bundle

port: 3000

The bundle travels in the release. Bundler installs into vendor/bundle in the checkout, held to Gemfile.lock, without the development and test groups, and the release is that checkout moved. Declare vendor/bundle under cache and the next build installs only what the lock changed; gems the lock no longer names are removed as it does. A lock written by another Bundler than the image's is honoured: that version is installed into the bundle and used.

Lock for Linux. A Gemfile.lock made on a Mac names the Mac's platform only, and an install held to the lock refuses to add another. Add it once:

bundle lock --add-platform x86_64-linux

With no start, the image runs bundle exec puma -p $PORT in the release, which reads config/puma.rb where there is one. Puma listens on PORT — 3000 unless port says otherwise — on every address. WEB_CONCURRENCY (worker processes, one by default), RAILS_MAX_THREADS and RAILS_LOG_LEVEL can be set on the service (see Service settings). RAILS_ENV and RACK_ENV are production, and Rails logs to the container's output, which is where the platform reads it.

The image's bundle, gem and rake come before the release's bin/ on PATH, so the bin/bundle older Rails applications generated is never the one run. The image's Ruby is the one used, whatever .ruby-version asks for: the version is runtime.ruby.

The release is read-only. storage/, log/ and tmp/ are linked out of it to directories that outlive every release (VALLIC_PUBLIC_DIR is storage/, VALLIC_PRIVATE_DIR is private/), so Active Storage's uploads, a file cache and SQLite's databases are kept. See Rails for the rest of a Rails application.

Versions

Version Status
4.0 Supported, and the default
3.4 Supported

Pin the version, not the build: name 4.0 and the platform matches it to the current build, so a security rebuild reaches you without anybody editing a repository.

What you can change

In vallic.yaml — what each one does is on Service settings:

services:
  - ruby:
      version: '4.0'
      environment:
        WEB_CONCURRENCY: …
        RAILS_MAX_THREADS: …
        RAILS_LOG_LEVEL: …

Anything not on this list refuses the deploy, naming the variable — rather than being accepted and quietly ignored.