What do you dislike about KrakenD API Gateway?
The documentation is not the most pleasant I have worked with. You do end up finding what you need, but a search often lands you on the Community page when you are running Enterprise, and the variations between the two are small enough that you lose your bearings. It also does not say everything: some behaviours we depend on only show up by testing, which is why we run a small integration lab against a real KrakenD before implementing against it. Their AI assistant tooling helps here, edition checks included.
Plugin development takes some setup: plugins have to be compiled against the exact Go and musl versions of the target build, using their builder image, so you cannot simply build locally. In fairness that is Go's plugin model rather than anything KrakenD chose, and once the pipeline is in place it does not move. A first-day cost, not an ongoing one. Review collected by and hosted on G2.com.
Recommendations to others considering KrakenD API Gateway:
To improve the documentation, consider creating separate sections for Enterprise and Community users to avoid confusion. Additionally, ensure that all behaviors and features are well-documented to reduce reliance on testing for discovery. Streamlining the plugin development process by providing more detailed guides and examples could also be beneficial. Review collected by and hosted on G2.com.
What problems is KrakenD API Gateway solving and how is that benefiting you?
Our API started as a single monolith, with JWT validation, request and response validation and rate limiting implemented endpoint by endpoint, inside the application. That holds up while there is only one application. The moment we wanted to pull services out of it, each one would have re-implemented the same logic its own way.
KrakenD is what made that extraction practical. Our API definitions are centralised in OpenAPI contracts and the gateway enforces those cross-cutting concerns at the edge, so a service we extract inherits them instead of carrying them. We are not chasing microservices, the services we pull out are large, but they come out uniform by construction rather than by discipline.
The bigger payoff came later. Because the gateway config is generated from those same contracts, we exposed the same operations as MCP tools for LLM agents - more than 200 of them - with a single annotation per operation, plus per-audience API documentation served from the gateway itself. One contract, three delivery surfaces, and the governance we had already built for REST applied to the agent surface for free. Review collected by and hosted on G2.com.
