Choosing an API Gateway in 2024, Kong, Tyk, and Envoy Gateway

TL;DR — Kong if you want a mature plugin ecosystem and don’t mind Postgres in the loop. Tyk if you’re SaaS-shaped and want a clean dashboard. Envoy Gateway if you’re already on Kubernetes and want to stop running a gateway that’s separate from your mesh.

I’ve shipped production traffic through all three of these in the last two years. Not benchmarks. Not pilots. Actual traffic, with on-call rotations and incident retros. The gap between marketing pages and operational reality is wide for every gateway, and the things that matter for the decision are almost never the things the vendors lead with.

This post is the comparison I wish I’d had when I last did a gateway selection. I’ll cover the three gateways I see most in 2024, what each is genuinely good at, and where each will hurt you. No “10 features compared” tables. Just the tradeoffs that change deployment outcomes.

If you’re earlier in the stack and not sure whether you need a gateway at all, the short answer is: if you have more than three public-facing services and you’re hand-rolling auth and rate limiting in each one, yes you do. A gateway centralizes that.

Kong, the incumbent

Kong 3.7 is what most teams I see in 2024 are running, often because they started on Kong 1.x or 2.x and the path of least resistance was to upgrade in place. It’s a reasonable default and the plugin ecosystem is genuinely the broadest in the market.

What Kong does well:

• Lua plugin ecosystem. Hundreds of plugins, most maintained, covering JWT, OAuth, rate limiting, request transformation, response caching, the lot. The custom plugin path in Lua is well-trodden.
• Declarative config. kong.yml plus decK for sync. Your gateway config lives in git. This is the table stakes for me in 2024 and Kong does it well.
• Mature observability. Prometheus exporter, OpenTelemetry plugin, good log formats. You can wire it into your existing stack without ceremony.

Where Kong hurts:

• Postgres dependency. Yes, you can run DB-less mode with declarative config, and it’s improved a lot. But the canonical path is still Kong + Postgres + the admin API. That’s two more things in your blast radius.
• Memory footprint. Kong on OpenResty (nginx + Lua) is heavier than Envoy or Tyk per-request. Not a problem until you’re running 50 instances and your infra bill notices.
• Plugin quality is uneven. The official Kong-maintained plugins are solid. Some community plugins are abandoned. Audit before you depend.

A minimal declarative Kong config that I’d actually ship:

# kong.yml
_format_version: "3.0"
_transform: true

services:
  - name: orders
    url: http://orders.internal:8080
    retries: 2
    connect_timeout: 2000
    read_timeout: 30000
    routes:
      - name: orders-v1
        paths: ["/v1/orders"]
        strip_path: false
    plugins:
      - name: jwt
        config:
          claims_to_verify: ["exp"]
          key_claim_name: kid
      - name: rate-limiting
        config:
          minute: 60
          hour: 1000
          policy: redis
          redis_host: redis.internal
          redis_port: 6379
          fault_tolerant: true
      - name: prometheus
        config:
          per_consumer: true
          status_code_metrics: true
          latency_metrics: true

fault_tolerant: true on the rate limiting plugin is the kind of thing that’s easy to miss and important. Without it, a Redis outage takes your gateway down. With it, requests pass through unlimited but un-blocked, which is the right failure mode for most use cases.

Tyk, the SaaS-shaped option

Tyk has been around as long as Kong but doesn’t get the same airtime. In 2024 it’s a viable choice, especially for teams that want a dashboard their non-engineering colleagues can use without breaking things.

What Tyk does well:

• Developer portal out of the box. If you’re shipping a public API and you need API key self-service, Tyk’s portal works. You can have it running in an afternoon. Kong has dev portal too, but Tyk’s is more turnkey.
• Multi-tenant story. Tyk’s notion of “organizations” maps cleanly onto B2B SaaS use cases where each tenant has separate quotas, keys, and policies.
• Native Go. No Lua, no nginx. The Tyk gateway is a single Go binary. Memory is reasonable, debugging is straightforward (it’s just Go), and custom middleware is in JS or gRPC plugins.

Where Tyk hurts:

• Smaller community. Fewer Stack Overflow answers, fewer blog posts, fewer “I solved this gnarly edge case” GitHub issues. You’ll be reading source code more than you would with Kong.
• Open Source vs Pro split. Some features you’d expect (advanced analytics, multi-data-center setups) are in Tyk Pro. Read the matrix carefully.
• Dashboard ergonomics. It’s a feature, but it’s also a footgun — well-meaning non-engineers can change policies in the UI and not commit them anywhere. Use the API and GitOps if you can.

Envoy Gateway, the new contender

