In this article, we will compare InProcess and OutOfProcess hosting models in ASP.NET Core and learn more about each hosting model.

Hosting refers to deploying an application into the server for external access. Understanding the hosting process is essential in implementing a reliable deployment setup.

To download the source code for this article, you can visit our GitHub repository.

Let’s dive into each one of the hosting models.

InProcess Hosting

Before ASP.NET Core 2.2, the only option to host the application was the OutOfProcess model. This model uses an external server proxying the request to an internal server that hosts the application. We will learn more about the OutOfProcess model in our next section.

The InProcess hosting model is available from ASP.NET Core 2.2 onwards. With this model, we host the application directly inside the IIS worker process(w3wp.exe). We can avoid using the reverse proxy server, as IIS manages the end-to-end application hosting process.

Don't like the ads? Take a second to support Code Maze on Patreon and get the ad free reading experience!
Become a patron at Patreon!

Also note that, during the development, we may use IIS Express for hosting applications locally. The worker process name of IIS Express is iisexpress.exe.

Pipeline of InProcess Hosting

Let’s now look at how InProcess hosting works:

In Process hosting

When an HTTP request hits the IIS, the ASP.NET Core Module receives the native HTTP request. The ASP.NET Core module is a native IIS module part of the IIS pipeline responsible for receiving native HTTP requests. Further, the IIS HTTP Server receives the native request and converts it into a managed request acceptable for the ASP.NET Core Middleware pipeline.

Afterward, the ASP.NET Core Middleware pipeline processes the request and passes it on as an HttpContext instance. Finally, the application code runs using the HttpContext instance.

In the response generation stage, the application code creates the response and passes it to the IIS. The IIS sends the response back to the client that sent the request.

Experimentation With Code

How about we experiment and find out which process runs our application code?

For this, let’s create a Web API project and modify the Program.cs file to add a middleware:

app.Run(async context => await context.Response.WriteAsync(Process.GetCurrentProcess().ProcessName));

Here, we create a terminal middleware delegate to the app’s request pipeline using the app.Run() method. We use the System.Diagnostics.Process class to retrieve the current process that runs our application and then write the process name to the HttpContext response stream using the WriteAsync() method of HttpResponse class.

If we select IIS or IISExpress and run the application, we will see that the output prints the corresponding process that executes the application. That is, either w3wp or iisexpress.

From ASP.NET Core 3.0 onwards, the in-process hosting model is the default. Although, we can explicitly specify the hosting model by modifying the project file and setting the AspNetCoreHostingModel property:


If we rerun the application after setting the hosting model explicitly, the output should still be the same.

OutOfProcess Hosting

Before ASP.NET Core 2.2, OutOfProcess was the only hosting model available. With OutOfProcess hosting, the application runs on a separate process from the one provided by IIS. The process that hosts the app is dotnet.exe.

In OutOfProcess hosting, we use two web servers: an internal and a reverse proxy server. The internal web server is the Kestrel server, and IIS is the reverse proxy server.

We can also implement OutOfProcess hosting without a reverse proxy server by configuring Kestrel. With this, the Kestrel server itself is the internet-facing server.

Let’s now look at these two implementations.

The Pipeline of OutOfProcess Hosting With a Reverse Proxy Server

First, we’ll look at how the OutOfProcess hosting pipeline works with a reverse proxy server:

OutOfProcess hosting with reverse proxy server

With this hosting model, we use IIS as a reverse proxy server. This is useful in case we need to take advantage of some of the unique features IIS supports but Kestrel doesn’t (Eg. Windows authentication).

Here, the IIS forwards the HTTP request to the Kestrel server, which transfers the request to the middleware pipeline. The middleware pipeline handles the request and passes it on as an HttpContext instance to the app’s logic.

The Pipeline of OutOfProcess Hosting Without a Reverse Proxy Server

We will now see how OutOfProcess hosting pipeline works without using a reverse proxy server:

OutOfProcess hosting with Kestrel

In this case, the Kestrel server acts as the main application server. This means that the Kestrel server is the internet-facing server that handles incoming requests directly.

Note that if we run the application via .NET core CLI, it ignores the AspNetCoreHostingModel set in the project file and uses the OutOfProcess hosting model by default.

Experimentation With Code

Let’s use the same project we created and update the project file to use the OutOfProcess hosting model:


The AspNetCoreHostingModel setting specifies the hosting model to use.

We then set the UseAppHost setting to false to disable the generation of a native executable. If we don’t do that, the build generates an executable file with the name of the project file, and the application runs within that executable. Using this setting, ensure the application uses the dotnet.exe process for hosting.

Once we run the application, we should see the output as dotnet.

InProcess Vs OutOfProcess Hosting

The InProcess hosting doesn’t use a reverse proxy server. This avoids the connection setup between IIS and Kestrel. That means the requests are not proxied over the loopback adapter, a network interface that returns outgoing network traffic to the same machine.

The advantage of the Kestrel server is its platform independence. Due to this, for hosting applications on multiple platforms, Kestrel comes in handy. In this case, we could prefer OutOfProcess hosting with Kestrel. Also, when we are hosting smaller APIs that either don’t have an IIS setup and don’t need IIS features like Windows authentication or FTP, we could opt for OutOfProcess hosting.

Also, with OutOfProcess hosting, using Kestrel alone may not provide all the required functionalities. This is because Kestrel is a lightweight server and doesn’t provide extensive options for configuration. This includes:

  • Windows Authentication does not exist on Kestrel as it’s cross-platform
  • Request Filtering is not available out of the box with Kestrel
  • Kestrel doesn’t support multiple apps on the same port

This is also one of the reasons why we opt for InProcess hosting.


In this article, we’ve learned about the InProcess and OutOfProcess hosting models available in ASP.NET Core. We also understood the processing pipeline of both models and understood the differences between them.

As we have discussed, although both InProcess and OutOfProcess hosting models have their use cases, the in-process hosting model provides better performance. This is why ASP.NET uses InProcess hosting by default.

Liked it? Take a second to support Code Maze on Patreon and get the ad free reading experience!
Become a patron at Patreon!