Entry-Point Runtime — Ruby

Heuristics the Stella Ops scanner uses to classify a container entry point as a Ruby application — Rack/Rails server, Bundler-wrapped command, or background worker — plus the evidence it attaches and the edge cases it guards against. For the shared detector contracts, scoring, and calibration, see the Runtime Detector Overview.

Signals to gather

• argv0 equals ruby, bundle, bundler, rackup, puma, unicorn, sidekiq, or resque.
• Bundler scripts: bundle exec <cmd>; Gemfile and Gemfile.lock.
• Rails and Rack hints: config.ru, bin/rails, bin/rake.
• Background jobs: sidekiq, delayed_job, resque.
• Environment variables (RAILS_ENV, RACK_ENV, BUNDLE_GEMFILE).

Implementation notes

• Normalise bundle exec by skipping the bundler wrapper and targeting the actual command.
• Resolve script paths relative to the working directory.
• For puma/unicorn, parse config files (config/puma.rb, config/unicorn.rb) to gather ports/workers.
• Recognise foreman start or overmind launching Procfile processes—may devolve to Supervisor classification.

Evidence & scoring

• Boost confidence when Gemfile.lock exists and the requested server script is found.
• Add evidence for env variables and config files.
• Penalise ambiguous CLI invocations or missing artefacts.

Edge cases

• Alpine and distroless images may rely on ruby symlinks; confirm binary presence.
• JRuby (running on the JVM) may trigger both Ruby and Java signals — prefer Ruby when a ruby/jruby interpreter is explicit.
• Supervisors launching multiple Ruby workers should produce a single Supervisor entry with Ruby children.

Related

• Runtime Detector Overview — shared contracts, scoring, calibration.
• Entry-Point Runtime — Java — disambiguating JRuby from JVM workloads.
• Supervisor detector — Procfile-driven (foreman, overmind) and multi-worker deployments.