Hosting Multiple ASP.NET Core Sites Behind Kestrel

Running several ASP.NET Core applications on one server can reduce infrastructure costs and simplify administration. Kestrel is fast, lightweight, and well suited to serving ASP.NET Core applications, but it is generally designed to sit behind a reverse proxy when hosting internet-facing websites. The proxy receives public traffic, selects the correct application, and forwards the request to the appropriate Kestrel process.

This arrangement works well for company websites, APIs, administration portals, and event platforms hosted on the same virtual machine. A setup serving conference.example.com, api.example.com, and members.example.com can use separate Kestrel listeners while presenting a clean HTTPS interface to visitors. For an Australian organisation, the server may sit in an Azure Australia East region in Sydney, Australia Southeast in Melbourne, or a local data centre connected through the NBN.

How The Hosting Model Works

Each ASP.NET Core site runs as an independent process. The process listens on a private port, such as 5001, 5002, or 5003, while a reverse proxy listens publicly on ports 80 and 443. Nginx, Apache, or Internet Information Services can perform this proxying, depending on whether the host is Linux or Windows.

A visitor does not need to know which internal port serves the application. The browser requests https://portal.example.com, and the reverse proxy examines the hostname. It then forwards the request to the Kestrel endpoint assigned to the portal. A different hostname, such as api.example.com, can be routed to a separate process without exposing its internal port to the internet.

This separation gives each application its own deployment cycle, configuration, logging location, and runtime settings. A conference registration site can be restarted without stopping an unrelated customer portal. It also makes it easier to apply different scaling, authentication, and maintenance policies to each service.

Kestrel can technically bind directly to multiple ports and serve different applications, but the reverse proxy remains valuable. It centralises TLS certificates, redirects HTTP to HTTPS, handles connection management, supports request filtering, and provides a consistent public entry point.

Assigning Hostnames And Ports

Start by giving each application a distinct DNS name. For example, DNS records might point conference.example.com, speakers.example.com, and api.example.com to the same public IP address. The reverse proxy uses the HTTP Host header and, for HTTPS, the requested server name indication to select the matching site configuration.

Each ASP.NET Core application should then receive a dedicated local binding. Configuration can be supplied through appsettings.json, environment variables, or a hosting command. A simple Kestrel configuration might bind an application to http://127.0.0.1:5001, keeping it reachable only from the local machine:

{
  "Kestrel": {
    "Endpoints": {
      "Http": {
        "Url": "http://127.0.0.1:5001"
      }
    }
  }
}

A second application can use port 5002, while a third uses 5003. Binding to the loopback address prevents direct external access, so users cannot bypass the reverse proxy by connecting to the Kestrel port. If the proxy runs on a separate host, use a private network address and restrict access with firewall rules.

Avoid assigning the same port to several processes. Kestrel cannot bind two independent applications to an identical IP address and port combination unless a specialised port-sharing arrangement is used. Clear port ownership makes incident response much simpler, particularly during an after-hours support call in Brisbane or Perth.

Configuring The Reverse Proxy

With Nginx, each hostname can have its own server block. The proxy should pass the original host, client address, protocol, and connection information to Kestrel. A basic configuration looks like this:

