IIS vs Kestrel is a common question when hosting ASP.NET Core on Windows, and the honest answer is that the two servers are not rivals – they are layers. Kestrel is the cross-platform HTTP server built into ASP.NET Core; IIS is the full Windows web server that normally sits in front of Kestrel and hands requests to it. Understanding which layer does what tells you when to use one, the other, or both.<\/p>\n\n
In the in-process hosting model, IIS loads the app directly into the application pool worker and Kestrel still exists inside the process – it is how ASP.NET Core speaks HTTP. So on a typical Windows deployment you are using both, with IIS as the front door.<\/p>\n\n
Kestrel is fast: it consistently posts some of the highest raw throughput numbers among managed web servers, and on Windows the in-process IIS model adds almost no overhead because requests never leave the worker process. The out-of-process model (Kestrel as a separate process behind IIS via loopback) adds one extra hop and is measurably slower, which is why in-process is the default since ASP.NET Core 2.2. For static files, IIS serves them directly from the StaticFileModule without touching managed code; Kestrel uses the StaticFiles middleware. Both are fast; IIS wins marginally on static content because it can skip the managed pipeline entirely.<\/p>\n\n
Raw benchmark numbers depend heavily on workload, hardware, and TLS configuration, so treat any headline figure with suspicion. The practical rule: on Windows, an in-process IIS deployment performs comparably to standalone Kestrel for typical web apps, while giving you IIS features for free.<\/p>\n\n
When you publish an ASP.NET Core app to IIS with hostingModel set to inprocess, the AspNetCoreModuleV2 loads the application into the w3wp.exe worker process of its application pool. Requests arrive at HTTP.sys, pass through the IIS module pipeline (authentication, URL rewrite, compression, request filtering), and then execute inside the app pool worker – no second process, no loopback hop. Kestrel still exists inside that process; it is the HTTP server the framework uses. The relevant web.config line:<\/p>\n\n
<\/code><\/pre>\n\nOut-of-process hosting runs dotnet.exe as a separate process and IIS proxies to it over a loopback socket. It provides process isolation between IIS and the app – a crash in the app does not take down the worker – at the cost of one extra hop per request. Choose in-process for performance and simplicity; choose out-of-process only if you specifically want the app isolated from the worker process.<\/p>\n\n
Feature comparison<\/h2>\n\nCapability<\/th> Kestrel (standalone)<\/th> IIS (full)<\/th><\/tr><\/thead> TLS termination<\/td> Configured in app code (UseHttps)<\/td> Bindings + certificate management UI<\/td><\/tr> HTTP\/2 \/ HTTP\/3<\/td> HTTP\/2 yes; HTTP\/3 experimental<\/td> HTTP\/2 yes; HTTP\/3 on Windows Server 2022+<\/td><\/tr> Request filtering<\/td> Manual middleware<\/td> Request Filtering module (URL, verbs, sizes, extensions)<\/td><\/tr> URL rewriting<\/td> Middleware or reverse-proxy rules<\/td> URL Rewrite module<\/td><\/tr> Windows auth (Kerberos\/NTLM)<\/td> Not built-in<\/td> Native, integrated with AD<\/td><\/tr> Process isolation<\/td> OS-level only<\/td> Application pools with recycling and crash isolation<\/td><\/tr> Diagnostics<\/td> Logging middleware, dotnet tools<\/td> Failed Request Tracing, App Pool logs<\/td><\/tr> Management<\/td> None (config files)<\/td> IIS Manager + Web Deploy<\/td><\/tr> Multi-server load balancing<\/td> Manual \/ external LB<\/td> ARR extension for server farms<\/td><\/tr><\/tbody><\/table><\/figure>\n\nWhen to run Kestrel directly<\/h2>\n\n- Containers and multi-platform deployments where IIS is not available.<\/li>
- Small internal services or microservices that sit behind a gateway, reverse proxy, or load balancer.<\/li>
- Development environments where dotnet run is the fastest path.<\/li><\/ul>\n\n
Running Kestrel directly on Windows Server means giving up request filtering, Windows authentication, app pool isolation, and IIS diagnostics. It is rarely the right call for a public-facing site on Windows.<\/p>\n\n
When to put IIS in front<\/h2>\n\n- Any public web application on Windows Server where you want HTTPS binding management, Windows auth, or request filtering.<\/li>
- Multiple apps on one server that need isolation – application pools contain crashes and recycle independently.<\/li>
- Teams that rely on IIS Manager, Web Deploy, or Failed Request Tracing for operations.<\/li><\/ul>\n\n
Decision summary<\/h2>\n\n- Public site on a Windows VPS: IIS in front, in-process hosting model. You get Kestrel performance plus IIS management.<\/li>
- Container or multi-platform app: Kestrel, with an external proxy for TLS and routing.<\/li>
- Internal tool with one or two users: Kestrel as a Windows Service is fine, but IIS adds isolation and logging for almost no effort.<\/li>
- Need both worlds: run IIS with the ASP.NET Core Module – that is the standard reverse-proxy arrangement on Windows.<\/li><\/ul>\n\n
The IIS-versus-Kestrel debate is really about where you want your operational features: in the framework or in the server. On Windows hosting, IIS plus in-process Kestrel is the default that loses nothing and gains management, filtering, and authentication. If you are comparing hosts for your next deployment, compare Windows VPS plans on our table<\/a>, and check our main comparison<\/a> for Windows Server VPS providers that pre-install IIS and let you manage it directly.<\/p>\n\nWant to experiment with both servers on your own hardware? Contabo’s Windows VPS plans<\/a> offer generous RAM and core counts for the price, which makes side-by-side IIS and Kestrel testing painless.<\/p>","protected":false},"excerpt":{"rendered":"