Rails Dependency Pruner explores whether a Rails 8 application can reduce boot-time memory by avoiding constants it does not appear to use. It combines Prism-based static analysis with optional runtime evidence, writes a reviewable profile and applies guards through a Rails engine.
Requirements and first run
The tool supports Ruby 3.2 or newer and Rails 8.x. Start by inspecting the application, generating a coverage manifest, and producing a reviewable plan:
bundle exec rails-dependency-pruner doctor --app . --json
bundle exec rails-dependency-pruner coverage template --app . --write config/pruner_coverage.yml
bundle exec rails-dependency-pruner plan --coverage config/pruner_coverage.yml --patch tmp/pruner-boot-plan.patch
bundle exec rails-dependency-pruner check --app . --profile config/rails_dependency_pruner_profile.json
Static analysis identifies candidate constants, optional runtime observations refine that list, and the generated profile remains available for review before it affects application boot. Measure baseline and pruned variants repeatedly; the plan and profile are review artifacts, not proof that a dependency is safe to remove.
Current benchmark evidence
One local Lobsters smoke run on arm64 Darwin, Ruby 4.0.5 and Rails 8.1.3 reduced request-process RSS from 233,072 KB to 129,920 KB: 100.7 MiB, or 44.3%. Warmed p95 increased from 4.2 ms to 23.9 ms because the profile deferred work. A separate small generic-blog target saved 21.5% and did not meet its 40% acceptance target.
Status and limitations
These results are case studies, not promises for another application. Static analysis can miss dynamic constant use and metaprogramming, while runtime evidence covers only the exercised workload. Review every proposed change, cover production routes and background work, compare latency as well as RSS, and retain a tested rollback path.