The mode a store runs in decides how fast and safe it is
Magento can run in one of three deployment modes, and the wrong one costs performance on every request. It is one of the fastest checks in an audit and one of the most common things we find set incorrectly.
The mode also controls how static assets and compiled code are handled, which is where broken CSS and stale JavaScript after a deploy usually come from.
This article covers the three modes, why developer mode in production is so costly, and the deploy steps that keep static content healthy.
The three modes and what they do
Confirm the active mode with bin/magento deploy:mode:show before anything else. The answer should be production on any live store.
Production mode pre-generates static content, compiles dependency injection, hides errors from customers, and never generates code on the fly. Developer mode does the opposite: it compiles and symlinks assets on demand and shows full errors. Default mode is neither, and it is not meant for a live site either.
Each mode is a different trade between speed and visibility. Production trades away on-the-fly convenience for the fastest, safest runtime, which is exactly what a live store wants.
Developer mode in production is a common, costly mistake
We regularly find live stores running in developer mode. Sometimes a launch never fully switched over, sometimes someone flipped it to debug an issue and never flipped it back.
The cost is real. In developer mode Magento regenerates static files and compiles code on nearly every request, work that production mode does once at deploy time.
Static content deployment and why it matters
In production mode, the storefront serves CSS, JavaScript, and images from pub/static, generated ahead of time by bin/magento setup:static-content:deploy. That command builds the assets per theme and locale so the runtime never has to.
Compiled code lives in generated/, built by bin/magento setup:di:compile. Both of these are deploy-time steps, and skipping either leaves the store either slow or serving nothing.
Magento tracks the deployed version in pub/static/deployed_version.txt, which drives the version string appended to asset URLs. That string is what tells browsers to fetch fresh files instead of cached ones.
What broken static content looks like
When static deployment goes wrong, the symptoms are visual and immediate. The most common ones are easy to recognize:
- Unstyled pages, because the expected CSS files are missing from
pub/static. - Old JavaScript or CSS after a deploy, because static content was not regenerated and the version string did not change.
- 404s on asset URLs, because the theme or locale was never deployed.
All three trace back to the same root cause: static content that does not match the code currently running. The fix is regenerating it correctly, not patching individual files.
The deploy steps that keep it healthy
A healthy deploy follows a fixed order, and each step exists for a reason. Set production mode, compile code, deploy static content, then clear the relevant caches.
Running setup:static-content:deploy with the -f flag forces a clean regeneration when assets have gone stale. After it finishes, the version string in deployed_version.txt changes, and browsers pick up the new files instead of cached ones.
Skipping any of these steps is where post-deploy incidents come from. Doing them in the right order every time is what makes deploys boring, which is the goal.
Stale generated code is its own trap
The generated/ directory holds compiled interceptors and factories, and it must match the code currently deployed. When an old generated/ survives a deploy, the store can run compiled classes that no longer match their source.
The safe pattern is to clear generated/ and recompile as part of the deploy, rather than letting it accumulate across releases. The same applies to pub/static, where old asset versions should be cleared, not layered on top of new ones.
Symptoms of stale generated code are strange to chase: methods behaving like an older release, or fatals referencing classes that changed. When behavior does not match the code you deployed, a leftover generated/ is a prime suspect.
A five-minute check with real value
Deployment mode and static content health are quick to verify and expensive to get wrong. One command tells you the mode, and a look at pub/static and the version file tells you whether assets are current.
Knowing your store runs in production mode, with static content that matches the code, removes a whole class of quiet slowdowns and post-deploy breakage. It is one of the cheapest wins a platform review produces.