Is kestrel for asp.net core application production ready?

Hemanth Bidare picture Hemanth Bidare · Apr 24, 2018 · Viewed 10k times · Source

I have an api used by my angular application developed in asp.net core 2.0 Its been deployed in IIS and configured to use kestrel.

I read Kestrel is not safe when exposing the application publicly and more. Is that true? Is kestrel still not ready for production use? or kestrel is for different purpose altogether like few blogs say for internal applications.

Answer

Zhaph - Ben Duguid picture Zhaph - Ben Duguid · Apr 24, 2018

Yes, Kestrel is production ready and is supported on all platforms and versions that .NET Core supports, but if your application is available on public networks Microsoft recommend that you use it with a reverse proxy:

Even if a reverse proxy server isn't required, using a reverse proxy server might be a good choice.

You can find out more about the options for hosting ASP.NET Core apps in the MSDN documentation, including on Windows with IIS, on Linux with Nginx and on Linux with Apache among others.

There are a number of reasons to use a reverse proxy including:

  1. Running multiple applications on the same IP and port
  2. Limiting your exposed surface area
  3. Additional layers of configuration and defence
  4. Simplified load balancing and SSL set-up (these can be terminated at the reverse proxy for example)
  5. Better support for static files, compression, etc.

Depending on your requirements, different aspects of the above may be more or less important for you.

For example, Kestrel is very lightweight web server that specialises in running ASP.NET Core apps, but to do that it doesn't have many of the features of the likes of IIS or Apache, which you may find that you want. For example, processing static file such as images, CSS or JS doesn't need to be handled by the ASP.NET Core engine - using IIS you can automatically compress these files and add caching headers to speed up subsequent page loads. Similarly redirects and routing can be handled by IIS before the request reaches the processor.

From a security point of view, again you can take advantage of features such as request filtering (i.e. verbs used, paths, etc.), IP filtering, authentication, etc. before the request reaches Kestrel and not have to handle those aspects in your code.

As a point of note, for ASP.NET Core 1.x, the documentation is even more specific:

If you expose your application to the Internet, you must use IIS, Nginx, or Apache as a reverse proxy server. A reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel after some preliminary handling.