When you spin up a new Umbraco development site, the console usually prints the root URL. That’s handy for frontend work, but it can slow you down when you’re focused on back-office features. The time spent navigating to the back office—typically by navigating to /umbraco—adds friction to your daily workflow. This article describes a simple, practical pattern to print the back office URL at startup, so you can jump straight into back-office development without extra clicks.

The essence of the solution is a small startup hook that reads the URLs you’ve configured, builds a complete list of candidate addresses (including app.Urls), and, when it finds a localhost URL, outputs the back-office link by appending /umbraco. The approach is deliberately lightweight: it doesn’t require changes to your routing or a separate utility, and it stays close to the standard ASP.NET Core configuration model.

In practice, the pattern unfolds in a few clear steps. First, a startup hook is registered so the code runs as soon as the host starts. This ensures the runtime context and the necessary services are available. Next, the code reads configuration keys, looking for both ASPNETCORE_URLS and the legacy urls key to cover common development setups. It then assembles a complete list of URLs by combining what’s in configuration with the runtime-provided app.Urls. With this list in hand, the code selects the first entry that indicates localhost and, if found, constructs the Umbraco back-office URL by adding /umbraco. The result is both logged and printed to the console, giving you an immediate, reliable link to the back office during development.

Behind the scenes, the approach is remarkably straightforward. The startup hook, registered via app.Lifetime.ApplicationStarted.Register, is what triggers the workflow. The configuration retrieval leverages the built-in DI system to access IConfiguration, reading both the standard ASP.NET Core URL settings and the older urls key to ensure compatibility with various project templates. By aggregating all potential URLs from configuration and runtime, the code minimizes the chance of missing the intended development port. The localhost check then drives the final step: if a localhost-based URL is present, a clean back-office URL is produced and surfaced through both the console and the logging system. This small enhancement eliminates wasted time spent hunting for the back office and keeps your focus on building features rather than navigating the environment.

A practical snippet illustrates the core idea. In your program.cs, you can wire up the startup hook to read configuration, assemble candidate URLs, locate a localhost entry, and print the back-office URL. The essence of the pattern is compact, easy to adapt, and safe to drop into most development setups without disturbing production behavior.

Beyond the immediate utility, there are several ways to extend this pattern. You could automatically open the back office in your default browser on startup, which further reduces context switching. You could gate the output behind an environment check so it only appears in development, avoiding clutter in other environments. If you work with multiple development environments (development, staging, production), you could tailor the logic to select environment-specific back-office URLs. A small feature flag to enable or disable this behavior would also make it easy to toggle without code changes. Additionally, you might build a tiny developer dashboard that lists handy links (Back Office, API endpoints, and common dashboards) for quick access during development.

In short, a tiny startup helper that prints the back-office URL can shave precious seconds from your daily development workflow. It’s a lightweight pattern you can adapt and expand as your back-office work evolves, helping you stay focused on building features rather than chasing URLs.