Inspect the Gemfile, JavaScript and CSS build configuration, and production static-file settings. Identify any runtime or credentials needed during compilation.

1. Install the locked Ruby and frontend dependencies required by the build. Avoid replacing the project’s asset stack as an unplanned hosting fix.

2. Run the project’s production asset preparation, commonly the appropriate assets:precompile task. Review failures and generated manifest files.

3. Deploy generated assets with the release that references them. Preserve fingerprinted files needed by already-open pages during the release transition.

4. Configure static delivery through the approved web server, proxy or Rails deployment setting. Keep private application directories outside public access.

5. Test styles, scripts, images and fonts through the public HTTPS hostname. Review caching for versioned files and avoid stale unversioned asset references.

Inspect actual asset responses and content types. Confirm the application does not depend on a development asset server or untracked local output.

A missing asset can indicate an incomplete build, wrong manifest or incorrect public path. Determine which asset pipeline is installed before applying a fix written for another Rails generation.

If the application opens but its stylesheet returns 404, inspect one failing asset before changing the complete build. Copy its URL from the browser's Network tab and compare the fingerprinted filename with the assets generated for the active release.

1. Confirm the deployment actually ran the project's production build. A successful Git checkout alone does not produce compiled JavaScript or CSS.
2. Find the generated manifest and output files for the asset system in this application. Compare them with the release currently served by the web process.
3. Check whether the response is a genuine missing file, an access denial or an HTML error page returned with an unexpected content type.
4. Deploy the corrected build as one release. Keep a rollback copy of the previous application and matching assets.

A manifest from the new release combined with files from the previous release can break pages even when both builds were valid individually. Avoid deleting all old fingerprinted assets during investigation because browsers may still have pages referring to them.

What evidence should I send to our team?

Include the public asset URL, HTTP status, active release identifier and the relevant build error. Exclude production secrets and full environment dumps. State whether the asset works locally and whether the local test used a development server or a production build.

• Preparing Rails encrypted credentials for production
• Building a deployment artifact in CI
• Separating development and production dependency groups
• Diagnosing Rails host authorization and HTTPS redirect loops

• Rails asset pipeline
• Rails configuration