Inspect the repository for its asset configuration and build scripts. Identify the final public directory and whether the site is served at the domain root or below a path prefix.

1. Run the asset build or compilation command documented by the application. Use its lock files and supported build runtime rather than installing arbitrary latest frontend packages on the server.

2. Include the generated public files and any asset manifest in the same release as the code that references them. Keep dependency source directories outside the document root.

3. Configure the web server to serve existing public assets directly and send application routes to the front controller. Check any URL prefix or CDN configuration.

4. Use versioned asset names or the project-supported cache-busting mechanism. Keep old assets long enough for already-open pages when a deployment changes filenames.

5. Publish the release and inspect the browser network panel for CSS, JavaScript, font and image responses.

Confirm assets return their proper content and MIME types rather than an HTML error page. Open a fresh page and test an already-open page across a controlled deployment.

If pages are unstyled, compare generated filenames with the active manifest and document root. A 200 response containing the application HTML is still a failed asset request.

• Deploying Symfony in the production environment
• Building a deployment artifact in CI
• Making client-side routes work after a browser refresh
• Changing a Symfony database schema safely

• Symfony AssetMapper
• Symfony deployment