server {
    listen 443 ssl;
    server_name conference.example.com;

    ssl_certificate /etc/letsencrypt/live/conference.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/conference.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5001;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The second site uses the same pattern with a different server_name and upstream port. WebSockets and long-running requests may need additional proxy settings, especially for live notifications, dashboards, or event chat features. Timeouts should reflect the application’s behaviour rather than relying on a generic default.

ASP.NET Core must trust forwarded headers carefully. The application can enable UseForwardedHeaders so that redirects, generated links, secure-cookie decisions, and client IP logging use the original request details. Trust only the known proxy address or private network range. Accepting forwarded headers from arbitrary clients allows attackers to forge protocol and IP information.

When TLS terminates at the reverse proxy, configure HTTP-to-HTTPS redirection there or ensure ASP.NET Core understands that the original request used HTTPS. Without this, an application may repeatedly redirect requests or generate callback URLs with the wrong scheme. This is particularly important for OAuth sign-in and account platforms.

Deploying Independent Application Processes

On Linux, each website can run as a separate systemd service. A service definition identifies the application directory, runtime environment, listening URL, user account, and restart behaviour. Running each service under a restricted user prevents one compromised application from freely reading another site’s files.

A typical service command might set:

[Service]
WorkingDirectory=/var/www/conference
ExecStart=/usr/bin/dotnet /var/www/conference/Conference.dll
Environment=ASPNETCORE_URLS=http://127.0.0.1:5001
Restart=always

Repeat the pattern for the other sites with separate directories and ports. Use systemctl status, journalctl, and the reverse proxy’s access log to distinguish application failures from routing problems. A 502 response usually indicates that the proxy could not reach Kestrel, while a 500 response generally means the application received the request and failed while processing it.

On Windows Server, IIS with the ASP.NET Core Module is a common alternative. Each site can have its own IIS binding and application pool, while IIS forwards traffic to the corresponding Kestrel process. Separate application pools improve isolation and allow individual recycling policies. Windows administrators should also check URL bindings, certificate assignments, firewall rules, and service account permissions.

Shared resources require special care. If multiple instances of the same application use cookie authentication, share ASP.NET Core Data Protection keys through a protected directory or external store. Otherwise, a user authenticated by one process may appear logged out after a request reaches another process. Separate unrelated applications should generally use separate key rings.

Securing And Scaling The Arrangement

The reverse proxy is the public security boundary, so expose only ports 80 and 443. Block direct access to Kestrel ports through the host firewall and cloud security group. Keep administrative endpoints private, restrict management access through a VPN or approved IP ranges, and avoid placing diagnostic pages on public routes.

Use a certificate covering every public hostname, either through individual certificates or a suitable subject alternative name certificate. Automated renewal with Let’s Encrypt works well for many deployments, provided renewal testing is scheduled. Australian businesses handling personal information should also consider where logs, backups, identity data, and database services are stored under their privacy and contractual obligations.

For an audience in Sydney or Melbourne, an Azure deployment can place the reverse proxy and applications close to the primary user base while retaining a recovery strategy in another Australian region. Applications serving Western Australia may need capacity planning around network latency to eastern-region infrastructure. A local NBN connection can be sufficient for testing or a small internal service, but production workloads usually need reliable data-centre connectivity, monitoring, and an alternative path.

Scaling can begin vertically by allocating more CPU and memory, then move to multiple application servers behind a load balancer. Every server must use consistent routing, certificates, environment variables, and shared state services. Session state should live in a distributed cache or database when requests can reach different nodes. Uploaded files should use shared object storage rather than a single server’s local disk.

Monitoring Requests And Diagnosing Failures

Reliable multi-site hosting depends on observing every layer. Monitor DNS resolution, certificate expiry, reverse proxy health, Kestrel process state, application response time, CPU, memory, disk space, and database connectivity. A simple uptime check for each hostname will identify whether the public route works, but internal health checks provide more useful detail.

Use correlation IDs so a request can be followed from the proxy log into the ASP.NET Core log and, where necessary, the database trace. Record the hostname and upstream status code. This helps separate a DNS error from a proxy routing error, a stopped Kestrel process, and an application exception.

Common mistakes include forwarding to the wrong port, omitting the original Host header, forgetting forwarded-header middleware, and leaving a stale process running after deployment. Port conflicts often appear after manually starting a second copy of an application. Service managers and deployment scripts should stop or replace the intended process in a predictable manner.

A maintenance window should include configuration validation before reload. For Nginx, test the configuration before applying it; for IIS, verify bindings and application pool status. Schedule deployments around local usage patterns, such as business hours across AEST and AEDT, and account for daylight-saving differences between Sydney, Melbourne, and Queensland.

Operational Recommendations

A practical production arrangement benefits from a short, repeatable checklist:

• Give every application a unique DNS hostname and private Kestrel port.
• Bind Kestrel to loopback or a protected private interface, never an unrestricted public address.
• Configure the reverse proxy to preserve Host, client IP, and original HTTPS information.
• Run each site under a separate service account, systemd unit, or IIS application pool.
• Monitor public endpoints, upstream health, certificate renewal, logs, and resource consumption.

Document the hostname-to-port mapping in the deployment repository rather than relying on one administrator’s memory. Store secrets outside source control, apply operating system and .NET security updates, and test restoration of certificates, configuration, databases, and uploaded files.

A well-organised reverse proxy arrangement remains straightforward as the number of sites grows. New ASP.NET Core applications can be added by allocating a port, creating a process definition, adding a hostname route, installing the certificate, and registering monitoring. The public experience stays consistent while each Kestrel application remains independently manageable.