// the find
ThreeMammals/Ocelot
.NET API Gateway
Ocelot is a .NET API gateway built as an ASP.NET Core middleware pipeline, targeting .NET 8, 9, and 10. It handles routing, auth, rate limiting, load balancing, and service discovery (Consul, Kubernetes, Eureka, Service Fabric) through a JSON configuration file. The audience is .NET teams running microservices who want a gateway they can deploy as a regular ASP.NET Core app rather than a separate infrastructure component.
The acceptance test suite is genuinely good — it spins up real ASP.NET Core pipelines with actual HTTP traffic instead of mocking the middleware chain, which catches the ordering bugs that unit tests miss. Multi-targeting .NET 8/9/10 is handled correctly, so LTS-pinned teams don't get left behind when a release drops. Delegating handlers are the right extensibility seam: you plug into HttpClient's pipeline rather than hacking routing config. The project is actively maintained — last commit two days ago — and has been around long enough that most of the sharp edges are documented.
YARP is now the Microsoft-backed alternative, and it benchmarks meaningfully faster because it avoids Ocelot's middleware-per-request allocation pattern; if throughput matters, that's the honest comparison to make first. Configuration is JSON-only and flat — a gateway with 50 routes produces a dense ocelot.json that's painful to diff and impossible to generate from code without wrapping the file format yourself. Rate limiting is in-memory only; there's no built-in Redis-backed distributed rate limiter, so in a multi-instance deployment you're either building it yourself via delegating handlers or accepting per-instance limits that don't add up. Response aggregation (the Multiplexer) fans out and concatenates responses into a JSON array but can't reshape or transform the merged payload without writing a custom aggregator class.