Hi @leuan-edmonds_ecwell ,
I was checking some resources on this and found few which I think might help. Also taken some help from AI by feeding the earlier responses, hereâs what it gave:
Resource 1: The Official Stance on MainDomKeyDiscriminator and Slot Swaps
The most critical piece of evidence regarding why slots fight over resources and how to fix it is buried in the Global Settings Reference documentation, not the main Azure guide.
What the documentation says:
âDeployment slots for a given Azure App Service share the same machine name. Without additional configuration, they will share a MainDomKey and therefore compete for MainDom status. This can be undesirable if attempting to deploy to a deployment slot followed by a swap with the production slot as once traffic has switched to the new instance the old production instance reboots and can re-acquire MainDom status⌠To prevent this from occurring you can specify a MainDomKeyDiscriminator which should be set as a slot-specific configuration to prevent the slots from competing for MainDom status.â
Why this matters to the OP: This officially validates the memberâs suspicion. Because Azure slots share a machine name and share the underlying wwwroot file system, they are actively fighting for control. By implementing SqlMainDomLock and assigning a unique sticky MainDomKeyDiscriminator to each slot (e.g., Prod and Staging), Umbraco treats them as two completely isolated applications that happen to point to the same database, eliminating the conflict.
Resource 2: The SqlMainDomLock vs FileSystemMainDomLock Debate
The member received conflicting advice about which lock to use because the âbest practiceâ depends entirely on whether they are using slots.
What the documentation says: The main Azure guide recommends "MainDomLock" : "FileSystemMainDomLock".
The Technical Reality (The âWhyâ): FileSystemMainDomLock works perfectly on a single Azure App Service because it relies on placing a physical file lock in the directory. However, when you introduce Deployment Slots, both slots read from the same remote file share (wwwroot). If you use FileSystemMainDomLock with slots, both Staging and Production try to lock the exact same physical file.
This is why the fallback to SqlMainDomLock is required for slotted architectures. It moves the lock mechanism away from the shared file system and into the database, where the MainDomKeyDiscriminator can safely keep the two instances separated.
Resource 3: The Linux Temporary File System Reality
The member noted that setting "LocalTempStorageLocation": "EnvironmentTemp" was still generating files in ~/site/wwwroot/umbraco/Data/tmp, leading to read/write errors.
What the documentation says:
âIn an Azure Web App, we want these [temp files] to be created in the local storage of the actual server that Azure happens to be used for the Web App⌠This is required for both the performance of the website as well as to prevent file locks from occurring due to the nature of Azure Web Apps shared files system.â
The Technical Reality (Linux vs. Windows): On Azure Windows App Services, the EnvironmentTemp setting resolves cleanly to the %TEMP% directory, which is isolated per worker instance.
On Azure Linux App Services, the environment variables donât always map the same way, and Umbraco often falls back to creating a Data/tmp folder inside the shared wwwroot directory. Because the wwwroot is a network share attached to the Linux container (not local memory), it is notoriously slow and subject to locking contention between the slots.
To achieve the isolated local storage the documentation demands on a Linux container, the member must explicitly point Umbraco to the Linux root temp directory:
"Hosting": {
"LocalTempStorageLocation": "Custom",
"LocalTempStorageDefaultPath": "/tmp/umbraco-temp"
}
Hope it helps!
