API Gateways for SaaS in 2026: Kong vs. Tyk vs. Apache APISIX vs. Building Your Own
Every SaaS product that exposes an API eventually needs an API gateway: a layer that handles authentication, rate limiting, routing, and analytics before requests reach your application. In 2026, the options range from managed services (AWS API Gateway, Kong) to self-hosted (Tyk, Apache APISIX) to building your own with a simple middleware layer. Here’s what actually matters when choosing.
Quick Answer
For most indie SaaS in 2026: start with managed services (AWS API Gateway, Kong Konnect, or Cloudflare API Gateway) until self-hosting’s cost savings justify the operational overhead. Kong is the right choice for self-hosted when you need complex plugin architectures and Kubernetes integration. Tyk wins for teams wanting a self-hosted solution with a good UI. Apache APISIX is the choice for high-throughput workloads requiring the lowest latency. Build your own (middleware) is valid only for trivial requirements — the complexity of production API management exceeds what simple middleware handles.
When You Need an API Gateway (And When You Don’t)
You need an API gateway when:
- Multiple microservices or micro-frontends need unified routing
- You expose your API to third-party developers who need their own API keys
- You need fine-grained rate limiting (per-user, per-plan, per-endpoint)
- You need centralized authentication (JWT validation, OAuth token exchange) across multiple services
- You need request/response logging, transformation, or analytics
You can skip an API gateway when:
- Single service, simple authentication (one JWT secret)
- Internal APIs consumed only by your own frontend (authenticate at the application layer)
- Low traffic where rate limiting and auth at the application level are sufficient
The mistake most indie founders make: buying an API gateway before they need one. Adding Kong or AWS API Gateway to a single-service application adds complexity without value. Add an API gateway when your architecture requires it, not preemptively.
Managed API Gateways: The Zero-Operations Option
AWS API Gateway
AWS API Gateway is the default for AWS-hosted applications. It integrates with AWS Lambda, ALB, and IAM, making it the lowest-friction choice for AWS-native applications. REST APIs and HTTP APIs both supported; HTTP APIs are cheaper and faster for most use cases.
Pros: native AWS integration, scales automatically, no servers to manage
Cons: vendor lock-in (migrating off AWS API Gateway is significant work), expensive at scale ($3.50 per million API calls for HTTP APIs), limited customization for advanced routing or transformation
Kong Konnect (Cloud)
Kong Konnect is Kong’s managed offering — the power of Kong without the operational overhead. You manage plugins and configuration; Kong manages the control plane and data planes.
Pros: Kong’s extensive plugin ecosystem, better customization than AWS API Gateway, works with any cloud or on-premise backend
Cons: more complex than AWS API Gateway, requires understanding Kong’s plugin system
Cloudflare API Gateway
Cloudflare’s API gateway integrates with their CDN, DDoS protection, and edge network. Best for applications already on Cloudflare or needing protection at the edge layer.
Pros: integrated DDoS protection, global edge deployment, simple configuration
Cons: requires Cloudflare for other services (not standalone), fewer plugins than Kong
Self-Hosted Options: When You Need Control
Kong (Self-Hosted)
Kong is the industry standard for self-hosted API gateways. Used by thousands of companies, from indie projects to Fortune 500s. The architecture: a declarative configuration file (deck) defines routes, services, and plugins; Kong applies the configuration to its data plane.
Kong’s strengths:
- Plugin ecosystem: 60+ official plugins (JWT, OAuth2, rate limiting, caching, CORS, logging) and hundreds of community plugins. If you need a capability, Kong probably has a plugin.
- Kubernetes native: Kong Ingress Controller makes Kubernetes deployments straightforward. Declarative config as code is well-supported.
- Performance: Handles 10K-100K+ requests/second on modest hardware. Horizontally scalable.
Kong’s requirements:
- Database: PostgreSQL or Cassandra for configuration storage. Adds operational complexity over stateless gateways.
- Configuration complexity: Kong’s declarative config is powerful but has a learning curve. The deck CLI helps but requires understanding Kong’s data model (services, routes, plugins).
Tyk
Tyk is the API gateway for teams that want a good GUI without the operational overhead of Kong. The dashboard provides visual API management (create APIs, configure auth, view analytics) without memorizing declarative config syntax.
Tyk’s strengths:
- Dashboard UX: Better than Kong’s for non-DevOps team members. Product managers can create API keys without touching YAML.
- Self-contained: Dashboard, gateway, and Redis (for rate limiting state) — everything runs locally.
- GraphQL native: First-class GraphQL support with automatic schema discovery and query validation.
Tyk’s limitations: smaller plugin ecosystem than Kong. Some integrations that exist in Kong require custom middleware with Tyk.
Apache APISIX
Apache APISIX prioritizes performance and low latency above all else. Built on Nginx, it handles high-throughput workloads with minimal overhead. The plugin system is hot-reloadable (change plugins without restarts) and supports Lua, JavaScript, and WASM plugins.
APISIX’s strengths:
- Latency: Lower p99 latency than Kong for equivalent workloads due to more efficient request handling.
- Hot reload: Update plugins without restarting. Critical for production systems where restarts cause brief outages.
- Cloud-native: Designed for Kubernetes from the ground up, with excellent Helm charts and CRD support.
APISIX’s limitations: smaller community than Kong. Less documentation, fewer Stack Overflow answers. Steeper learning curve if you’re new to API gateways.
Building Your Own: When It Makes Sense
For simple requirements, a custom middleware layer (Express.js middleware, Python decorator, etc.) handles auth, rate limiting, and logging without an API gateway. This approach works when:
- Single service, no routing complexity
- Auth via middleware (JWT verification)
- Rate limiting via Redis (per-IP or per-user)
- Simple request logging (store in database or ship to log aggregator)
Build your own when: your requirements are simple, your team has the expertise, and you don’t need advanced features (multi-service routing, enterprise auth protocols, complex analytics). The risk: requirements grow. The simple middleware that handled JWT verification for one service becomes the tangled mess that can’t handle adding a second service. Design for growth, not just today’s requirements.
Feature Comparison
| Feature | AWS API GW | Kong | Tyk | APISIX |
|---|---|---|---|---|
| Rates | $3.50/M calls | $0.0015/M calls (Konnect) | $0.0035/M calls | Self-hosted only |
| Self-hosted | ❌ | ✅ | ✅ | ✅ |
| Plugin ecosystem | Limited | 60+ official | 30+ | 50+ |
| Dashboard UI | AWS Console | Basic | ✅ Excellent | Basic |
| GraphQL support | ✅ | ✅ | ✅ Native | ✅ |
| Kubernetes | ❌ Native | ✅ Ingress Controller | ✅ Ingress | ✅ CRD-native |
| Best for | AWS-native apps | Complex custom needs | Team without DevOps | High-throughput |
Limitations
- Self-hosted gateways require DevOps investment: Updating, monitoring, and scaling an API gateway is real work. If your team is 2 people and neither is a DevOps engineer, the operational overhead of self-hosted gateways may exceed their value.
- Vendor lock-in is real for managed services: AWS API Gateway integrations are deeply coupled to AWS Lambda. Migrating to Kong or self-hosted later requires re-architecting your routing and auth layer.
- Plugin bugs affect production traffic: Kong and APISIX plugins run on every request. A poorly written plugin can slow down or crash all traffic. Test plugins thoroughly before deploying to production.
Bottom Line
Most indie SaaS products: start with AWS API Gateway (if on AWS) or Kong Konnect (if cloud-agnostic). The managed tier handles routing, auth, and rate limiting without operational overhead. When your bill exceeds $200/month for managed API Gateway, evaluate self-hosted Kong or APISIX — at that volume, the infrastructure cost is lower and you gain customization control. Build your own middleware only for trivially simple requirements — and design it to be replaceable when requirements grow.
FAQ
What’s the cost of self-hosting an API gateway?
Minimum: 2-core VM with 4GB RAM ($20-40/month). Kong, Tyk, and APISIX all run on this. At 10K requests/second+, you need multiple instances ($80-160/month for HA). Add monitoring (Datadog, self-hosted Prometheus), maintenance time (2-4 hours/month for updates and troubleshooting), and the true cost emerges. Self-hosted is cheaper than managed at scale, but the break-even point depends on your volume and DevOps capacity.
Can I use multiple API gateways for different services?
Yes, but it’s messy. Different gateways for different services (Kong for external APIs, AWS API GW for AWS services) add cognitive overhead. A single gateway that routes to different backend services is cleaner architecturally — use path prefixes (/api/v1/ → service A, /api/v2/ → service B) to route within one gateway.
How do I handle API versioning with an API gateway?
Common patterns: path versioning (/v1/users, /v2/users) or header versioning (API-Version: 2024-01). Path versioning is simpler and more visible; header versioning keeps URLs clean. Either works with any gateway. Set up routing rules to direct traffic to the appropriate backend service or version of your service.
What’s the migration path from AWS API Gateway to self-hosted?
Migrate incrementally: place a self-hosted gateway in front of one non-critical API, route a small percentage of traffic through it, validate behavior, then expand. This “shadow mode” approach catches issues before they affect all users. The key challenge: recreating authentication rules, rate limits, and custom authorizers in your new gateway. Deck (Kong’s config management) helps with migration from AWS.
Do I need an API gateway for a serverless architecture?
For AWS Lambda: AWS API Gateway or ALB is practically required — they’re how requests reach your functions. For Cloudflare Workers: Cloudflare’s built-in routing handles most use cases. For self-hosted serverless (OpenFaaS, Knative): an API gateway (Kong, APISIX) provides routing and auth. The “do I need an API gateway” question is partly answered by your platform — serverless platforms often include gateway capabilities.