What it is

Ocelot is a .NET API gateway built as a series of ASP.NET Core middlewares arranged in a specific order. It is aimed at teams running a microservices or service-oriented architecture on .NET that need a unified point of entry into their system, though the README notes it will work with anything that speaks HTTP(S) and runs on any platform that ASP.NET Core supports. The project lives in the .NET ecosystem, is written in C#, and is distributed under the MIT license.

The concrete problem it solves is request routing and pipeline control at the edge of a distributed system. Ocelot's custom middlewares manipulate the HttpRequest object into a state specified by its configuration until the request reaches a request builder middleware, where a HttpRequestMessage is created and used to call a downstream service. That request-making middleware is the last item in the Ocelot pipeline and does not call the next middleware. The downstream response is retrieved as control passes back up the pipeline, where a further piece of middleware maps the HttpResponseMessage onto the HttpResponse object returned to the client. This gives a single configured entry point instead of clients addressing each service directly.

Key capabilities

• Acts as an API gateway and reverse proxy for HTTP(S) traffic in front of downstream services.
• Composes an ASP.NET Core middleware pipeline in a defined order, with custom middlewares that transform the incoming HttpRequest according to configuration.
• Builds downstream calls through a request builder middleware that produces an HttpRequestMessage.
• Terminates the pipeline at the request-making middleware, which does not invoke the next middleware.
• Maps the downstream HttpResponseMessage back onto the client-facing HttpResponse.
• Targets net9.0 STS plus net8.0 and net10.0 LTS target framework monikers.
• Ships as the Ocelot NuGet package with documentation hosted on Read the Docs.

Who uses it and how

• .NET teams running microservices that need one unified entry point into the system rather than exposing every service.
• Service-oriented architectures where routing and request shaping are declared in configuration instead of hand-written per client.
• Deployments on any platform ASP.NET Core supports, since the gateway itself is an ASP.NET Core application.
• Non-.NET backends that speak HTTP(S), because the gateway only requires the downstream service to be reachable over HTTP or HTTPS.
• Teams that need to inspect or extend gateway behavior by inserting their own ASP.NET Core middleware into the Ocelot pipeline.

Getting started

Install the package and its dependencies with the .NET CLI using dotnet add package Ocelot; all versions are available on NuGet. Documentation sources live in the repository as reStructuredText files, with rendered HTML at the Read the Docs site.

When to use it — and when not to

Ocelot fits projects already committed to ASP.NET Core and .NET, where the gateway can be hosted as another ASP.NET Core application and configured through its middleware pipeline. It is a library rather than a hosted service, so a self-h

dotnet add package Ocelot