After reading the 24 days article https://24days.in/umbraco-cms/2023/runtime-modes/, I decided to go through our client environments and implement the runtime modes, which necessitates setting the `UmbracoApplicationUrl `app setting. But I have a question, if I have a load balanced setup (1 backoffice edit app which is locked behind Azure AD, and 2 public frontend apps which sit under Azure Application Gateway), what URL do I set `UmbracoApplicationUrl `to? Would it be the public domain, or the domain of the backoffice edit app? (Note: /Umbraco is redirected to a 404 on the public domain)

The URL should be so Umbraco can "reach itself", so in this case, the backoffice URL for the backoffice app, and the frontend URL for the frontend apps. This is how we do it, but we currently don't have any multi-instance frontend apps. I'm not sure any functionality is broken if the reach-itself URL for the frontend apps is actually balanced between two instances. I can't see why Umbraco would need to differentiate between different frontend instances. They just all need to subscribe to the publishing app.

Perfect thank you! 🙂

I thought I'd seen a discussion where by for umb 9+ this is no longer the case, and it should be the scheduling publisher public url.. @Sebastiaan if memory serves I think you provided the HQ definitive answer after a lengthy discord discussion (but on the defunct discord channel so can't point to that). Docs do now say (https://docs.umbraco.com/umbraco-cms/fundamentals/setup/server-setup/load-balancing#automatic-server-role-election)

The address used by the "Scheduling server" is called the "umbracoApplicationUrl".

But (https://docs.umbraco.com/umbraco-cms/reference/configuration/webroutingsettings#umbraco-application-url) confuses this by saying it's the url to reach itself (note also clarifies no need for {url}/umbraco/ like in v8) If you set the subscribers to have umbracoApplicationUrls that are there own unique urls, then I think you'll find that the tokenised return links in things like forgotten pwd for members/users would use that umbracoApplicationUrl and route to your non public unique subscriber urls. Plus if you are using autoscale for a subscriber instance on azure then you don't have unique urls to hit each instance? And if these unqiue serverurls leak through to the frontend then you have SEO duplication of content issues?

I ended up setting

UmbracoApplicationUrl

to the azure web app url for the private backoffice editing app (this web app is locked behind AD), and the public frontend subscriber instances I set to the public facing url (e.g. mydomain.com). It seems to work, I haven't noticed any issues with links on the site or in member emails. (so far atleast).