Replacing Sprockets with Propshaft in Rails 7

By USEO Engineering Team January 4, 2026

BLUF (Bottom Line Up Front): Sprockets is heavily over-engineered for the modern web where browsers natively support ES modules and CSS variables. By replacing Sprockets with Propshaft, you eliminate complex asset processing, significantly reduce CI/CD build times, and rely on a drastically simplified digest generation mechanism.

Sprockets 4 vs Propshaft (Rails 7 default)
Aspect	Sprockets	Propshaft
Role	Compile + fingerprint + serve	Fingerprint + serve only
SCSS/CoffeeScript	Built-in transpilation	Not supported - use dartsass-rails
Fingerprinting	MD5 content hash	SHA1 content hash
Manifest format	manifest-<hash>.json	.manifest.json
require directives	Yes: //= require	No - explicit imports only
Boot time	Slower (full pipeline)	Faster (static only)
When to use	Legacy apps with SCSS imports	New Rails 7 apps + CSS bundling

Phase 1: The Sprockets Overhead

Sprockets was built to concatenate, transpile, and minify assets. In modern Rails 7 stacks utilizing jsbundling-rails or cssbundling-rails, the actual compilation is handled by external tools like esbuild or Tailwind. Sprockets becomes an unnecessary middleware that slows down the load path resolution and consumes excessive memory.

Synthetic Engineering Context: The CI/CD Bottleneck

Below is a snippet from a GitHub Actions CI run on a legacy application using Sprockets alongside Webpack.

# CI Log Output (Sprockets)
Running `rake assets:precompile`...
I, [2026-04-23T10:00:00.123]  INFO -- : Writing /app/public/assets/application-9c8...
Sprockets::FileNotFound: couldn't find file 'legacy_plugin' with type 'application/javascript'
Time elapsed: 145.2 seconds

The build is slow because Sprockets attempts to parse and resolve directives (like //= require) inside files that have already been bundled by another tool.

Phase 2: The Propshaft Migration

Propshaft operates on a simple premise: it copies files from the load path to the public directory and appends a hash for caching. It does not transpile or concatenate.

Execution

Remove sprockets-rails from your Gemfile and add propshaft.
Delete app/assets/config/manifest.js. Propshaft does not use manifests; it serves everything in the build paths.

# Gemfile
# Remove: gem 'sprockets-rails'
gem 'propshaft'

Update your configuration to reflect the removed Sprockets dependency:

# config/application.rb
# Replace `require "rails/all"` with explicit framework requires if you had it
require "active_record/railtie"
require "action_controller/railtie"
require "action_view/railtie"
# require "sprockets/railtie" # REMOVE THIS LINE
require "rails/test_unit/railtie"

Post-Migration Results

Running the precompilation with Propshaft yields pure digest generation without the parsing overhead.

# CI Log Output (Propshaft)
Running `rake assets:precompile`...
Created public/assets/application-7b4...css
Created public/assets/application-3f1...js
Time elapsed: 12.4 seconds

Build time drops from 145 seconds to 12 seconds.

Phase 3: Next Steps & Risk Mitigation

Migrating to Propshaft is straightforward if your assets are already modern. However, if your application still relies heavily on Sprockets directives (//= require_tree .) or ERB in CSS/JS files, the migration will break your frontend.

Need Help Stabilizing Your Legacy App? Untangling years of Sprockets dependencies requires a surgical approach to asset management. Our team at USEO specializes in modernizing the Rails asset pipeline for maximum performance.