Does .NET need an API gateway between YARP and Kong/APISIX?

Hey guys,

I’m looking for feedback on a different deployment and extensibility model for API gateways.

YARP is an excellent reverse-proxy toolkit, but teams still need to build the surrounding configuration lifecycle, validation, management, and operational tooling. Platforms like Kong and Apache APISIX provide that out of the box, but introduce a separate runtime and configuration system.

We’ve been building HPD Gateway, a YARP-based gateway that can run either:

1. Embedded directly inside an ASP.NET Core application.
2. As a standalone Native AOT executable/container.

The embedded runtime registration can be as small as:

using HPD.Gateway; var builder = WebApplication.CreateBuilder(args); builder.Services.AddHpdGateway(gateway => { gateway .EnableCoreDeclarations() .ProtectCredentialHeaders( "Authorization", "X-Api-Key") .AddAuthorizationPolicy( "AdminOnly", policy => policy.RequireRole("Admin")); }); var app = builder.Build(); app.MapHpdGateway(); await app.RunAsync(); 

EnableCoreDeclarations() enables the built-in request-timeout, request-transform, response-transform, and credential-disposition vocabulary. Capabilities such as authorization, CORS, rate limiting, resilience, caching, inspection, and service discovery are explicitly registered by the host.

It has not been released yet but today it supports typed routing and matching, YARP load balancing and affinity, authorization, CORS, rate limiting, transforms, resilience, output caching, bounded request inspection, protected-credential stripping, TLS/SNI handling, Microsoft configuration/DNS/DNS-SRV discovery, immutable configuration revisions, rollback, durable SQLite recovery, a secured Admin API, generated TypeScript client, Gateway Studio, operational diagnostics, and Native AOT deployment.

One deliberate difference from Kong and APISIX is the extensibility model.

HPD allows configuration to change dynamically at runtime, but only within capabilities explicitly installed by the host. Operators can change routes, upstreams, transforms, policy selections, resilience bindings, and service-discovery declarations without redeploying.

What they cannot do is load arbitrary plugins, middleware, scripts, or executable code through the management API.

Custom behavior is implemented as typed C# code and registered by the host as part of the application deployment. Adding a new capability therefore requires rebuilding and redeploying the host, while configuration using existing capabilities remains dynamically manageable.

The tradeoff is less runtime plugin flexibility in exchange for:

• Strongly typed extension boundaries
• Host-capability validation before activation
• Native AOT compatibility
• A smaller dynamic code-loading attack surface
• Reproducible behavior identities
• Rejection of configuration that references unavailable behavior

For people running gateways in production:

1. Would you consider embedding the gateway inside your ASP.NET Core application, or would you still strongly prefer a separate process/container?
2. How important is the ability to introduce entirely new gateway behavior without rebuilding or redeploying?
3. Does a host-registered capability model feel like a useful safety property or an unacceptable restriction?
4. What missing capability or architectural concern would prevent you from adopting this model?

Especially interested in criticism from people using YARP, Kong, APISIX, Envoy, Nginx, or managed cloud gateways.