Type: Troubleshooting
Category: Umbraco CMS > Configuration & Runtime
Tags: runtime mode, Production mode, backoffice not loading, backoffice blank, backoffice white screen, 404 CSS JS, static web assets, UseStaticWebAssets, Umbraco.Cms.StaticAssets, localhost, dotnet run, dotnet publish, Program.cs, Release build

Product: Umbraco CMS
Version: v13 and later

If you switch Umbraco:CMS:Runtime:Mode to Production and your front end still renders correctly but the back office comes up blank with a few files failing to load, this article explains why and how to fix it. The cause is not Razor view compilation, and it is not Models Builder.

Symptoms

The runtime mode is set to Production and the application starts without a BootFailedException.
Front-end pages render normally.
/umbraco loads a blank or unstyled page, or never finishes loading.
The browser console (F12 > Console, or the Network tab) shows a small number of 404 errors for back office CSS and JavaScript files.
App_Data/Logs/UmbracoTraceLog.txt contains nothing relevant. The requests never reach a point that logs an error.
Setting the runtime mode back to Development or BackofficeDevelopment makes the back office work again.

The direction of the failure is the clue. Back office broken while the front end works points at this article. The reverse, front end returning 404 while the back office is fine, is a different problem: see Resolving 404 Errors and BootFailedException During Umbraco v17 Upgrades.

Cause

Production runtime mode disables ASP.NET Core static web assets, following Microsoft's guidance for non-Development environments.

The back office user interface is not part of your own wwwroot. It is shipped inside an Umbraco NuGet package, and when you run the application from build output those files are located through the static web assets manifest rather than from a folder on disk. Turn the manifest off and there is nowhere for those requests to resolve to, so they return 404 and the back office cannot render.

Your front end is unaffected because it serves your own files from your own wwwroot, and your views are already compiled into the build.

This is why the problem appears when testing locally but not on a properly deployed environment. Publishing copies those assets into wwwroot as real files, so nothing needs the manifest. Umbraco Cloud environments run from published output, which is why Production mode works there without any of this.

Solution

If you are testing Production mode locally, or otherwise running from source

Add the following line to Program.cs:

builder.WebHost.UseStaticWebAssets();

Then rebuild and run. The back office should load normally with the runtime mode left at Production.

Placement matters. The line has to come before builder.Build() is called. Host configuration is read while the host is being built, so adding it afterwards has no effect and the back office will keep failing in exactly the same way.

For a real deployment

Do not add that line. Run from published output instead:

dotnet publish --configuration Release

Publishing writes the back office assets into wwwroot as real files, so they resolve without the manifest and no code change is needed. This is the arrangement Production mode is designed for.

What this is not

These are worth ruling out, because they are the usual suspects for 404s under Production mode and they send you in the wrong direction for this particular symptom.

Razor view compilation. Production mode does disable runtime compilation of .cshtml views, and leaving <RazorCompileOnBuild> or <RazorCompileOnPublish> in your project file does cause 404s. But that affects templates, which means front-end pages. It does not explain a broken back office while the front end works.
Models Builder. ModelsMode must be Nothing in Production mode, but getting this wrong prevents the application from starting at all rather than breaking only the back office.
Rewrite rules. Worth checking that ^/umbraco is excluded from any rewrites you have, but if the back office page itself is served and only a few asset requests 404, rewrites are not the cause.

Prevention

Test Production mode from published output where you can, rather than from dotnet run. It is closer to what your live environment actually does.
If you keep UseStaticWebAssets() in Program.cs for local testing, be aware it is a local-development convenience. It is not intended for an environment hosting from published output.
Check the other Production mode prerequisites before switching, since a missing one throws a BootFailedException at startup: Release build, Umbraco:CMS:WebRouting:UmbracoApplicationUrl set to a valid URL, Umbraco:CMS:Global:UseHttps enabled, and Umbraco:CMS:ModelsBuilder:ModelsMode set to Nothing. On v13 a fixed Umbraco:CMS:RuntimeMinification:CacheBuster (Version or AppDomain) is also required; that setting was removed in v14 and the requirement no longer applies from v14 onwards.
Change one thing at a time when moving an environment to Production mode, so a failure points at a single cause.

Still having issues?

Contact Umbraco support with your CMS version, the exact runtime mode and build configuration you are using, whether you are running from build output or published output, and the exact URLs of the files returning 404 from the browser console. If you are already in a support conversation, ask to talk to a human agent.

Back office does not load when running Production runtime mode locally (404 errors on CSS and JS)