Open Source API Management
An API gateway sits in the path of every request you serve, holding your auth and rate limits, which makes it the one component that can take all your services down at once - and the one you least want to treat as a black box. Around that gateway sits the wider job of API management: publishing APIs, issuing credentials to consumers, enforcing quotas, and running a developer portal. Open source lets you read exactly how routing, authentication, and policy execution behave instead of trusting a vendor's description, run the whole layer on your own infrastructure, and avoid a pricing model that meters the very traffic your business depends on.

Strapi
Model content visually and Strapi generates REST and GraphQL APIs with a self-hosted admin

Kong
Cloud-native API, LLM, and MCP gateway with plugin-based traffic control

Ory Hydra
OpenID Certified OAuth 2.0 and OpenID Connect server for SSO, API access, and machine-to-machine authorization

Windmill
Code-first platform for turning scripts into internal APIs, jobs, workflows, webhooks, and UIs

Apache APISIX
Dynamic, real-time API gateway with AI proxying, load balancing, and traffic control

Ory Kratos
API-first identity and user management for login, registration, recovery, verification, and profile flows

Unleash
Open-source feature management platform for targeted rollouts, feature flags, and self-hosted control

Tyk
Open source API gateway for REST, GraphQL, TCP, and gRPC with rate limiting, auth, and analytics

KeystoneJS
Define a content schema in code and get a GraphQL API plus an admin UI for Node.js
Our picks
Pick by the layer you need: a raw gateway, a full management platform, or the identity server behind them.
Best general-purpose gateway: Kong Kong is a mature, cloud-native gateway that centralizes proxying, routing, load balancing, health checking, and authentication, with a plugin system for everything else. It runs natively on Kubernetes through an official ingress controller and now extends to LLM and MCP traffic. It is the safe default for a fast, extensible proxy in front of services.
Best for mixed protocols: Apache APISIX Apache APISIX applies plugin and config changes through hot updates without restarts, so routes change with no downtime. It proxies TCP, UDP, gRPC, MQTT, WebSocket, and HTTP/3 alongside HTTP, and runs as a stateless data plane storing config in etcd. Governed by the Apache Software Foundation, it suits traffic that is not only REST.
Best full management platform: Gravitee API Management Gravitee covers the governance layer, not just the proxy: register APIs, shape them with over 50 pre-built policies, and front the catalog with a themeable developer portal and analytics. Its community edition is Apache-2.0 and self-hostable with Docker. Choose it when you need consumers, plans, and a portal rather than a bare gateway.
Best OAuth and OpenID server: Ory Hydra Ory Hydra is an OpenID Certified OAuth 2.0 and OpenID Connect server that handles token issuance, validation, client management, and consent. It deliberately leaves user management to a separate system, connecting to your identity provider through a login and consent app. Pair it with a gateway to keep authorization standards-based and auditable.
Know which layer of the API stack you are buying
The first thing to settle is whether you need a gateway or a full management platform, because the word management hides two different products. A gateway like Kong, Apache APISIX, or Tyk is the runtime that accepts traffic, applies policy, and routes requests - the tool for proxying, rate limiting, and auth in front of services. A platform like WSO2 API Manager, Gravitee, or Apiman adds the governance layer: publishing APIs, onboarding consumers, issuing keys, and a developer portal. If one team just needs a smart reverse proxy, a full platform is overhead you will feel.
Architecture drives the failure modes, so look at how the control plane and data plane are split. Some gateways bundle routing, policy, and storage into one deployable; others separate a light data plane from an admin plane and database, which changes what happens when the control plane is down. Several tools here are Kubernetes-native: Kgateway and Envoy Gateway implement the Gateway API, while APISIX and Kong ship ingress controllers. If you already run Kubernetes, that route removes a lot of glue, but check whether config changes need reloads.
The policy and identity model is where the daily work lives. Rate limits, quotas, JWT and OAuth checks, mTLS, and request transforms interact once several teams share a gateway, so look for explicit policy ordering, reusable bundles, and admin RBAC with audit logs. Authentication is often better handled by a dedicated server: Ory Hydra issues OAuth 2.0 and OpenID Connect tokens, and Ory Kratos runs the login flows behind them. Whatever you choose, test the export path for routes, consumers, and policies, since runtime counters rarely move cleanly.
Related categories
Frequently asked questions
What is the difference between an API gateway and API management?+
A gateway is the runtime that accepts traffic, applies policy, and routes requests - Kong, Tyk, and Apache APISIX are gateways. API management is the wider system around it: publishing APIs, onboarding consumers, issuing credentials, enforcing quotas, and often a developer portal, which is what WSO2 API Manager, Gravitee, and Apiman provide. The distinction matters when you need governance across many teams rather than a single reverse proxy.
Do I need a separate tool for OAuth and identity?+
Often, yes. Most gateways validate tokens but do not issue them or manage users. Ory Hydra is an OpenID Certified OAuth 2.0 and OpenID Connect server that handles token issuance, client management, and consent, while Ory Kratos runs login, registration, and recovery flows. Pairing a dedicated identity server with your gateway keeps auth logic in one auditable place instead of scattered across route config.
Why are so many of these tools built for Kubernetes?+
API traffic and Kubernetes ingress overlap heavily, so several projects target it directly. Kgateway and Envoy Gateway implement the Kubernetes Gateway API and provision Envoy for you, and both Kong and Apache APISIX ship official ingress controllers. If your services already run on Kubernetes, a gateway that speaks the Gateway API removes custom glue. If you run bare metal or VMs, confirm the tool has a first-class non-Kubernetes install.
Does every gateway handle GraphQL, gRPC, and WebSockets, or just REST?+
No, and this is worth testing early. Many gateways are strongest with HTTP and REST, then vary on everything else. Tyk lists REST, GraphQL, TCP, and gRPC support, and Apache APISIX proxies gRPC, MQTT, WebSocket, and HTTP/3 as well as HTTP. A simple pass-through may route these fine, but field-level GraphQL limits or gRPC metadata policy need a gateway that inspects the protocol, not just forwards it.
Which features tend to be reserved for paid editions?+
Several projects here follow an open-core model, so read what the license actually covers. Gravitee and Tyk are open core with commercial add-ons, WSO2 sells a supported subscription, and Kong offers hosted Konnect alongside the open gateway. Analytics, enterprise identity integration, and management dashboards are common split points. Before committing, confirm the specific capabilities you need are in the open-source build rather than a paid tier.
How do I model teams and permissions on a shared gateway?+
Model access around API ownership and operational risk. A service team may edit routes and docs for its own APIs, while platform engineers control global plugins, certificates, and production promotion. Look for RBAC that separates read, publish, approve, and administer actions, plus audit logs. In larger setups, tenant isolation matters so one group cannot accidentally expose another team's internal API through a shared gateway.
Can I mock or test an API before the gateway sees real traffic?+
Yes, and it is worth doing. Microcks turns OpenAPI, AsyncAPI, gRPC, and GraphQL artifacts into live mocks in seconds, then reuses the same artifacts for contract and non-regression tests wired into CI. Standing up a mock lets front-end and consumer teams build against a stable contract while the real service is still in progress, and catches breaking changes before they reach the gateway.