This is an automated email from the ASF dual-hosted git repository.
Yilialinn pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new d508b5b8fb3 refactor(seo): refresh APISIX comparison content (#2121)
d508b5b8fb3 is described below
commit d508b5b8fb3d4cb484bb38e5aa1316da1d9e3a9a
Author: Yilia Lin <[email protected]>
AuthorDate: Fri Sep 18 13:59:24 2026 +0800
refactor(seo): refresh APISIX comparison content (#2121)
---
.../api-gateway-vs-load-balancer.md | 161 +++++++++---------
website/learning-center/apisix-vs-kong.md | 182 +++++++++++----------
website/learning-center/apisix-vs-traefik.md | 144 +++++++++-------
website/src/pages/comparisons.tsx | 4 +-
website/static/llms.txt | 4 +-
5 files changed, 257 insertions(+), 238 deletions(-)
diff --git a/website/learning-center/api-gateway-vs-load-balancer.md
b/website/learning-center/api-gateway-vs-load-balancer.md
index ac9e3172e57..d184bd80b6a 100644
--- a/website/learning-center/api-gateway-vs-load-balancer.md
+++ b/website/learning-center/api-gateway-vs-load-balancer.md
@@ -5,133 +5,120 @@ slug: api-gateway-vs-load-balancer
date: 2026-04-14
tags: [api-gateway, load-balancer, architecture]
hide_table_of_contents: false
+faq:
+ - q: "Does upstream load balancing make an API gateway highly available?"
+ a: >-
+ No. Upstream load balancing distributes requests from the gateway to
backend instances. The gateway tier still needs multiple nodes, a stable entry
point, health checks, and a failure-handling plan so that the gateway itself
does not become a single point of failure.
+ - q: "Who should own health checks when a load balancer and API gateway are
both deployed?"
+ a: >-
+ A common division is for the external load balancer to check gateway
nodes while the gateway checks its service upstreams. Define ownership at each
boundary and avoid overlapping checks that can remove healthy targets for
different reasons or create conflicting recovery behavior.
+ - q: "How should retries be configured across a load balancer and an API
gateway?"
+ a: >-
+ Assign a bounded retry budget to the layer that has the best view of
each failure boundary. Uncoordinated retries at both layers can multiply
requests, increase latency, and replay operations that are not safe to repeat.
Test timeout and retry behavior together under partial failures.
---
-An API gateway and a load balancer serve different primary purposes. A load
balancer distributes network traffic across multiple backend servers to
maximize throughput and availability. An API gateway operates at the
application layer to manage, secure, and transform API traffic with features
like authentication, rate limiting, and request routing. In modern
architectures, they complement each other and are frequently deployed together.
+A load balancer distributes traffic across healthy backend instances. An API
gateway controls how clients use APIs through routing and policies such as
authentication, rate limiting, transformation, and observability. Their
capabilities overlap at Layer 7, but they solve different architectural
problems. Many production systems use both: a network or cloud load balancer
exposes a highly available gateway cluster, and the gateway applies API
policies before balancing requests across services.
-## What is a Load Balancer
+## What Is a Load Balancer?
-A load balancer sits between clients and a pool of backend servers,
distributing incoming requests to ensure no single server becomes overwhelmed.
Load balancers operate at either Layer 4 (TCP/UDP) or Layer 7 (HTTP/HTTPS) of
the OSI model.
+A load balancer presents one endpoint in front of multiple servers and selects
a healthy target for each connection or request. Its primary goals are
availability, horizontal scaling, and efficient traffic distribution.
-Layer 4 load balancers route traffic based on IP address and port number
without inspecting the request content. They are fast, protocol-agnostic, and
add minimal latency. Layer 7 load balancers inspect HTTP headers, URLs, and
sometimes request bodies to make more intelligent routing decisions.
+Load balancers commonly operate at one of two layers:
-Load balancers are foundational infrastructure. The vast majority of
organizations use some form of load balancing in their production environments.
The technology has been a networking staple for over two decades, with the core
algorithms (round-robin, least connections, weighted distribution) remaining
largely unchanged.
+- **Layer 4 load balancing** uses transport information such as IP addresses,
ports, and TCP or UDP connections. It can distribute traffic without
interpreting an HTTP request.
+- **Layer 7 load balancing** understands application protocols such as HTTP
and HTTPS. Depending on the product, it can route by host, path, header, or
other request attributes and may provide selected security or
traffic-management features.
-The primary value of a load balancer is availability. By distributing traffic
and performing health checks, load balancers ensure that the failure of a
single backend instance does not cause a service outage. They also enable
horizontal scaling: adding more backend instances to handle increased traffic
without changing the client-facing endpoint.
+The exact boundary depends on the implementation. A modern application load
balancer may support TLS termination, identity integration, redirects, header
modification, or weighted routing. It should not be treated as a featureless
network component.
-## What is an API Gateway
+## What Is an API Gateway?
-An [API gateway](/learning-center/what-is-an-api-gateway/) is an
application-layer proxy that acts as the single entry point for API consumers.
Beyond routing requests to the correct backend service, an API gateway provides
a rich set of cross-cutting concerns: authentication, authorization, rate
limiting, request and response transformation, caching, logging, and monitoring.
+An [API gateway](/learning-center/what-is-an-api-gateway/) is an
application-aware entry point for APIs. It routes requests to services and
provides a policy layer for concerns that would otherwise be implemented
repeatedly across clients or backends.
-API gateways emerged from the needs of microservices architectures and
API-first product strategies. When an organization exposes dozens or hundreds
of microservices, a gateway centralizes the operational concerns that would
otherwise be duplicated across every service.
+Typical gateway responsibilities include authenticating callers, enforcing
general access policies, applying per-consumer or per-route limits, rewriting
requests and responses, collecting gateway telemetry, and managing traffic
between API versions or upstream services. Services still own business
authorization, resource ownership, and domain-specific rules.
-An API gateway typically operates exclusively at Layer 7 and understands
application-level protocols like HTTP, gRPC, WebSocket, and GraphQL. It makes
routing decisions based on URL paths, headers, query parameters, and even
request body content.
+API gateways primarily work at Layer 7. Some products can also proxy TCP or
UDP traffic, but their API-specific policies generally apply to the protocols
and request phases supported by that gateway.
-## Feature Comparison
+## API Gateway vs Load Balancer
-| Capability | Load Balancer | API Gateway |
-|-----------|--------------|-------------|
-| Traffic distribution | Yes (core function) | Yes (built-in) |
-| Health checks | Yes | Yes |
-| SSL/TLS termination | Yes | Yes |
-| Layer 4 routing | Yes | Typically no |
-| Layer 7 routing | L7 LB only | Yes (core function) |
-| Authentication | No | Yes |
-| Authorization | No | Yes |
-| Rate limiting | Basic (some L7 LBs) | Yes (granular) |
-| Request transformation | No | Yes |
-| Response transformation | No | Yes |
-| API versioning | No | Yes |
-| Protocol translation | Limited | Yes (HTTP to gRPC, REST to GraphQL) |
-| Caching | Limited | Yes |
-| Developer portal | No | Yes (with management layer) |
-| Analytics and monitoring | Basic metrics | Detailed API analytics |
-| Circuit breaking | Some implementations | Yes |
-| Canary/blue-green deploys | Some implementations | Yes |
+The table describes common product roles, not a universal feature checklist.
Layer 7 load balancers and API gateways continue to adopt overlapping
capabilities, so a product evaluation should verify the exact policy model and
protocol support you need.
-The table makes the distinction clear: load balancers focus on network-level
traffic distribution, while API gateways focus on application-level API
management. The overlap exists primarily in Layer 7 load balancers, which have
gradually added some application-aware features.
+| Dimension | Load Balancer | API Gateway |
+| --- | --- | --- |
+| Primary purpose | Distribute traffic across healthy targets | Route and
govern API traffic |
+| Common operating layer | Layer 4 or Layer 7 | Primarily Layer 7 |
+| Routing model | Listener and target-pool rules | API routes, methods,
headers, consumers, and other request attributes |
+| Health checks | Core capability in most products | Commonly available for
gateway upstreams |
+| TLS termination | Common | Common |
+| Authentication | Available in some Layer 7 products | Common gateway policy |
+| Rate limiting | Product-dependent | Commonly configurable by route,
consumer, credential, or other keys |
+| Request and response changes | Product-dependent | Common through explicit
gateway policies or plugins |
+| Protocol conversion | Not a typical load-balancing concern | Available only
when the gateway supports and is configured for a specific conversion |
+| Observability | Connection, target, and request metrics vary by product |
API route, consumer, plugin, and upstream telemetry varies by configuration |
+| Traffic releases | Weighted target routing in many products | Route- and
upstream-level traffic controls, depending on the gateway |
-## Key Differences Explained
+The most useful distinction is the operating model. A load balancer is
centered on listeners, target groups, and target health. An API gateway is
centered on APIs, routes, consumers, credentials, and reusable policies.
-### Scope of Concern
+## Where the Capabilities Overlap
-A load balancer answers the question: which backend server should handle this
connection? An API gateway answers a broader set of questions: is this client
authenticated? Are they authorized for this endpoint? Have they exceeded their
rate limit? Does the request need transformation before forwarding? Should the
response be cached?
+Both components can terminate TLS, route HTTP traffic, check backend health,
retry selected failures, and distribute requests among targets. A Layer 7 load
balancer may be sufficient when an application needs host- or path-based
routing but only a small set of API policies.
-In practice, most organizations using API gateways configure multiple
cross-cutting policies (authentication, rate limiting, logging, and CORS), none
of which fall within a traditional load balancer's responsibility.
+An API gateway becomes useful when policies need to follow API semantics.
Examples include applying different authentication methods to different routes,
enforcing quotas for individual consumers, transforming a request for a
specific upstream, or recording metrics by API route. Protocol conversion is
not automatic: it requires a supported capability and an explicit mapping. For
example, Apache APISIX provides a [`grpc-transcode`
plugin](/docs/apisix/plugins/grpc-transcode/) for configur [...]
-### Protocol Awareness
+## Where Should a Load Balancer Sit Relative to an API Gateway?
-Load balancers, especially at Layer 4, are largely protocol-agnostic. They
route TCP connections without understanding the application protocol. API
gateways are deeply protocol-aware. They parse HTTP methods, match URL
patterns, inspect headers, and in many cases understand domain-specific
protocols like gRPC and GraphQL.
+There is no single correct placement. Three patterns are common.
-This protocol awareness enables capabilities that load balancers cannot
provide. For example, an API gateway can route GraphQL queries to different
backend services based on the query's requested fields, or translate between
REST and gRPC protocols transparently.
+### Load Balancer in Front of an API Gateway Cluster
-### Configuration Granularity
+```text
+Clients -> Load balancer -> API gateway nodes -> Backend services
+```
-Load balancer configuration centers on server pools, health check parameters,
and distribution algorithms. API gateway configuration is far more granular:
per-route authentication requirements, per-consumer rate limits, request header
injection, response body transformation, and conditional plugin execution.
+The load balancer exposes a stable network endpoint and distributes
connections across multiple gateway nodes. The gateway nodes then apply API
policies and select backend services. This pattern is useful when a cloud
platform, Kubernetes environment, or network team provides the external entry
point and the gateway must be deployed for high availability.
-A typical enterprise API gateway configuration manages 50-200 routes with
distinct policy combinations, compared to a load balancer managing 10-30 server
pools. The operational complexity reflects the difference in scope.
+### API Gateway Balancing Across Service Instances
-### Performance Profile
+```text
+Clients -> API gateway -> Service instances
+```
-Layer 4 load balancers add microsecond-level latency because they operate
below the HTTP layer. API gateways add millisecond-level latency because they
must parse, inspect, and potentially transform HTTP requests. High-performance
gateways like Apache APISIX, built on NGINX and LuaJIT, keep this overhead
under 1ms for typical configurations. According to APISIX benchmark data, the
gateway processes over 20,000 requests per second per core with authentication
and rate limiting enabled.
+If the gateway already receives traffic through a suitable highly available
endpoint, it can balance requests across the instances of each upstream
service. This can remove a separate Layer 7 load-balancing hop between the
gateway and those services. It does not remove the need to design availability
for the gateway nodes themselves.
-## When to Use Which
+### Load Balancer Without an API Gateway
-### Use a Load Balancer When
+```text
+Clients -> Load balancer -> Application instances
+```
-- You need to distribute TCP or UDP traffic across backend instances.
-- Your primary concern is availability and horizontal scaling.
-- You are load balancing non-HTTP protocols (databases, message queues, custom
TCP services).
-- You want minimal latency overhead with no application-layer processing.
+This is often sufficient for applications that primarily need availability and
scaling, have no shared API policy requirements, or already implement the
necessary controls elsewhere.
-### Use an API Gateway When
+## When to Use Each
-- You expose APIs to external consumers who need authentication and rate
limiting.
-- You run a microservices architecture and need centralized cross-cutting
concerns.
-- You need request or response transformation between clients and services.
-- You require detailed API analytics, logging, and monitoring.
-- You manage multiple API versions or need protocol translation.
+Use a load balancer when the main requirement is to distribute TCP, UDP, HTTP,
or HTTPS traffic across healthy targets, expose a stable endpoint, or provide
network-level availability for a cluster.
-### Use Both Together
+Use an API gateway when you need consistent API routing and policies across
services, such as caller authentication, granular rate limits, request
transformation, API-specific telemetry, or controlled traffic migration.
-In most production architectures, load balancers and API gateways coexist at
different layers. A common deployment pattern places a Layer 4 or cloud-native
load balancer (AWS NLB, Google Cloud Load Balancing) in front of a cluster of
API gateway instances. The load balancer distributes traffic across gateway
nodes for high availability, while the gateway handles application-level API
management.
+Use both when the gateway itself needs a highly available network entry point
or when infrastructure and API policy have separate owners. Before adding both
layers, verify that each component has a distinct responsibility; duplicate
retries, timeouts, health checks, and routing rules can make failures harder to
diagnose.
-This separation of concerns allows each component to do what it does best.
+## How Apache APISIX Handles Load Balancing
-## How Apache APISIX Combines Both
+Apache APISIX is an open-source API gateway with load balancing in its core
request-processing path. An APISIX
[Upstream](/docs/apisix/terminology/upstream/) represents a set of service
nodes and the rules used to select among them. Supported algorithms include:
-Apache APISIX is an API gateway that includes built-in load balancing
capabilities, effectively combining both roles into a single component for many
use cases.
+- **Weighted round robin (`roundrobin`)** to distribute requests according to
node weights.
+- **Consistent hashing (`chash`)** to select nodes from a configurable key
such as a request variable, header, cookie, or authenticated consumer.
+- **Exponentially weighted moving average (`ewma`)** to prefer nodes with
lower observed latency.
+- **Least connections (`least_conn`)** to account for active connections and
configured node weights.
-APISIX supports multiple load balancing algorithms natively, documented in its
[load balancing guide](/docs/apisix/getting-started/load-balancing/):
+Upstreams can also use active and passive [health
checks](/docs/apisix/tutorials/health-check/) and retries. For controlled
releases across different upstreams, the [`traffic-split`
plugin](/docs/apisix/plugins/traffic-split/) provides condition- and
weight-based traffic distribution.
-- **Round-robin (weighted):** Distributes requests across upstream nodes based
on configured weights.
-- **Consistent hashing:** Routes requests to the same backend based on a
configurable key (IP, header, URI), useful for cache-friendly distributions.
-- **Least connections:** Sends requests to the upstream node with the fewest
active connections.
-- **EWMA (Exponential Weighted Moving Average):** Selects the upstream node
with the lowest response latency, adapting to real-time backend performance.
+APISIX can therefore perform application-layer routing, API policy
enforcement, and upstream load balancing in the same gateway layer. It does not
automatically replace an external load balancer. A separate cloud, hardware, or
Layer 4 load balancer may still provide the public entry point, distribute
connections across APISIX nodes, or supply network services outside the
gateway's scope. APISIX can also be configured as a [stream
proxy](/docs/apisix/stream-proxy/) for TCP and UDP traffic [...]
-By combining API gateway features with production-grade load balancing, APISIX
reduces architectural complexity for many deployments. Organizations that would
otherwise deploy a separate load balancer and a separate API gateway can
consolidate into a single APISIX layer, reducing operational overhead and
network hops.
+## Compare Performance in Your Own Traffic Path
-For large-scale deployments, a dedicated Layer 4 load balancer in front of
APISIX nodes still makes sense for TCP-level high availability and DDoS
protection. But within the application layer, APISIX handles both traffic
distribution and API management without requiring an additional component.
+Adding application-layer inspection and policies requires work that a simple
Layer 4 forwarding path does not perform. The actual latency and throughput
difference depends on the products, protocols, TLS configuration, enabled
gateway policies, logging, upstream behavior, hardware, and traffic shape. A
universal microsecond or millisecond estimate is not reliable enough for
architecture decisions.
-## FAQ
+Benchmark the configurations you intend to operate. Compare at least the load
balancer alone, the gateway with routing only, and the gateway with the
production policy set. Measure tail latency as well as average latency, and
test failure behavior such as unhealthy upstreams, retries, and gateway-node
loss. This reveals whether an additional layer creates meaningful cost in your
environment and whether its policy benefits justify that cost.
-### Can an API gateway replace a load balancer entirely?
+## Conclusion
-For HTTP and gRPC traffic, a modern API gateway like Apache APISIX can replace
a Layer 7 load balancer because it includes equivalent load balancing
algorithms. However, for non-HTTP protocols (raw TCP, UDP, database
connections) or for Layer 4 DDoS protection, a dedicated load balancer remains
necessary. The most common production pattern uses both: a Layer 4 load
balancer for network-level distribution and an API gateway for
application-level management.
-
-### Does adding an API gateway increase latency compared to a load balancer
alone?
-
-Yes, but the increase is typically small. A Layer 4 load balancer adds
microseconds of latency. An API gateway adds 0.5-2ms depending on the number of
active plugins. For most APIs where upstream service response times are
10-500ms, the gateway overhead is negligible. The operational benefits of
centralized authentication, rate limiting, and observability far outweigh the
minor latency cost.
-
-### Should I use a cloud provider's managed API gateway or deploy my own?
-
-Managed gateways (AWS API Gateway, Google Apigee) reduce operational burden
but limit customization and can become expensive at high traffic volumes. AWS
API Gateway charges per million requests, which can reach thousands of dollars
monthly for high-traffic APIs. Self-managed gateways like Apache APISIX offer
full control, unlimited throughput on your infrastructure, and no per-request
fees, but require your team to operate the gateway cluster. Evaluate based on
your traffic volume, cust [...]
-
-### How does an API gateway differ from a reverse proxy?
-
-A reverse proxy forwards client requests to backend servers and is the
foundation of both load balancers and API gateways. An API gateway is a
specialized reverse proxy that adds API-specific features: authentication, rate
limiting, request transformation, API versioning, and developer-facing
analytics. NGINX, for example, can function as a reverse proxy, load balancer,
or (with extensions) an API gateway. Apache APISIX is purpose-built as an API
gateway with load balancing built in.
-
-## Related
-
-- [Compare API gateways](/comparisons/)
-- [API gateway for
microservices](/learning-center/api-gateway-for-microservices/)
+A load balancer answers where a connection or request should go among healthy
targets. An API gateway also decides how an API request should be admitted,
shaped, observed, and routed. Use the smallest architecture that satisfies both
availability and API policy requirements. When both are needed, give the load
balancer responsibility for the gateway cluster's network entry point and give
the gateway responsibility for APIs and their upstream services.
diff --git a/website/learning-center/apisix-vs-kong.md
b/website/learning-center/apisix-vs-kong.md
index 4f13edcf733..84f15f535f6 100644
--- a/website/learning-center/apisix-vs-kong.md
+++ b/website/learning-center/apisix-vs-kong.md
@@ -1,144 +1,156 @@
---
-title: "Apache APISIX vs Kong: Feature Comparison & Performance Benchmarks"
-description: "Compare Apache APISIX and Kong API Gateway across architecture,
performance, plugin ecosystem, Kubernetes support, and migration tradeoffs."
+title: "Apache APISIX vs Kong: Architecture, Features, and Tradeoffs"
+description: "Compare Apache APISIX and Kong across deployment topology,
configuration, plugins, Kubernetes integration, performance testing, and
migration tradeoffs."
slug: apisix-vs-kong
date: 2026-04-14
tags: [comparison, apisix, kong, api-gateway]
hide_table_of_contents: false
faq:
- - q: "Can APISIX and Kong run side by side during a migration?"
+ - q: "Does Apache APISIX always require etcd?"
a: >-
- Yes. Both gateways can operate in parallel by splitting traffic at the
load balancer level. A common migration strategy routes new services through
APISIX while existing services continue running through Kong. Gradual traffic
shifting with health checks ensures zero-downtime migration. The timeline
depends on the number of routes, custom plugins, and testing requirements.
- - q: "Is APISIX harder to operate because it requires etcd?"
+ No. APISIX uses etcd in its traditional and decoupled deployment modes.
File-driven standalone is the general etcd-free option and loads complete local
YAML or JSON configuration. API-driven standalone is designed for APISIX
Ingress Controller and ADC integrations, which replace full routing state
through a dedicated API rather than using it as a general operator-facing mode.
+ - q: "Can Kong configuration be imported directly into Apache APISIX?"
a: >-
- etcd adds a dependency compared to Kong's DB-less mode, but in practice,
etcd is a well-understood, battle-tested component already present in most
Kubernetes clusters (it is the backing store for Kubernetes itself). Operating
etcd requires standard distributed systems practices: run an odd number of
nodes (3 or 5), monitor disk latency, and maintain regular snapshots. For teams
already running Kubernetes, etcd operational knowledge is typically already
available. The operational c [...]
- - q: "How do the two gateways compare on gRPC and streaming support?"
+ There is no universal direct conversion because the gateways use
different entity schemas, route matching rules, plugin phases, credentials, and
state models. A migration should map and test each service, route, consumer,
plugin, certificate, and operational behavior before traffic is shifted.
+ - q: "Which gateway is a better fit for Kubernetes?"
a: >-
- APISIX provides native gRPC proxying, gRPC-Web transcoding, and
HTTP-to-gRPC transformation out of the box, along with support for HTTP/3
(QUIC), Dubbo, and MQTT protocols. Kong supports gRPC proxying and gRPC-Web
through plugins, with HTTP/2 support on both client and upstream connections.
For teams heavily invested in gRPC or multi-protocol architectures, APISIX's
broader built-in protocol support reduces the need for custom plugins or
sidecars.
+ Both projects provide Kubernetes ingress controllers, so the decision
depends on the exact Ingress, Gateway API, and custom resources your platform
requires. Test the relevant support matrix, status reporting, secret handling,
upgrade behavior, and configuration convergence for the controller version you
intend to deploy.
---
-Apache APISIX and Kong are the two most widely adopted open-source API
gateways, both built on NGINX and Lua. APISIX differentiates itself with a
fully dynamic architecture powered by etcd, higher single-core throughput, and
a broader protocol support matrix, while Kong offers a mature enterprise
ecosystem with extensive third-party integrations and a large plugin
marketplace.
+Apache APISIX and Kong are open-source API gateways with mature routing,
traffic management, authentication, observability, and Kubernetes integrations.
Their most important differences are not a single feature count or benchmark
result, but how they store and distribute configuration, which deployment
models they support, and how their plugin ecosystems are packaged.
-## Overview
+Apache APISIX combines an Apache-governed project and [100+ open-source
plugins](/plugins/) with etcd-backed and standalone deployment modes. Kong
offers database-backed, DB-less, and hybrid control-plane/data-plane
topologies, plus an ecosystem that includes open-source, Enterprise-only, and
separately licensed plugins. The right choice depends on the topology,
policies, extensions, and operating model your team needs.
-Both projects serve as high-performance, extensible API gateways for
microservices architectures. Kong was open-sourced in 2015 and has built a
substantial commercial ecosystem around Kong Gateway Enterprise, Kong Konnect,
and the Kong Plugin Hub. Apache APISIX entered the Apache Software Foundation
incubator in 2019 and graduated as a top-level project in 2020, with rapid
community growth.
+For a broader shortlist, see the [open-source API gateway
comparison](/learning-center/open-source-api-gateway-comparison/).
-Both projects are recognized as production-grade gateways and see active
production deployments worldwide.
+## APISIX vs Kong at a Glance
-## Architecture Comparison
+| Dimension | Apache APISIX | Kong Gateway |
+| --- | --- | --- |
+| Project and product model | Apache Software Foundation open-source project |
Open-source gateway with vendor-backed commercial products and services |
+| Deployment topology | Traditional, decoupled control/data plane, and
standalone modes | Traditional database-backed, DB-less, and hybrid
control/data plane modes |
+| Configuration state | etcd in traditional and decoupled modes; local
YAML/JSON in file-driven standalone; in-memory full-state updates for
API-driven integrations | Database in traditional mode; declarative
configuration held by each node in DB-less mode; control plane distributes
configuration to data planes in hybrid mode |
+| Runtime configuration | Admin API with etcd-backed updates; file detection
in general standalone deployments; a dedicated full-state API for Ingress
Controller or ADC integrations | Admin API in database-backed deployments; full
declarative reloads in DB-less mode; control-plane updates in hybrid mode |
+| Plugin ecosystem | 100+ open-source plugins, native Lua plugins, external
plugin runners, and experimental Wasm support | Plugin Hub with open-source,
Enterprise-only, and license-required plugins; custom plugins through supported
PDKs |
+| Kubernetes | APISIX Ingress Controller supports Kubernetes Ingress,
supported Gateway API resources, and APISIX custom resources | Kong Ingress
Controller translates Ingress, Gateway API, and Kong custom resources into Kong
Gateway configuration |
+| Performance evaluation | Official APISIX benchmarks are available, but must
be interpreted using their documented environment and workload | Official Kong
benchmarks are available, with results that depend on version, topology,
plugins, and test environment |
-The architectural differences between APISIX and Kong are fundamental and
affect day-to-day operations, scalability, and deployment complexity.
+Feature availability changes across versions and Kong editions. Verify any
requirement against the current documentation for the exact version and
distribution you plan to deploy.
-### Apache APISIX Architecture
+## Architecture and Configuration
-APISIX uses NGINX as its data plane with Lua plugins running in the request
lifecycle. Configuration is stored in **etcd**, a distributed key-value store
that pushes changes to all gateway nodes in real time via watch mechanisms.
This architecture means that route changes, plugin updates, and upstream
modifications take effect within milliseconds without requiring restarts or
reloads. There is no relational database dependency.
+### Apache APISIX
-The etcd-based design gives APISIX a stateless data plane: any node can be
added or removed without migration steps or database schema changes. This makes
horizontal scaling straightforward and reduces operational overhead
significantly in Kubernetes environments where pods are ephemeral.
+Apache APISIX is built on NGINX and LuaJIT. In its traditional mode, a node
handles both control-plane and data-plane responsibilities, while decoupled
mode separates those roles. Both modes can use etcd as the configuration
provider. APISIX nodes watch configuration changes in etcd and update in-memory
routing and plugin state without replacing worker processes.
-### Kong Architecture
+APISIX also provides [standalone deployment
modes](/docs/apisix/deployment-modes/) that do not use etcd as the
configuration center. File-driven standalone is the general etcd-free option:
it loads a complete YAML or JSON configuration and watches the local file for
changes. API-driven standalone stores the configuration in memory and replaces
it through a dedicated full-state API, but it is designed specifically for
APISIX Ingress Controller and ADC integrations rather than as a general [...]
-Kong also uses NGINX and Lua for its data plane. Configuration is stored in
**PostgreSQL** or **Cassandra** (though Cassandra support has been deprecated
in newer versions). Kong's DB-mode requires database migrations when upgrading,
and configuration changes propagate through a polling mechanism with a
configurable cache TTL, which introduces a delay between API calls to the Admin
API and actual enforcement at the proxy layer.
+APISIX supports an [embedded Dashboard UI](/docs/apisix/dashboard/) for
managing routes, plugins, and upstreams through the Admin API. Its availability
depends on whether the selected APISIX package or build includes the compiled
UI assets. When enabled, production deployments still need to restrict access
to the Admin API and protect its credentials.
-Kong also offers a DB-less mode where configuration is loaded from a
declarative YAML file, which eliminates the database dependency but sacrifices
the ability to modify configuration dynamically through the Admin API at
runtime. Kong's commercial offering, Konnect, provides a managed control plane
that addresses many of these operational concerns.
+### Kong
-## Performance Benchmarks
+Kong documents three main [deployment
topologies](https://developer.konghq.com/gateway/deployment-topologies/):
-Performance characteristics matter at scale, where even small per-request
overhead compounds into significant infrastructure costs.
+- **Traditional mode:** Gateway nodes connect to a database that stores
configured entities. Each node performs both control-plane and data-plane
responsibilities.
+- **DB-less mode:** Each node holds declarative configuration in memory.
Operators load a complete YAML or JSON configuration at startup or through the
`/config` endpoint. Entity management through the Admin API is read-only in
this mode, and plugins that require database-backed state have limitations.
+- **Hybrid mode:** Control-plane nodes manage configuration and distribute it
to data-plane nodes. Data planes do not connect directly to the control-plane
database and cache the latest configuration they receive.
-Key architectural differences that affect performance:
+These topologies have materially different failure modes and workflows. A
comparison that treats all Kong deployments as database polling, or all Kong
deployments as DB-less, misses the choices Kong operators actually make.
-- **Route matching**: APISIX uses a radix tree-based routing algorithm. Kong
uses a different matching approach. The routing algorithm affects lookup time
as the number of routes grows.
-- **Configuration propagation**: APISIX pushes configuration changes from etcd
to all nodes in real time. Kong's DB-mode polls the database on a configurable
interval, introducing a delay between configuration changes and enforcement.
-- **Memory model**: Both use NGINX's event-driven architecture, but their
plugin execution models differ in per-request allocation patterns.
+## Operational Tradeoffs
-We recommend benchmarking both gateways with your actual workload, plugin
chain, and hardware to get meaningful performance comparisons. Vendor-published
benchmarks often test under ideal conditions that may not reflect your
production environment.
+### Configuration dependencies
-For many production deployments, both gateways provide sufficient throughput,
and the choice often depends on factors beyond raw performance such as
ecosystem maturity, plugin availability, and operational familiarity.
+APISIX deployments that use etcd need a properly sized and monitored etcd
cluster, including backup and recovery procedures. Kubernetes uses etcd
internally, but that does not remove the need to design and operate the
configuration store used by APISIX. File-driven standalone avoids this
dependency by making a complete local configuration file authoritative.
API-driven standalone also avoids etcd, but its full-state in-memory update
model is intended for Ingress Controller or ADC integrations.
-## Feature Comparison
+Kong's traditional mode requires operating its database and handling the
supported upgrade and migration workflow. DB-less mode removes that database
dependency from gateway nodes, but configuration is replaced as a complete
declarative document and database-dependent plugin behavior is limited. Hybrid
mode separates control and data planes, while adding control-plane
connectivity, certificate, version-compatibility, and plugin-distribution
considerations.
-| Feature | Apache APISIX | Kong (OSS) |
-|---------|--------------|-------------|
-| Plugin count (built-in) | 80+ | 40+ (OSS), 200+ (Enterprise) |
-| Protocol support | HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, TCP/UDP, MQTT,
Dubbo | HTTP/1.1, HTTP/2, gRPC, WebSocket, TCP/UDP |
-| Dashboard | Apache APISIX Dashboard (OSS) | Kong Manager (Enterprise only) |
-| Admin API | Full REST API, fully dynamic | REST API, DB-mode or DB-less |
-| Service discovery | Nacos, Consul, Eureka, DNS, Kubernetes | DNS, Consul
(others via plugins) |
-| Kubernetes ingress | APISIX Ingress Controller (CRD-based) | Kong Ingress
Controller (KIC) |
-| Multi-language plugin support | Go, Java, Python, Wasm, Lua | Go,
JavaScript, Python (PDK) |
-| Configuration storage | etcd (distributed, real-time) | PostgreSQL (requires
migrations) |
-| Canary/traffic splitting | Built-in traffic-split plugin | Canary plugin
(Enterprise) |
+There is no universal lowest-cost topology. Compare the infrastructure,
recovery objectives, team expertise, configuration workflow, and required
plugin state for the specific mode you intend to run.
-Both gateways support core functionality like rate limiting, authentication
(JWT, OAuth 2.0, API key, LDAP), load balancing, health checks, and circuit
breaking. The primary differences lie in the breadth of built-in features
available in the open-source edition versus features gated behind enterprise
licensing.
+### Configuration propagation
-## Plugin Ecosystem
+APISIX's etcd-backed modes use watch-based updates, while file-driven
standalone uses local file detection. In APISIX Ingress Controller or ADC
integrations that use API-driven standalone, a dedicated API replaces the
in-memory full state. Kong's propagation behavior depends on whether the
deployment is traditional, DB-less, or hybrid. In either product, measure
configuration convergence under failure, rollout, and recovery conditions
instead of relying on an unqualified "instant" claim.
-APISIX ships with over 80 built-in plugins covering authentication, security,
traffic management, observability, and protocol transformation. Notably,
plugins for serverless functions (running custom Lua, Java, or Go code inline)
and advanced traffic management are available in the open-source edition.
+## Plugins and Extensibility
-Kong's open-source edition includes approximately 40 built-in plugins, with a
substantial number of additional plugins available through Kong Plugin Hub and
the enterprise edition. Kong's plugin marketplace includes many third-party and
partner-contributed plugins, giving it a broader ecosystem for specific vendor
integrations like Datadog, PagerDuty, and Moesif.
+Apache APISIX lists [100+ open-source plugins](/plugins/) across traffic
management, authentication, security, observability, transformation, serverless
integration, AI traffic, and other protocols. Native plugins use Lua. APISIX
also supports custom plugins through Java, Python, and Go plugin runners, with
experimental Wasm support. Runner-based plugins introduce a separate process
and communication boundary that teams should include in performance and failure
testing.
-For custom plugin development, APISIX supports external plugins via gRPC-based
plugin runners in Go, Java, and Python, as well as Wasm-based plugins that run
in a sandboxed environment. Kong offers a Plugin Development Kit (PDK)
supporting Go, JavaScript, and Python alongside native Lua plugins. Both
projects accept community-contributed plugins, and their ecosystems continue to
grow.
+Kong's [Plugin Hub](https://developer.konghq.com/plugins/) includes
open-source plugins as well as plugins marked Enterprise-only or
license-required. Because the catalog and packaging change, evaluate the exact
plugins required by your deployment rather than comparing a frozen total. Kong
documents custom plugin development through Lua, Go, Python, and JavaScript
PDKs; installation and availability can differ by deployment topology.
-## Kubernetes Integration
+For both gateways, build a requirement-level plugin matrix that records:
+
+- whether the feature is available in the intended version and distribution;
+- whether it requires external storage or another service;
+- whether it works in the selected control-plane/data-plane topology;
+- how configuration, upgrades, and rollback are handled;
+- what latency and failure behavior it adds to your actual request path.
+
+## Protocol Support
+
+APISIX supports HTTP and HTTPS routing, stream proxying for TCP and UDP,
WebSocket, and gRPC proxying. Specific plugins add capabilities such as
gRPC-Web handling and HTTP-to-gRPC transcoding. Other protocol plugins have
narrower scopes; for example, `mqtt-proxy` performs MQTT load balancing in
stream mode rather than general MQTT-to-HTTP transformation.
-Both gateways offer mature Kubernetes ingress controllers, though they differ
in design philosophy.
+Kong documents native routing for HTTP/HTTPS, TCP/TLS, and gRPC/GRPCS.
[WebSocket
traffic](https://developer.konghq.com/gateway/traffic-control/proxying/) can
use regular HTTP(S) Services and Routes, or dedicated WS(S) Services and Routes
when message-level WebSocket plugin processing is required. Additional behavior
depends on installed plugins and the selected distribution.
+
+Protocol names alone do not prove that one gateway can replace an application
adapter. Verify the exact direction of translation, supported message format,
streaming behavior, authentication path, and plugin compatibility required by
the workload.
+
+## Kubernetes Integration
-The **APISIX Ingress Controller** supports both custom resource definitions
(CRDs) specific to APISIX and standard Kubernetes Ingress resources. It
communicates with the APISIX data plane through the Admin API and supports
Gateway API, the emerging Kubernetes standard for traffic management.
Configuration changes propagate instantly through etcd.
+The [APISIX Ingress Controller](/docs/ingress-controller/overview/) translates
supported Kubernetes Ingress, Gateway API, and APISIX custom resources into
APISIX configuration. Gateway API support varies by resource and field, so use
the [current support matrix](/docs/ingress-controller/concepts/gateway-api/)
when planning a deployment.
-The **Kong Ingress Controller (KIC)** also supports CRDs and standard
Kubernetes Ingress resources, with Kong-specific annotations for extended
functionality. KIC translates Kubernetes resources into Kong configuration,
applying them through the Admin API. KIC has a longer track record in
production Kubernetes environments and benefits from extensive documentation
and community resources.
+The [Kong Ingress
Controller](https://developer.konghq.com/kubernetes-ingress-controller/)
translates resources such as `Ingress` and `HTTPRoute`, along with Kong custom
resources, into Kong Gateway configuration. Its supported resources and
behavior vary by controller version and deployment model.
-Both controllers are actively maintained and see regular releases aligned with
Kubernetes version updates.
+For a Kubernetes evaluation, compare more than whether each project has a
controller. Test the Gateway API resources and policies you need, failure
handling for invalid configuration, status conditions, upgrade compatibility,
secret handling, and how quickly the controller and data plane converge after a
change.
-## Community and Ecosystem
+## How to Compare Performance
-| Metric | Apache APISIX | Kong |
-|--------|--------------|------|
-| License | Apache 2.0 | Apache 2.0 (OSS) |
-| Governance | Apache Software Foundation | Kong Inc. |
-| First release | 2019 | 2015 |
+Neither project's published benchmark establishes a universal winner. The
[APISIX benchmark](/docs/apisix/benchmark/) and [Kong
benchmark](https://developer.konghq.com/gateway/performance/benchmarks/) use
their own infrastructure, versions, tuning, routes, plugins, and traffic
generators. Results from different test environments are not a valid
head-to-head comparison.
-APISIX benefits from Apache Software Foundation governance, which ensures
vendor-neutral development and community-driven roadmap decisions. Kong
benefits from the backing of Kong Inc., which provides dedicated engineering
resources, enterprise support, and a commercial ecosystem that many large
organizations value.
+Run both gateways in the topology you would operate and keep these variables
equivalent:
-Both projects maintain active community forums, Slack channels, and regular
release cadences. Kong's longer market presence gives it an advantage in terms
of available tutorials, third-party integrations, and consultant familiarity.
+1. CPU, memory, network placement, TLS settings, and worker configuration.
+2. Number and complexity of routes, upstreams, and consumers.
+3. Authentication, rate limiting, logging, tracing, and transformation plugins.
+4. Request and response sizes, keepalive behavior, connection concurrency, and
protocol.
+5. Configuration storage and control-plane topology.
+6. Test duration, warm-up period, error rate, throughput, and latency
percentiles.
-## When to Choose Apache APISIX
+Report P50, P95, and P99 latency together with throughput and errors. A
gateway that performs well with no plugins may behave differently with the
policy chain required in production.
-APISIX is the stronger choice when your requirements include:
+## Migration Considerations
-- **Dynamic configuration at scale:** Environments where routes and plugins
change frequently benefit from etcd-based instant propagation without restarts.
-- **Maximum open-source functionality:** Teams that need advanced features
like traffic splitting and multi-protocol support without enterprise licensing.
-- **High-performance requirements:** Workloads where per-request latency and
single-core throughput directly impact infrastructure costs.
-- **Kubernetes-native deployments:** Organizations adopting Gateway API and
wanting tight integration with cloud-native service discovery (Nacos, Consul,
Eureka).
-- **Vendor-neutral governance:** Teams that prefer Apache Software Foundation
stewardship over single-vendor control.
+A migration from Kong to APISIX is a configuration and behavior migration, not
a direct file conversion. Similar concepts often exist on both sides, but their
schemas, matching rules, plugin phases, credentials, and state models differ.
-## When to Choose Kong
+Use a staged process:
-Kong is the stronger choice when your requirements include:
+1. Inventory Kong Services, Routes, Consumers, credentials, plugins,
certificates, and deployment topology.
+2. Map each item to APISIX Routes, Services, Upstreams, Consumers,
credentials, SSL resources, and plugins.
+3. Identify plugins without equivalent behavior and design replacements before
moving traffic.
+4. Reproduce routing precedence, path handling, retries, timeouts, health
checks, and observability in a test environment.
+5. Run both gateways in parallel and shift selected traffic gradually using an
upstream load balancer, DNS, or another controlled entry point.
+6. Compare responses, logs, metrics, traces, and failure behavior, and keep a
tested rollback path.
-- **Mature enterprise ecosystem:** Organizations that need commercial support,
SLA guarantees, and a proven enterprise deployment track record.
-- **Extensive third-party integrations:** Environments with specific vendor
integration needs covered by Kong's plugin marketplace.
-- **Existing Kong investment:** Teams already running Kong in production where
migration cost outweighs technical advantages.
-- **Managed control plane:** Organizations that prefer a SaaS-managed control
plane (Kong Konnect) to reduce operational burden.
-- **Broad hiring market:** Teams that can more easily find engineers with Kong
experience due to its longer market presence.
+Parallel operation and gradual traffic shifting can reduce migration risk, but
they do not guarantee zero downtime. The outcome depends on the surrounding
architecture, stateful plugins, change controls, and rollback design.
-## FAQ
+## When APISIX May Be a Better Fit
-### Can APISIX and Kong run side by side during a migration?
+Consider Apache APISIX when:
-Yes. Both gateways can operate in parallel by splitting traffic at the load
balancer level. A common migration strategy routes new services through APISIX
while existing services continue running through Kong. Gradual traffic shifting
with health checks ensures zero-downtime migration. The timeline depends on the
number of routes, custom plugins, and testing requirements.
+- you want an Apache-governed open-source gateway with a large open-source
plugin catalog;
+- etcd-backed dynamic configuration fits your operating model, or file-driven
standalone matches your declarative workflow;
+- you need a specific APISIX plugin, external plugin runner, or documented
protocol capability;
+- the APISIX Ingress Controller supports the Kubernetes and Gateway API
resources your platform uses.
-### Is APISIX harder to operate because it requires etcd?
+## When Kong May Be a Better Fit
-etcd adds a dependency compared to Kong's DB-less mode, but in practice, etcd
is a well-understood, battle-tested component already present in most
Kubernetes clusters (it is the backing store for Kubernetes itself). Operating
etcd requires standard distributed systems practices: run an odd number of
nodes (3 or 5), monitor disk latency, and maintain regular snapshots. For teams
already running Kubernetes, etcd operational knowledge is typically already
available. The operational cost of [...]
+Consider Kong when:
-### How do the two gateways compare on gRPC and streaming support?
+- your organization already operates Kong configuration, plugins, and
deployment tooling;
+- a specific Kong plugin or integration is available in the distribution you
plan to use;
+- Kong's traditional, DB-less, or hybrid topology matches your configuration
and control-plane requirements;
+- you want Kong's commercial support or managed-service options and have
evaluated their licensing and operational model.
-APISIX provides native gRPC proxying, gRPC-Web transcoding, and HTTP-to-gRPC
transformation out of the box, along with support for HTTP/3 (QUIC), Dubbo, and
MQTT protocols. Kong supports gRPC proxying and gRPC-Web through plugins, with
HTTP/2 support on both client and upstream connections. For teams heavily
invested in gRPC or multi-protocol architectures, APISIX's broader built-in
protocol support reduces the need for custom plugins or sidecars.
+## Make the Decision with Your Own Requirements
-## Related
+Start with the deployment topology and policy chain you will actually operate.
Build a short proof of concept for both gateways, test configuration recovery
as well as request traffic, and verify every required plugin against the
intended version and distribution. The better choice is the one that meets
those requirements with acceptable operational complexity, not the one with the
longest feature table.
-- [All API gateway comparisons](/comparisons/)
-- [What is an API gateway?](/learning-center/what-is-an-api-gateway/)
-- [Apache APISIX vs NGINX](/learning-center/apisix-vs-nginx/)
-- [Apache APISIX vs AWS API
Gateway](/learning-center/apisix-vs-aws-api-gateway/)
-- [Get started with Apache APISIX](/docs/apisix/getting-started/)
+You can review the [full set of API gateway comparisons](/comparisons/) or
[learn how an API gateway works](/learning-center/what-is-an-api-gateway/)
before building a test plan.
diff --git a/website/learning-center/apisix-vs-traefik.md
b/website/learning-center/apisix-vs-traefik.md
index ff4c1b279a1..2dedec97ecc 100644
--- a/website/learning-center/apisix-vs-traefik.md
+++ b/website/learning-center/apisix-vs-traefik.md
@@ -1,103 +1,123 @@
---
-title: "Apache APISIX vs Traefik: Performance vs Auto-Discovery"
-description: "Compare Apache APISIX and Traefik: APISIX for higher throughput
and a larger plugin ecosystem, Traefik for container-native auto-discovery and
TLS."
+title: "Apache APISIX vs Traefik: Architecture, Routing, and Kubernetes"
+description: "Compare Apache APISIX and Traefik Proxy across configuration,
service discovery, Kubernetes, Gateway API, extensibility, TLS, and performance
testing."
slug: apisix-vs-traefik
date: 2026-06-24
tags: [comparison, apisix, traefik, api-gateway]
hide_table_of_contents: false
faq:
- - q: "Is Traefik easier to set up than Apache APISIX?"
+ - q: "Can Apache APISIX read Docker labels the way Traefik does?"
a: >-
- Traefik is known for fast setup in container environments because it
auto-discovers services from Docker labels or Kubernetes resources and
configures itself, with automatic HTTPS through Let's Encrypt. For a small
containerized setup this is very convenient. APISIX requires defining routes
and upstreams explicitly, but provides more control and a richer feature set in
return. For simple auto-wired deployments Traefik feels lighter; for
feature-rich gateways APISIX's explicit model [...]
- - q: "How do Apache APISIX and Traefik compare on performance?"
+ No. Traefik can build dynamic routing configuration from Docker labels
through its provider model. APISIX uses explicit gateway configuration,
Kubernetes resources translated by APISIX Ingress Controller, or supported
service discovery integrations. Teams should choose based on where routing
intent should live and how it should be reviewed and promoted.
+ - q: "Does Traefik's built-in ACME issue certificates for Gateway API
listeners?"
a: >-
- APISIX is built on NGINX and LuaJIT, while Traefik is written in Go.
APISIX generally achieves higher single-node throughput and lower, more
predictable latency, which matters most at high request volumes where
per-request overhead compounds. Traefik performs well for many workloads, but
teams prioritizing maximum throughput and a low latency floor tend to favor
APISIX. As always, benchmark with your own workload and hardware.
- - q: "Which has a larger plugin ecosystem, Apache APISIX or Traefik?"
+ Not in the current Traefik documentation. Traefik recommends using a
certificate controller such as cert-manager for Gateway API listeners. Verify
this behavior against the exact Traefik release you plan to deploy because
certificate support can change between versions.
+ - q: "Can Apache APISIX and Traefik run in the same architecture?"
a: >-
- APISIX ships with 100+ built-in plugins and supports custom plugins in
Lua, Go, Java, Python, and Wasm. Traefik uses middlewares for cross-cutting
concerns and supports plugins through a Go interpreter and Wasm, with a smaller
catalog. Teams needing a broad set of ready-made capabilities, including AI
gateway features, generally find more available in APISIX out of the box.
- - q: "Do both Apache APISIX and Traefik support Kubernetes and the Gateway
API?"
- a: >-
- Yes. Both run as Kubernetes ingress controllers and both support the
Kubernetes Gateway API. Traefik is known for automatically discovering
Kubernetes services and configuring routes from annotations and CRDs. APISIX
provides its own ingress controller with CRDs, standard Ingress support, and
Gateway API support, with configuration propagated through etcd in real time.
+ Yes, when each gateway has a distinct traffic boundary or
responsibility, such as during a migration or for separate application
platforms. Avoid configuring both layers to own the same routing, retry, TLS,
or authentication policy, and measure the operational cost and latency of the
additional hop.
---
-Apache APISIX and Traefik are both modern, cloud-native gateways, but they
optimize for different things. APISIX prioritizes raw performance and a broad,
ready-to-use feature set. Traefik prioritizes developer experience through
automatic service discovery and configuration. For most production API
workloads — where throughput, feature breadth, and predictable, auditable
configuration matter — APISIX is the stronger choice; Traefik is most
compelling for container-native setups that valu [...]
+Apache APISIX and Traefik Proxy are open-source gateways that can route
traffic in Kubernetes and other environments. They differ most in how teams
define and distribute configuration. Traefik emphasizes provider-driven
discovery, while APISIX combines explicit gateway resources with multiple
deployment and service discovery options.
+
+This comparison covers the open-source projects. Traefik Hub and Traefik
Enterprise have additional commercial capabilities that are outside this
article's scope.
+
+## Quick comparison
+
+| Area | Apache APISIX | Traefik Proxy |
+| --- | --- | --- |
+| Primary focus | API gateway with traffic management, security,
observability, and protocol plugins | Application proxy and load balancer with
provider-driven routing |
+| Routing model | Explicit Routes, Upstreams, Services, Consumers, and Plugins
| Routers, Services, and Middlewares generated from providers or files |
+| Configuration storage | etcd in traditional and decoupled modes; YAML or
JSON in standalone mode | Install configuration plus dynamic routing
configuration from providers or files |
+| Service discovery | DNS, Kubernetes, Consul, Nacos, Eureka, and other
integrations | Docker, Kubernetes, Consul Catalog, ECS, file, KV, and other
providers |
+| Extensibility | 100+ open-source plugins; Lua plugins and external plugin
runners | Built-in middlewares plus Yaegi and WebAssembly plugins |
+| Kubernetes | Ingress, APISIX custom resources, and Gateway API through
APISIX Ingress Controller | Ingress, Traefik custom resources, and Gateway API
through Kubernetes providers |
+| TLS automation | TLS resources and certificate integrations depend on the
deployment | Built-in ACME for supported routing configurations; external
certificate controllers can also be used |
+| License | Apache License 2.0 | MIT License |
+
+## Architecture and configuration
+
+Apache APISIX separates its data plane from configuration management. In
traditional and decoupled deployment modes, APISIX stores configuration in etcd
and distributes changes to gateway instances. [Standalone
mode](https://apisix.apache.org/docs/apisix/deployment-modes/) instead loads
declarative YAML or JSON without requiring etcd. Teams model gateway behavior
explicitly through Routes, Upstreams, Services, Consumers, and Plugins.
+
+Traefik separates installation configuration from dynamic routing
configuration. Its
[providers](https://doc.traefik.io/traefik/reference/install-configuration/providers/overview/)
watch sources such as Docker, Kubernetes, Consul Catalog, files, or key-value
stores and update routers, services, and middlewares when the source changes.
This can reduce separate gateway configuration in provider-centric
environments, but teams still need review and ownership rules for labels,
annotations, c [...]
+
+The practical choice is therefore not "automatic" versus "manual." It is where
your team wants routing intent to live and how that intent should be reviewed,
promoted, and audited.
+
+## Service discovery and dynamic environments
-## Overview
+Traefik's provider model is a natural fit when routing should follow Docker
labels or Kubernetes resources. It can watch those sources and update its
dynamic configuration as workloads change.
-Traefik (Traefik Proxy) is an open-source edge router written in Go. Its
signature feature is automatic configuration: it discovers services from
providers such as Docker labels, Kubernetes resources, and Consul, and wires up
routes without manual definitions. It includes automatic HTTPS through Let's
Encrypt, a dashboard, and middlewares for cross-cutting concerns. Commercial
tiers (Traefik Hub and Traefik Enterprise) add further capabilities.
+APISIX keeps gateway policy in explicit resources while supporting [DNS
discovery](https://apisix.apache.org/docs/apisix/discovery/dns/), [Kubernetes
discovery](https://apisix.apache.org/docs/apisix/discovery/kubernetes/), and
other discovery integrations. In Kubernetes, APISIX Ingress Controller
translates Ingress, Gateway API, and APISIX custom resources into APISIX
configuration.
-Apache APISIX is an Apache Software Foundation top-level project built on
NGINX and LuaJIT, with configuration stored in etcd and a 100+ plugin
ecosystem. It targets high throughput, low latency, broad protocol support, and
rich gateway features, configured explicitly through an Admin API, declarative
YAML, or a dashboard.
+During a proof of concept, test how each model handles deleted services, stale
endpoints, configuration rollback, and changes made outside your normal
deployment process.
-## Architecture Comparison
+## Kubernetes and Gateway API
-### Apache APISIX Architecture
+Both projects can serve as Kubernetes ingress and Gateway API implementations.
Support is release-specific, so a simple "Gateway API supported" checkbox is
not enough.
-APISIX uses NGINX's event-driven data plane with Lua plugins and stores
configuration in etcd, which propagates changes to all nodes in real time.
Routes, upstreams, and plugins are defined explicitly, which gives precise
control over behavior. The architecture is tuned for high single-node
throughput and predictable latency, and it supports a wide range of protocols
beyond HTTP.
+For APISIX, review the [Gateway API support
matrix](https://apisix.apache.org/docs/ingress-controller/concepts/gateway-api/)
for the resource kinds, filters, and features your workloads require. For
Traefik, review its current [Kubernetes Gateway provider
documentation](https://doc.traefik.io/traefik/reference/install-configuration/providers/kubernetes/kubernetes-gateway/)
and conformance information.
-### Traefik Architecture
+Validate the exact release you plan to deploy, especially if you depend on
extended filters, TCP or UDP routes, cross-namespace references, or
experimental Gateway API resources.
-Traefik is built around providers and dynamic discovery. Instead of defining
routes by hand, you label your containers or annotate your Kubernetes
resources, and Traefik builds its routing table automatically and keeps it in
sync as services come and go. This is excellent for fast-moving container
environments. Being written in Go, Traefik benefits from a simple deployment
model (a single binary) but generally trades some raw throughput compared to an
OpenResty-based data plane.
+## Extensibility and gateway policies
-## Performance
+Apache APISIX provides more than 100 open-source plugins for authentication,
authorization, traffic control, observability, transformations, and upstream
integration. Custom logic can be implemented in Lua, while [external plugin
runners](https://apisix.apache.org/docs/apisix/external-plugin/) support
selected non-Lua languages through separate runner processes.
-Performance is a frequent reason teams choose APISIX. Its NGINX and LuaJIT
foundation and radix-tree route matching deliver high throughput and low
per-request overhead, which becomes important at scale where small overheads
multiply into real infrastructure cost. Traefik is fast enough for a large
share of workloads, but Go's runtime characteristics typically place its peak
throughput below an OpenResty-based gateway. For latency-sensitive or very
high-volume APIs, APISIX usually has th [...]
+Traefik composes routing behavior with built-in middlewares and supports
community plugins. Its plugin system supports Go plugins interpreted with Yaegi
and plugins compiled to WebAssembly. Review plugin maintenance, compatibility,
execution model, and operational ownership rather than comparing catalog size
alone.
-## Developer Experience and Configuration
+For either gateway, test the complete policy chain you intend to run. A
gateway with no plugins or middlewares enabled does not represent the latency,
memory use, or failure behavior of a production configuration.
-Traefik's strength is auto-discovery: a developer can deploy a container with
a few labels and have it routed and served over HTTPS automatically, with
minimal gateway knowledge. In container-heavy environments this is genuinely
convenient, but it is a tradeoff — implicit, label-driven configuration is
harder to audit, and behavior can shift as labels change.
+## TLS and certificate operations
-APISIX favors explicit configuration. Routes and plugins are declared
deliberately, which is more setup up front but yields fine-grained control,
clearer auditability, and behavior that does not change implicitly as labels
change. APISIX also supports service discovery integrations (Nacos, Consul,
Eureka, Kubernetes), narrowing the gap for dynamic environments while keeping
configuration explicit.
+Traefik includes ACME certificate resolution for supported routing
configurations. That can simplify certificate issuance when its resolver,
challenge, DNS, and storage requirements match the environment. However,
Traefik's built-in ACME resolver does not issue certificates for Gateway API
listeners; its [Kubernetes setup
documentation](https://doc.traefik.io/traefik/setup/kubernetes/#gateway-api--acme)
recommends a certificate controller such as cert-manager for that case.
-## Feature Comparison
+APISIX represents certificates through [SSL
resources](https://apisix.apache.org/docs/apisix/certificate/) and can consume
certificates managed by the surrounding platform. In Kubernetes deployments,
certificate lifecycle automation is commonly handled by a controller and
referenced by ingress or gateway resources.
-| Feature | Apache APISIX | Traefik |
-|---------|--------------|---------|
-| Implementation | NGINX + LuaJIT | Go |
-| Configuration style | Explicit (Admin API, YAML) | Auto-discovery from
providers |
-| Plugin ecosystem | 100+ built-in plugins | Middlewares + Go/Wasm plugins |
-| Protocol support | HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, TCP/UDP, MQTT,
Dubbo | HTTP/1.1, HTTP/2, HTTP/3, gRPC, TCP/UDP |
-| Automatic TLS | Via plugins / cert management | Built-in Let's Encrypt
(ACME) |
-| Service discovery | Nacos, Consul, Eureka, DNS, Kubernetes | Docker,
Kubernetes, Consul, others |
-| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | Not built in |
-| Kubernetes / Gateway API | Ingress controller + Gateway API | Ingress
controller + Gateway API |
-| License | Apache 2.0 | MIT |
+Compare renewal behavior, secret storage, multi-instance coordination, failure
recovery, and Gateway API integration instead of treating "automatic TLS" as a
single feature.
-## When to Choose Apache APISIX
+## Performance: test the workload, not the implementation language
-- **High throughput and low latency** are priorities, especially at scale.
-- **A broad, built-in feature set** including advanced traffic management and
AI gateway capabilities.
-- **Multi-protocol support** beyond HTTP (gRPC, MQTT, Dubbo, TCP/UDP).
-- **Explicit, auditable configuration** with real-time dynamic updates.
+APISIX uses NGINX and LuaJIT, while Traefik is implemented in Go. That
architectural difference alone does not establish which gateway will be faster
for a specific workload.
-## When to Choose Traefik
+A useful comparison keeps these conditions equivalent:
-- **Container-native auto-discovery** with minimal manual configuration.
-- **Automatic HTTPS** through built-in Let's Encrypt integration.
-- **Docker and Kubernetes label-driven** workflows where convention beats
configuration.
-- **A simple single-binary Go deployment** for small to moderate workloads.
+- gateway version, CPU and memory limits, and instance count;
+- HTTP, HTTPS, HTTP/2, HTTP/3, gRPC, TCP, or UDP protocol settings;
+- route count and matching complexity;
+- enabled plugins, middlewares, authentication, and rate limits;
+- TLS termination, connection reuse, and upstream latency;
+- access logs, metrics, tracing, and sampling settings;
+- concurrency, payload size, test duration, and configuration changes during
the test.
-## FAQ
+Measure throughput, p50 and tail latency, CPU, memory, error rate, and
recovery during upstream or configuration changes. Published project benchmarks
can help design a test, but results from different environments should not be
used as a direct head-to-head comparison.
-### Is Traefik easier to set up than Apache APISIX?
+## When to evaluate Apache APISIX
-Traefik is known for fast setup in container environments because it
auto-discovers services from Docker labels or Kubernetes resources and
configures itself, with automatic HTTPS through Let's Encrypt. For a small
containerized setup this is very convenient. APISIX requires defining routes
and upstreams explicitly, but provides more control and a richer feature set in
return. For simple auto-wired deployments Traefik feels lighter; for
feature-rich gateways APISIX's explicit model pays off.
+Apache APISIX is a strong candidate when you need:
-### How do Apache APISIX and Traefik compare on performance?
+- a broad set of gateway policies available as open-source plugins;
+- explicit Routes, Upstreams, Consumers, and reusable plugin configuration;
+- deployment choices that include etcd-backed and standalone configuration;
+- service discovery integrations alongside API gateway policy;
+- Apache Software Foundation governance and an Apache 2.0-licensed project.
-APISIX is built on NGINX and LuaJIT, while Traefik is written in Go. APISIX
generally achieves higher single-node throughput and lower, more predictable
latency, which matters most at high request volumes where per-request overhead
compounds. Traefik performs well for many workloads, but teams prioritizing
maximum throughput and a low latency floor tend to favor APISIX. As always,
benchmark with your own workload and hardware.
+See [what an API gateway does](/learning-center/what-is-an-api-gateway/) and
compare APISIX with other projects in the [open-source API gateway
comparison](/learning-center/open-source-api-gateway-comparison/).
-### Which has a larger plugin ecosystem, Apache APISIX or Traefik?
+## When to evaluate Traefik
-APISIX ships with 100+ built-in plugins and supports custom plugins in Lua,
Go, Java, Python, and Wasm. Traefik uses middlewares for cross-cutting concerns
and supports plugins through a Go interpreter and Wasm, with a smaller catalog.
Teams needing a broad set of ready-made capabilities, including AI gateway
features, generally find more available in APISIX out of the box.
+Traefik Proxy is a strong candidate when you need:
-### Do both Apache APISIX and Traefik support Kubernetes and the Gateway API?
+- routing configuration derived directly from Docker or Kubernetes providers;
+- built-in ACME certificate resolution for supported routing configurations;
+- a single Go binary with provider-based dynamic configuration;
+- Traefik routers, services, and middlewares as the team's preferred operating
model.
-Yes. Both run as Kubernetes ingress controllers and both support the
Kubernetes Gateway API. Traefik is known for automatically discovering
Kubernetes services and configuring routes from annotations and CRDs. APISIX
provides its own ingress controller with CRDs, standard Ingress support, and
Gateway API support, with configuration propagated through etcd in real time.
+## Proof-of-concept checklist
-## Related
+Before choosing either gateway, run the same representative workload and
verify:
-- [All API gateway comparisons](/comparisons/)
-- [What is an API gateway?](/learning-center/what-is-an-api-gateway/)
-- [Apache APISIX vs NGINX](/learning-center/apisix-vs-nginx/)
-- [Apache APISIX vs Envoy](/learning-center/apisix-vs-envoy/)
-- [Get started with Apache APISIX](/docs/apisix/getting-started/)
+1. Required protocols, Gateway API resources, and routing filters.
+2. Authentication, rate limiting, transformations, retries, and observability
policies.
+3. Configuration review, rollout, rollback, and disaster recovery.
+4. Certificate issuance, rotation, and multi-instance behavior.
+5. Throughput, tail latency, resource use, and failure recovery under
realistic load.
+6. Upgrade procedures and compatibility for required plugins or middlewares.
diff --git a/website/src/pages/comparisons.tsx
b/website/src/pages/comparisons.tsx
index 0ee8b153c35..2794c08ddf8 100644
--- a/website/src/pages/comparisons.tsx
+++ b/website/src/pages/comparisons.tsx
@@ -17,7 +17,7 @@ const COMPARISONS: Comparison[] = [
{
title: 'Apache APISIX vs Kong',
description:
- 'Architecture, performance benchmarks, plugin ecosystem, Kubernetes
support, and when to choose each.',
+ 'Deployment topology, configuration, plugins, Kubernetes integration,
performance testing, and migration tradeoffs.',
to: '/learning-center/apisix-vs-kong/',
},
{
@@ -41,7 +41,7 @@ const COMPARISONS: Comparison[] = [
{
title: 'Apache APISIX vs Traefik',
description:
- 'Throughput and plugin breadth vs container-native auto-discovery and
automatic TLS.',
+ 'Configuration models, service discovery, Kubernetes support,
extensibility, and operational tradeoffs.',
to: '/learning-center/apisix-vs-traefik/',
},
{
diff --git a/website/static/llms.txt b/website/static/llms.txt
index 95261273ac5..d077e3379c4 100644
--- a/website/static/llms.txt
+++ b/website/static/llms.txt
@@ -70,11 +70,11 @@
- [What is gRPC? Protocol Buffers, Performance & API Gateway
Integration](https://apisix.apache.org/learning-center/what-is-grpc/): gRPC
basics and gateway integration
- [What is Mutual TLS (mTLS)? How Two-Way Authentication
Works](https://apisix.apache.org/learning-center/what-is-mutual-tls/): mTLS and
zero-trust security
- [API Gateway Security: Threats, Best Practices &
Implementation](https://apisix.apache.org/learning-center/api-gateway-security/):
API security, WAF, rate limiting, zero trust
-- [Apache APISIX vs Kong: Feature Comparison & Performance
Benchmarks](https://apisix.apache.org/learning-center/apisix-vs-kong/): APISIX
vs Kong comparison
+- [Apache APISIX vs Kong: Architecture, Features, and
Tradeoffs](https://apisix.apache.org/learning-center/apisix-vs-kong/): Compare
deployment topology, configuration, plugins, Kubernetes integration,
performance testing, and migration tradeoffs
- [Apache APISIX vs AISIX: General-Purpose vs AI-Native
Gateway](https://apisix.apache.org/learning-center/apisix-vs-aisix/):
General-purpose API and AI gateway vs a dedicated AI-native gateway
- [Apache APISIX vs AWS API Gateway: Self-Hosted vs
Managed](https://apisix.apache.org/learning-center/apisix-vs-aws-api-gateway/):
Open-source self-hosted gateway vs managed cloud service, cost at scale, lock-in
- [Apache APISIX vs NGINX: API Gateway vs Reverse
Proxy](https://apisix.apache.org/learning-center/apisix-vs-nginx/): How APISIX
builds a full API gateway on top of NGINX; NGINX Plus comparison
- [Apache APISIX vs Envoy: API Gateway vs Service
Proxy](https://apisix.apache.org/learning-center/apisix-vs-envoy/): Turnkey
gateway vs a proxy that needs a separate control plane; service mesh
-- [Apache APISIX vs Traefik: Performance vs
Auto-Discovery](https://apisix.apache.org/learning-center/apisix-vs-traefik/):
Throughput and plugin breadth vs container-native auto-discovery and automatic
TLS
+- [Apache APISIX vs Traefik: Architecture, Routing, and
Kubernetes](https://apisix.apache.org/learning-center/apisix-vs-traefik/):
Configuration, service discovery, Kubernetes, extensibility, and performance
testing
- [Apache APISIX vs Apigee: Open-Source Gateway vs API Management
Platform](https://apisix.apache.org/learning-center/apisix-vs-apigee/):
Open-source gateway vs full enterprise API management platform, scope and cost
- [MCP Protocol & AI Gateways: Managing AI Agent Traffic at
Scale](https://apisix.apache.org/learning-center/mcp-protocol-ai-gateway/): MCP
and AI gateway architecture
