Ruby on Rails

Gigadrive Network detects Rails when your Gemfile.lock lists railties and a config/application.rb file exists. A project without a lockfile is detected from the rails gem in its Gemfile instead. Your config.ru becomes the Function that answers every path, and the application runs on Puma.

Defaults

The runtime comes from .ruby-version, .tool-versions, the ruby line in your Gemfile or the RUBY VERSION in Gemfile.lock, in that order. Runtimes lists how each Ruby version maps to a runtime.

The preset also writes RAILS_ENV=production, RACK_ENV=production, RAILS_LOG_TO_STDOUT=1, RAILS_SERVE_STATIC_FILES=1 and RAILS_MAX_THREADS=5. They reach your Function as defaults, and a variable you store under Environment variables with the same name replaces one. Logs written to standard output appear in your Function's logs.

tmp/, log/ and storage/ are left out of the deployed package, and tmp/cache, tmp/pids, tmp/sockets, tmp/storage, log and storage are created empty and writable. What a Function writes there stays with that copy of the Function and is gone when it stops.

The database

A new Rails application uses SQLite. When every database your application uses in production is SQLite, each copy of your Function starts with its own databases under storage/, prepared the way bin/rails db:prepare would prepare them, including the Solid Cache, Solid Queue and Solid Cable databases. The build prepares them once, so db/seeds.rb runs during the build, not each time a copy starts. A SQLite database that names no file, as in an application generated without Kamal, gets one under storage/. That data belongs to one copy and is gone when it stops, so it suits a first deployment, not real data.

For data you keep, set DATABASE_URL under Environment variables to a PostgreSQL or MySQL server. The pg, mysql2 and trilogy gems work without extra setup. A server database is never migrated for you: run bin/rails db:migrate against it yourself, before the deployment that needs the new schema.

How requests are served

Every request reaches Puma unchanged, so server-sent events (text/event-stream) reach the client as your application writes them and Action Cable WebSocket connections work. The Puma in your Gemfile.lock serves the application, with RAILS_MAX_THREADS threads. Your config/puma.rb is not read: Gigadrive Network chooses the port and starts and stops the process itself.

After the build, the preset publishes everything in public to the edge, including the compiled files in public/assets, so they are served without reaching your application.

The build

The build installs your gems with Bundler into vendor/bundle, leaving out the development and test groups. When your application uses Propshaft or Sprockets, it then runs bin/rails assets:precompile with RAILS_ENV=production and SECRET_KEY_BASE_DUMMY=1, so an initializer that needs the real secret does not stop the build. An API-only application skips that step. A build script in package.json, such as the one jsbundling-rails or cssbundling-rails adds, runs before it.

When your Gemfile pins an exact Ruby patch release, such as ruby "3.3.6", the build runs your application on the newest release of that Ruby version instead and logs that it did.

Changing the defaults

version: 4
functions:
  config.ru:
    runtime: ruby-34
    memory: 1024
    max_duration: 60

Declaring the Function replaces the preset's entrypoint, and any setting you omit falls back to the config file's own defaults of memory: 128 and max_duration: 30 instead of the preset's 512 MB. Set both explicitly.

Rails' own guides live at guides.rubyonrails.org.