ASP.NET Core 10: Easy support of local multi host

Introduction

If you’ve ever built a project locally that needed to respond on multiple hostnames, say an API, an admin panel, and a frontend, you know the pain. Editing your hosts file, generating custom certificates with mkcert, running Visual Studio as admin… it was doable, but annoying. ASP.NET Core 10 makes this significantly easier thanks to first-class support for the .localhost top-level domain.

What changed

The .localhost TLD is defined in RFC 2606 and RFC 6761 as reserved for local use. Modern browsers already resolve any *.localhost address to the loopback IP (127.0.0.1 / ::1), so api.localhost, admin.localhost, or anything.localhost all point back to your machine, no hosts file needed.

Starting with .NET 10 Preview 7, ASP.NET Core has been updated to properly support this:

• Kestrel now recognizes .localhost addresses as loopback, so binding to them just works.
• The HTTPS dev certificate (dotnet dev-certs) now includes *.dev.localhost as a Subject Alternative Name, meaning HTTPS works out of the box with these subdomains.

After installing the .NET 10 SDK, just run dotnet dev-certs https --trust to trust the updated certificate.

Setting it up

There are a few ways to configure your app to listen on multiple .localhost hosts. Let’s go through them.

Option 1: UseUrls in Program.cs

The most straightforward approach, just tell Kestrel where to listen:

Simple, but hardcoded. Fine for a quick local setup.

Option 2: Kestrel endpoints in appsettings.Development.json

A cleaner approach is to configure Kestrel endpoints through configuration, keeping your Program.cs untouched:

This is my preferred option, it separates the URL configuration from the code, and it only affects your development environment.

Option 3: Launch profiles in launchSettings.json

If you want different launch profiles per host (useful when debugging a specific part of your app), you can define them in launchSettings.json:

With this, Visual Studio (or dotnet run --launch-profile ApiApp) lets you pick which host to spin up.

The “So What”: Routing by Hostname

Configuring multiple URLs is the first step, but the real power of this feature is logical separation. Instead of creating multiple projects or complex middleware, you can route requests to different endpoints based on the hostname using the .RequireHost() metadata.

This allows you to run an API and an Admin Dashboard within the same process while keeping their logic entirely distinct:

Conclusion

Nothing revolutionary here, but it removes real friction. No more hosts file edits, no more certificate headaches, no more running your IDE as admin just to get subdomains working locally. If you’re building multi-tenant apps or microservices that need distinct hostnames during development, this is a welcome quality-of-life improvement in ASP.NET Core 10.