Envoy Gateway 1.1 hit stable in 2024 and is what I’d pick for any greenfield Kubernetes-native project. It’s the official Envoy community implementation of the Kubernetes Gateway API. If you’re already running Envoy as your service mesh data plane, the consistency win is real.

What Envoy Gateway does well:

• Kubernetes Gateway API native. Not Ingress, not a CRD-pretending-to-be-Ingress. The full Gateway API surface, with HTTPRoute, GRPCRoute, TLSRoute, the whole thing. This is the future of K8s networking and Envoy Gateway is the most mature implementation.
• Envoy under the hood. Battle-tested data plane. The same Envoy that runs at Lyft, Netflix, Google. Performance is a non-issue.
• Mesh consistency. If you’re using Istio or any other Envoy-based mesh, having your gateway speak the same data plane means consistent observability, consistent failure modes, consistent config.

Where Envoy Gateway hurts:

• Ecosystem is younger. Plugin equivalents (ExtProc, Lua filters, WASM) all exist, but the off-the-shelf “JWT validation” or “rate limiting” experience is less polished than Kong’s. You’ll write more config.
• Gateway API learning curve. If your team doesn’t know HTTPRoute from Ingress, there’s a ramp. Not steep, but real.
• Operational maturity still proving out. I’ve run it for ~9 months in 2024 and it’s been solid, but it’s not 10 years of Kong production hours.

A minimal Envoy Gateway setup:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: edge
  namespace: gateway
spec:
  gatewayClassName: eg
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: edge-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders
  namespace: gateway
spec:
  parentRefs:
    - name: edge
  hostnames: ["api.example.com"]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1/orders
      backendRefs:
        - name: orders
          namespace: orders
          port: 8080
      timeouts:
        request: 30s
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: orders-jwt
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: orders
  jwt:
    providers:
      - name: auth0
        issuer: https://example.auth0.com/
        remoteJWKS:
          uri: https://example.auth0.com/.well-known/jwks.json
        audiences: ["api.example.com"]

JWT validation via SecurityPolicy, no plugin install, no Lua. The JWT patterns I described in securing Go microservices with JWT apply directly here for the upstream services.

The Envoy Gateway docs are worth bookmarking — the Gateway API spec evolves and you’ll reference them often.

What about cloud-managed (AWS, GCP, Azure)?

If you’re all-in on one cloud and have modest scale, the managed gateways (API Gateway, Cloud Endpoints, APIM) get you 80% of the way. You give up portability and pay for it. I won’t dwell on these — most readers of this post are running multi-cloud or on-prem and that’s where the open-source three matter.

How I actually decide

The decision tree I run in my head:

1. Already on Kubernetes with a service mesh? Envoy Gateway. The consistency wins are too good to pass up.
2. Need a polished developer portal for a public API? Tyk. Or Kong with the portal addon if you’re already on Kong.
3. VM-based deployment, lots of legacy services, need many plugins? Kong. It’s the safe bet.
4. Greenfield, no strong opinions, want minimal ops? Envoy Gateway if K8s, Tyk otherwise.

If you’re picking between two that both look fine, pick the one your team has more existing experience with. The gateway is not where you should be doing your team’s stretch learning.

Common Pitfalls

• Putting business logic in gateway plugins. Lua plugins, JS middleware, ExtAuthz services — they all tempt you. Resist. The gateway is for cross-cutting concerns (auth, rate limiting, observability), not business logic.
• Single point of failure. Whatever gateway you pick, run at least three instances. One per AZ minimum. The gateway is the single most critical thing in your stack — if it’s down, everything is down.
• No backpressure. A gateway with infinite request queueing will mask backend problems until they cascade. Set max connections, max requests per connection, and circuit breakers.
• Forgetting to test failure modes. What happens when Redis is unreachable from the gateway? What happens when the JWT provider’s JWKS endpoint is slow? You should know before production tells you.
• Skipping access logs. Whichever gateway you pick, ship access logs to a queryable store. When someone asks “why did this request 502”, access logs are the first place you look.

Wrapping Up

Gateway choice is mostly a function of your existing stack and team. The differences between Kong, Tyk, and Envoy Gateway in 2024 are real but not catastrophic — any of them will serve production traffic competently if configured well. Where teams get hurt is not in the choice itself but in the configuration discipline around it: GitOps the config, run multi-instance, monitor backpressure, test failure modes.

My personal default for new K8s-native projects in mid-2024 is Envoy Gateway. The Gateway API is winning, the data plane is rock solid, and the consistency with mesh is genuinely valuable. But I would not migrate an existing Kong deployment to Envoy Gateway without a real reason — the migration cost is high and the wins are modest if your Kong setup is already healthy.