Kong Gateway Enterprise

What do you like best about the product?

What I like most is the federated model: it gives each team its own gateway while still keeping central governance intact. I manage a few microservices across two environments, and before Konnect I was SSHing into different boxes just to push config changes. Now the SaaS control plane lets me handle everything from a single dashboard. I can spin up a runtime, attach my services, and configure rate limiting and JWT auth through the UI, and it’s live within minutes.

The developer portal is also a quiet win. I publish my APIs as products with OpenAPI specs, and external teams can self-serve onboarding instead of emailing me for credentials. The plugin system is genuinely modular, too—I’ve stacked key-auth, rate-limiting, and response-transforming plugins on the same route without writing a line of custom code.

What do you dislike about the product?

What I dislike is that the SaaS dependency is a hard requirement, not an option. The control plane lives in Kong’s cloud, which means that if their service has an outage, you can’t push config changes. For some enterprises, sending API metadata to a third-party cloud is a dealbreaker on its own.

The learning curve is also steeper than it needs to be. The difference between a “runtime group,” a “service,” a “route,” and a “target” takes a few sessions to click, and the docs often read like you already know the Kong Gateway CLI.

What problems is the product solving and how is that benefiting you?

Kong Konnect solves the problem of managing API gateways across multiple environments without manual config pushes. Before it, every time I needed to update a rate limit or add an auth plugin, I was SSHing into individual gateway nodes and applying changes one by one—slow, error-prone, and hard to audit. Now the SaaS control plane syncs configuration to all runtimes in seconds from a single dashboard, and I can see exactly what changed and when.

The developer portal also cuts down the whole “email me your API keys” cycle. External teams can self-serve onboarding, which saves me a lot of back-and-forth.

What do you like best about the product?

Kong Connect gives us a central layer for managing APIs while still fitting into our workflow. We mainly use it with our MCP server, and having the APIs set up so we can manage policies via Kong makes it easier for us to keep the integration controlled, instead of handling everything separately. The AI gateway part is also useful because it can manage authentication and our token usage across all services, rather than adding the same logic to each individual service. Overall, it helps us make better sense of the traffic.

What do you dislike about the product?

It took me a long time to understand the nuances of the product and get used to it. A few concepts, such as routes, services, and plugins, also take time to piece together.

What problems is the product solving and how is that benefiting you?

Our multiple backend AI integrations can be managed securely through the AI Gateway concept by Kong. We also have a couple of services that can be isolated, rather than running in the same gateway, so if one fails we still have another. In addition, the MCP and Claude workflows are managed smoothly, and we can monitor traffic, which gives us better visibility from the API layer.

What do you like best about the product?

I evaluated Kong Konnect as an API management and gateway solution for our Fulfillment Innovation Technology (FIT) project, which follows a microservice-based architecture. With multiple backend services, managing API routing, authentication, traffic control, and access policies individually in each service can become difficult to maintain. Kong Konnect provides a centralized layer in front of the backend services. It can handle requests coming from clients and route them to the appropriate service based on the configured routes and services. This is useful because the backend Spring Boot services can focus more on business logic instead of implementing the same API management functionality repeatedly. I also found features such as authentication, rate limiting, logging, and plugins useful for a microservice environment. These capabilities can be managed at the gateway level and applied consistently across different APIs. As the number of services increases, having a centralized API management layer makes the overall architecture easier to manage.

What do you dislike about the product?

The main area I think could be improved is the initial learning curve. There are several concepts to understand, including services, routes, plugins, authentication, policies, and configuration. For someone who is new to API gateways, it can take some time to understand how these different components work together. For a project with only a few APIs, Kong Konnect can also feel like more infrastructure than what is necessary. However, for a larger microservice architecture such as FIT, the additional setup can provide more value because there are more APIs and common requirements to manage. I think the onboarding experience could be improved with more beginner-friendly, end-to-end examples. A sample Spring Boot microservice application showing routing, authentication, rate limiting, and plugins together would make it much easier for new users to understand the product.

What problems is the product solving and how is that benefiting you?

One of the main problems Kong Konnect can solve is the complexity of managing APIs across multiple microservices. In a project like FIT, different services may expose different APIs, and managing authentication, routing, traffic limits, and access policies separately can lead to duplicated configuration and logic. Kong provides a centralized place to manage these concerns. For example, routing rules can determine which backend service should receive a request, while authentication can provide a common security layer for APIs. Rate limiting can also help control excessive traffic and protect backend services from unnecessary load. Another benefit is consistency. Instead of implementing similar API-related functionality in every Spring Boot service, common requirements can be handled at the gateway level. This makes the services more focused on their actual business responsibilities and can make the overall system easier to maintain as the number of microservices grows.

What do you like best about the product?

The centralized layer for managing APIs—and handling auth and rate-limiting policies across different services—can be managed at the gateway level. Especially with the AI gateway for MCP servers, it’s good for consistent authentication, traffic control, and isolation across all my apps. The visibility into API traffic is also a great feature; when I’m working with different integrations, troubleshooting becomes much easier.

What do you dislike about the product?

There was a gap in the learning curve when I was getting started. There are a lot of concepts around services, routes, plugins, and consumers, and understanding how all of this fits together takes time. The UI is good overall, but it can feel a tad dense.

What problems is the product solving and how is that benefiting you?

It compares fairly well with integrations managed across different services. For MCP based integrations, having them as part of the same application stack with a common gateway layer makes it easier to apply auth, rate limiting, and monitoring especially for AI usage by individuals. Having a gateway in front of services also provides a common layer that others can reuse, with most of the setup already in place.

What do you like best about the product?

Definitely Kong Gateway, since it’s delivered solid API performance for us at scale. Another standout is the analytics feature, which gives me genuinely useful numbers to bring into client conversations. The integrations also fit smoothly with our existing ecosystem, so it’s been easy to align with what we already use. Support is especially valuable when an account has a more complex setup and needs extra attention. Overall, ROI is much easier to explain and discuss when API usage is clearly visible.

What do you dislike about the product?

It’s a great platform to start with, but over time the UI can feel a bit dense, especially when you’re managing multiple services. Pricing can also be disruptive, since it often requires detailed, account-level discussions to sort out.

What problems is the product solving and how is that benefiting you?

API traffic was starting to raise performance concerns for us, especially during peak usage. Kong Gateway helped by giving us stronger traffic control and clearer visibility, which made it easier to manage those workloads. At the same time, our growing AI services were increasing the number of APIs we needed to monitor. Kong’s AI Gateway gave the team a more structured way to handle those AI integrations, and in the end everything worked out perfectly.