This is an automated email from the ASF dual-hosted git repository.
guoqqqi 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 1521618130a feat(seo): add 5 head-to-head API gateway comparison
articles (AWS, NGINX, Envoy, Traefik, Apigee) (#2059)
1521618130a is described below
commit 1521618130a294e3b91cf93d70737e3b24845037
Author: Ming Wen <[email protected]>
AuthorDate: Thu Jun 25 11:26:38 2026 +0800
feat(seo): add 5 head-to-head API gateway comparison articles (AWS, NGINX,
Envoy, Traefik, Apigee) (#2059)
---
website/learning-center/apisix-vs-apigee.md | 108 +++++++++++++++++++
.../learning-center/apisix-vs-aws-api-gateway.md | 114 +++++++++++++++++++++
website/learning-center/apisix-vs-envoy.md | 103 +++++++++++++++++++
website/learning-center/apisix-vs-kong.md | 13 +++
website/learning-center/apisix-vs-nginx.md | 99 ++++++++++++++++++
website/learning-center/apisix-vs-traefik.md | 103 +++++++++++++++++++
website/src/pages/comparisons.tsx | 30 ++++++
website/static/llms.txt | 34 +++---
8 files changed, 592 insertions(+), 12 deletions(-)
diff --git a/website/learning-center/apisix-vs-apigee.md
b/website/learning-center/apisix-vs-apigee.md
new file mode 100644
index 00000000000..c16e70421ce
--- /dev/null
+++ b/website/learning-center/apisix-vs-apigee.md
@@ -0,0 +1,108 @@
+---
+title: "Apache APISIX vs Apigee: Gateway vs API Management Platform"
+description: "Compare Apache APISIX and Google Cloud Apigee: an open-source
API gateway vs a full enterprise API management platform — scope, cost, and
portability."
+slug: apisix-vs-apigee
+date: 2026-06-24
+tags: [comparison, apisix, apigee, api-gateway]
+hide_table_of_contents: false
+faq:
+ - q: "Is Apache APISIX a full API management platform like Apigee?"
+ a: >-
+ Not on its own. APISIX is a high-performance API gateway focused on the
runtime: routing, authentication, rate limiting, traffic management,
observability, and AI gateway features. Apigee is a broader API management
platform that also includes a developer portal, deep API analytics,
monetization, and lifecycle governance. To build a full API management program
around APISIX, you pair it with complementary tooling for those higher-level
functions.
+ - q: "How do the costs of Apache APISIX and Apigee compare?"
+ a: >-
+ APISIX is free and open source under the Apache 2.0 license; your cost
is the infrastructure you run it on. Apigee is a commercial enterprise platform
with pricing based on API calls and capabilities, which can be substantial at
scale. Organizations focused primarily on gateway functionality often find
APISIX far more cost-effective, while those needing Apigee's full management
suite weigh that against its platform cost.
+ - q: "Does Apache APISIX offer a developer portal and analytics like Apigee?"
+ a: >-
+ APISIX provides strong runtime observability through integrations with
Prometheus, OpenTelemetry, Datadog, SkyWalking, and others, but the open-source
project does not bundle a polished developer portal, business-level API
analytics, or monetization the way Apigee does. Teams that need those
capabilities integrate additional tools alongside APISIX, whereas Apigee
delivers them as part of one platform.
+ - q: "How do I migrate from Apigee to Apache APISIX?"
+ a: >-
+ Migration usually starts with the gateway runtime: map Apigee API
proxies to APISIX routes and upstreams, and translate Apigee policies (for
authentication, quotas, spike arrest, and transformation) to the equivalent
APISIX plugins. Higher-level Apigee features such as the developer portal and
monetization are addressed separately with complementary tooling. Running both
in parallel and shifting traffic incrementally allows a controlled, low-risk
migration.
+---
+
+Apache APISIX and Apigee are often compared, but they sit at different layers.
APISIX is a high-performance, open-source API gateway focused on moving and
governing traffic. Apigee is a comprehensive, commercial API management
platform that includes a gateway plus the surrounding business and lifecycle
tooling. For the gateway layer itself — performance, cost, and portability —
APISIX is the stronger and far more economical choice; Apigee earns its place
only when you genuinely need the [...]
+
+## Overview
+
+Apigee is Google Cloud's enterprise API management platform. Beyond the
gateway runtime, it provides a developer portal, detailed API analytics,
monetization, and full API lifecycle management, with policies configured
through a console and an XML-based policy model. It is offered as Apigee X
(fully managed on Google Cloud) and Apigee hybrid (runtime in your own
Kubernetes, management plane in Google Cloud). It targets large organizations
running formal API programs.
+
+Apache APISIX is an Apache Software Foundation top-level project: a gateway
built on NGINX and LuaJIT, with etcd-backed dynamic configuration and 100+
plugins. It is free, self-hosted, and focused on the data plane, prioritizing
performance, flexibility, and low cost.
+
+## Scope: Gateway vs Platform
+
+The most important distinction is scope.
+
+APISIX is a **gateway**. It excels at routing, authentication, rate limiting,
traffic shaping, protocol support, observability, and AI proxying. It is the
runtime layer that sits in front of your services.
+
+Apigee is a **platform**. It includes a gateway, but its value proposition
extends to the full API business: onboarding external developers through a
portal, analyzing API usage for product decisions, monetizing APIs, and
governing them across their lifecycle.
+
+This means the comparison is rarely feature-for-feature. The real question is
whether you need a focused, high-performance gateway you can run anywhere, or
an end-to-end managed API management suite, and whether you are willing to
trade cost and portability for that breadth.
+
+## Architecture and Deployment
+
+### Apache APISIX
+
+APISIX is self-hosted on any cloud, on-premises, or in Kubernetes. The data
plane and control plane (Admin API plus etcd) deploy together, configuration
changes propagate in real time, and you retain full control over where traffic
flows and what it costs. There is no dependency on a specific cloud provider.
+
+### Apigee
+
+Apigee X is fully managed within Google Cloud, removing operational burden but
coupling you to that environment. Apigee hybrid lets you run the runtime in
your own Kubernetes clusters while the management plane remains in Google
Cloud, offering more deployment flexibility while retaining the platform's
management capabilities and its commercial model.
+
+## Cost
+
+Cost is frequently decisive. APISIX has no license fee; you pay only for the
compute it runs on, and a single node sustains very high throughput, so cost
per request stays low as traffic grows. Apigee is priced as an enterprise
platform, typically based on API call volume and the capabilities you enable,
which can become a major line item at scale. For teams whose primary need is a
capable gateway, APISIX delivers that at a fraction of the platform cost.
+
+## Feature Comparison
+
+| Feature | Apache APISIX | Apigee |
+|---------|--------------|--------|
+| Category | Open-source API gateway | Enterprise API management platform |
+| Deployment | Self-hosted anywhere | Apigee X (managed) or hybrid on Google
Cloud |
+| Cost | Free + infrastructure | Commercial, volume-based |
+| Gateway runtime | NGINX + LuaJIT, 100+ plugins | Managed runtime, XML
policies |
+| Developer portal | Via complementary tooling | Built in |
+| API analytics | Runtime observability (Prometheus, OTel, etc.) | Built-in
business analytics |
+| Monetization | Not built in | Built in |
+| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | Via platform
features |
+| Portability | Runs anywhere, no lock-in | Coupled to Google Cloud |
+| Governance / lifecycle | Gateway-level | Full lifecycle management |
+
+## When to Choose Apache APISIX
+
+- **You need a high-performance gateway**, not a full management platform.
+- **Cost efficiency** matters and per-call platform pricing is unattractive.
+- **Multi-cloud, hybrid, or on-premises** deployment and no vendor lock-in.
+- **Flexibility** to assemble your own management tooling around a focused,
open-source core.
+
+## When to Choose Apigee
+
+- **You need a complete API management program**: developer portal, analytics,
monetization, and lifecycle governance in one product.
+- **A fully managed platform** is preferred and Google Cloud is your
environment.
+- **Enterprise governance** and a polished external developer experience are
priorities.
+- **Budget exists** for an enterprise platform in exchange for that breadth.
+
+## FAQ
+
+### Is Apache APISIX a full API management platform like Apigee?
+
+Not on its own. APISIX is a high-performance API gateway focused on the
runtime: routing, authentication, rate limiting, traffic management,
observability, and AI gateway features. Apigee is a broader API management
platform that also includes a developer portal, deep API analytics,
monetization, and lifecycle governance. To build a full API management program
around APISIX, you pair it with complementary tooling for those higher-level
functions.
+
+### How do the costs of Apache APISIX and Apigee compare?
+
+APISIX is free and open source under the Apache 2.0 license; your cost is the
infrastructure you run it on. Apigee is a commercial enterprise platform with
pricing based on API calls and capabilities, which can be substantial at scale.
Organizations focused primarily on gateway functionality often find APISIX far
more cost-effective, while those needing Apigee's full management suite weigh
that against its platform cost.
+
+### Does Apache APISIX offer a developer portal and analytics like Apigee?
+
+APISIX provides strong runtime observability through integrations with
Prometheus, OpenTelemetry, Datadog, SkyWalking, and others, but the open-source
project does not bundle a polished developer portal, business-level API
analytics, or monetization the way Apigee does. Teams that need those
capabilities integrate additional tools alongside APISIX, whereas Apigee
delivers them as part of one platform.
+
+### How do I migrate from Apigee to Apache APISIX?
+
+Migration usually starts with the gateway runtime: map Apigee API proxies to
APISIX routes and upstreams, and translate Apigee policies (for authentication,
quotas, spike arrest, and transformation) to the equivalent APISIX plugins.
Higher-level Apigee features such as the developer portal and monetization are
addressed separately with complementary tooling. Running both in parallel and
shifting traffic incrementally allows a controlled, low-risk migration.
+
+## Related
+
+- [All API gateway comparisons](/comparisons/)
+- [What is an API gateway?](/learning-center/what-is-an-api-gateway/)
+- [Apache APISIX vs AWS API
Gateway](/learning-center/apisix-vs-aws-api-gateway/)
+- [Apache APISIX vs Kong](/learning-center/apisix-vs-kong/)
+- [Get started with Apache APISIX](/docs/apisix/getting-started/)
diff --git a/website/learning-center/apisix-vs-aws-api-gateway.md
b/website/learning-center/apisix-vs-aws-api-gateway.md
new file mode 100644
index 00000000000..1e5a4af27d4
--- /dev/null
+++ b/website/learning-center/apisix-vs-aws-api-gateway.md
@@ -0,0 +1,114 @@
+---
+title: "Apache APISIX vs AWS API Gateway: Self-Hosted vs Managed"
+description: "Compare Apache APISIX and AWS API Gateway: self-hosted open
source vs a managed cloud service, pricing at scale, vendor lock-in, and
performance."
+slug: apisix-vs-aws-api-gateway
+date: 2026-06-24
+tags: [comparison, apisix, aws-api-gateway, api-gateway]
+hide_table_of_contents: false
+faq:
+ - q: "Is Apache APISIX cheaper than AWS API Gateway?"
+ a: >-
+ It depends on traffic volume. AWS API Gateway charges per request plus
data transfer, so cost scales linearly with traffic and becomes significant at
high volumes. Apache APISIX is free and open source; you pay only for the
compute you run it on, which is a largely fixed cost regardless of request
count. For low or spiky traffic, the managed convenience of AWS API Gateway
often outweighs its per-request cost. For sustained high-volume APIs,
self-hosting APISIX is typically far chea [...]
+ - q: "Can I run Apache APISIX on AWS?"
+ a: >-
+ Yes. APISIX runs anywhere you can run a container or a Linux host,
including EC2, EKS, and ECS. Many teams run APISIX on AWS to keep traffic
inside their VPC while avoiding per-request gateway fees and retaining the
ability to move to another cloud or on-premises later without rewriting their
gateway configuration.
+ - q: "How do I migrate from AWS API Gateway to Apache APISIX?"
+ a: >-
+ The common approach is to stand up APISIX behind the same DNS or load
balancer and shift routes incrementally. Map each API Gateway stage and
resource to an APISIX route and upstream, translate authorizers to APISIX
authentication plugins, and replace VTL mapping templates with request and
response transformation plugins. Shifting traffic route by route with health
checks allows a zero-downtime migration.
+ - q: "Does AWS API Gateway or Apache APISIX add more latency?"
+ a: >-
+ A self-hosted APISIX deployment running close to your backends typically
adds sub-millisecond proxy overhead and avoids extra network hops. AWS API
Gateway is a managed regional service, so requests traverse AWS infrastructure
and are subject to service limits such as integration timeouts. For
latency-sensitive workloads where you control the network path, a self-hosted
gateway gives you more control over the latency floor.
+---
+
+Apache APISIX and AWS API Gateway solve the same problem from opposite
directions. APISIX is a self-hosted, open-source gateway you run on any
infrastructure, while AWS API Gateway is a fully managed, serverless service
tightly integrated with the AWS ecosystem. The choice comes down to control and
cost versus managed convenience and lock-in.
+
+## Overview
+
+AWS API Gateway is a managed service that handles API traffic without any
servers for you to operate. It offers REST APIs, lower-cost HTTP APIs, and
WebSocket APIs, and integrates natively with AWS Lambda, IAM, Cognito,
CloudWatch, and WAF. You configure it through the AWS console, CloudFormation,
or Terraform, and AWS operates and scales the underlying infrastructure.
+
+Apache APISIX is a top-level Apache Software Foundation project: a
high-performance gateway built on NGINX and LuaJIT, with configuration stored
in etcd and pushed to all nodes in real time. You deploy and operate it
yourself, on any cloud, on-premises, or in Kubernetes, with no per-request
platform fees.
+
+## Architecture Comparison
+
+### Apache APISIX Architecture
+
+APISIX runs as a self-hosted data plane with a built-in control plane: an
Admin API, etcd-backed configuration, an optional dashboard, and a 100+ plugin
ecosystem. Because configuration lives in etcd and propagates instantly, routes
and policies change without restarts. You own the full request path, which
means you can deploy APISIX next to your services in any environment and tune
it to your hardware.
+
+### AWS API Gateway Architecture
+
+AWS API Gateway is serverless. There is no instance to size, patch, or scale,
and high availability is handled by AWS within a region. Backends are typically
Lambda functions, HTTP endpoints, or other AWS services, wired through
integrations. The tradeoff is that the data plane is a black box: you configure
behavior through AWS abstractions (stages, resources, authorizers, mapping
templates) rather than operating the proxy directly, and behavior is bounded by
AWS service limits.
+
+## Pricing and Cost at Scale
+
+The pricing models are fundamentally different, and this is often the deciding
factor.
+
+AWS API Gateway charges **per request**, plus data transfer and optional
caching. This is attractive at low volume because you pay nothing when idle,
but cost grows linearly with traffic. At high, sustained request volumes the
per-request fee can dominate the total cost of an API platform.
+
+Apache APISIX has **no per-request fee**. The cost is the compute you run it
on, which is largely fixed regardless of how many requests flow through. A
single modest node handles very high throughput, so cost per request falls as
traffic grows.
+
+A useful rule of thumb: managed per-request pricing favors low or
unpredictable traffic, while self-hosting favors sustained high volume where
fixed infrastructure cost is amortized across many requests.
+
+## Performance and Limits
+
+AWS API Gateway is designed for elasticity rather than minimal latency, and it
enforces hard service limits such as integration timeouts and per-region
request quotas (some of which are soft limits you can request increases for).
These rarely matter for typical workloads but can constrain long-running,
high-throughput, or large-payload APIs.
+
+APISIX is optimized for low, predictable per-request overhead using NGINX's
event-driven model and radix-tree route matching. Running it close to your
backends removes extra network hops. Because you control the deployment, you
can benchmark and tune for your own latency and throughput targets rather than
working within a managed service's quotas.
+
+## Feature Comparison
+
+| Feature | Apache APISIX | AWS API Gateway |
+|---------|--------------|-----------------|
+| Deployment model | Self-hosted (any cloud, on-prem, hybrid, Kubernetes) |
Fully managed, AWS-only |
+| Pricing | Free + infrastructure cost | Per request + data transfer |
+| Configuration | etcd, real-time, fully dynamic | AWS console /
CloudFormation / Terraform |
+| Extensibility | 100+ plugins, multi-language (Go, Java, Python, Wasm, Lua) |
Lambda authorizers, VTL mapping templates |
+| Protocol support | HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, TCP/UDP, MQTT,
Dubbo | REST, HTTP, WebSocket |
+| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | Via Lambda /
Bedrock integrations |
+| Auth | Key, JWT, OAuth 2.0, OIDC, LDAP, mTLS | IAM, Cognito, Lambda
authorizers |
+| Observability | Prometheus, OpenTelemetry, Datadog, SkyWalking, Zipkin |
CloudWatch, X-Ray |
+| Portability | Runs anywhere, no lock-in | Coupled to AWS |
+
+## Vendor Lock-in and Portability
+
+The strongest argument for a self-hosted gateway is portability. AWS API
Gateway configuration, authorizers, and VTL templates are specific to AWS;
moving to another cloud or on-premises means rebuilding the gateway layer.
APISIX configuration is portable: the same routes, plugins, and upstreams run
identically on any cloud, in your own data center, or across a hybrid
deployment. For organizations pursuing multi-cloud strategies, data-residency
requirements, or simply avoiding lock-in, t [...]
+
+## When to Choose Apache APISIX
+
+- **Sustained high traffic** where per-request pricing would dominate cost.
+- **Multi-cloud, hybrid, or on-premises** deployments and data-residency
requirements.
+- **Full control** over the data plane, custom plugins, and the latency floor.
+- **Rich gateway features** (advanced traffic management, multi-protocol, AI
proxy) without a managed service's constraints.
+- **Avoiding vendor lock-in** with a portable, open-source configuration.
+
+## When to Choose AWS API Gateway
+
+- **All-in on AWS** with Lambda or other AWS services as backends.
+- **Low or spiky traffic** where paying per request beats running
infrastructure.
+- **No operational appetite** for running and scaling a gateway yourself.
+- **Tight AWS-native integration** with IAM, Cognito, and CloudWatch as a
priority.
+
+## FAQ
+
+### Is Apache APISIX cheaper than AWS API Gateway?
+
+It depends on traffic volume. AWS API Gateway charges per request plus data
transfer, so cost scales linearly with traffic and becomes significant at high
volumes. Apache APISIX is free and open source; you pay only for the compute
you run it on, which is a largely fixed cost regardless of request count. For
low or spiky traffic, the managed convenience of AWS API Gateway often
outweighs its per-request cost. For sustained high-volume APIs, self-hosting
APISIX is typically far cheaper pe [...]
+
+### Can I run Apache APISIX on AWS?
+
+Yes. APISIX runs anywhere you can run a container or a Linux host, including
EC2, EKS, and ECS. Many teams run APISIX on AWS to keep traffic inside their
VPC while avoiding per-request gateway fees and retaining the ability to move
to another cloud or on-premises later without rewriting their gateway
configuration.
+
+### How do I migrate from AWS API Gateway to Apache APISIX?
+
+The common approach is to stand up APISIX behind the same DNS or load balancer
and shift routes incrementally. Map each API Gateway stage and resource to an
APISIX route and upstream, translate authorizers to APISIX authentication
plugins, and replace VTL mapping templates with request and response
transformation plugins. Shifting traffic route by route with health checks
allows a zero-downtime migration.
+
+### Does AWS API Gateway or Apache APISIX add more latency?
+
+A self-hosted APISIX deployment running close to your backends typically adds
sub-millisecond proxy overhead and avoids extra network hops. AWS API Gateway
is a managed regional service, so requests traverse AWS infrastructure and are
subject to service limits such as integration timeouts. For latency-sensitive
workloads where you control the network path, a self-hosted gateway gives you
more control over the latency floor.
+
+## Related
+
+- [All API gateway comparisons](/comparisons/)
+- [What is an API gateway?](/learning-center/what-is-an-api-gateway/)
+- [Apache APISIX vs Apigee](/learning-center/apisix-vs-apigee/)
+- [Apache APISIX vs Kong](/learning-center/apisix-vs-kong/)
+- [Get started with Apache APISIX](/docs/apisix/getting-started/)
diff --git a/website/learning-center/apisix-vs-envoy.md
b/website/learning-center/apisix-vs-envoy.md
new file mode 100644
index 00000000000..290b5cc9929
--- /dev/null
+++ b/website/learning-center/apisix-vs-envoy.md
@@ -0,0 +1,103 @@
+---
+title: "Apache APISIX vs Envoy: API Gateway vs Service Proxy"
+description: "Compare Apache APISIX and Envoy: a turnkey API gateway with a
built-in control plane vs a high-performance proxy that needs one (Istio,
Gloo)."
+slug: apisix-vs-envoy
+date: 2026-06-24
+tags: [comparison, apisix, envoy, api-gateway]
+hide_table_of_contents: false
+faq:
+ - q: "Are Apache APISIX and Envoy competitors or complementary?"
+ a: >-
+ They overlap but often complement each other. APISIX is most commonly
used as a north-south API gateway for traffic entering your platform from
clients, while Envoy is most commonly used as the east-west data plane inside a
service mesh for service-to-service traffic. Many organizations run APISIX at
the edge and Envoy inside the mesh. They compete directly only when you
evaluate one of them for the edge gateway role.
+ - q: "Is Envoy faster than Apache APISIX?"
+ a: >-
+ Both are high-performance proxies and both are fast enough that raw
proxy speed is rarely the deciding factor. Envoy is written in C++ and APISIX
is built on NGINX and LuaJIT; real-world throughput depends heavily on your
configuration, plugin or filter chain, and hardware. The more meaningful
difference is operational: APISIX gives you a complete gateway out of the box,
whereas Envoy's performance comes with a more complex configuration model.
+ - q: "Does Apache APISIX need a separate control plane like Envoy does?"
+ a: >-
+ No. APISIX ships with its own control plane: an Admin API, etcd-backed
configuration, and an optional dashboard. You can run a working gateway
immediately. Envoy is a data plane only; to configure it dynamically you must
run a separate control plane that speaks the xDS protocol, such as Istio, Gloo,
or Contour. That control plane is additional software to operate.
+ - q: "Should I use Apache APISIX or Envoy for a service mesh?"
+ a: >-
+ For a full service mesh with sidecar proxies and service-to-service
mTLS, Envoy (typically through Istio) is the established choice; it was
designed for that role. For an API gateway handling north-south traffic at the
edge, with authentication, rate limiting, and a plugin ecosystem ready to use,
APISIX is the more direct fit. The two roles are different, and many platforms
use both.
+---
+
+If you need an API gateway, Apache APISIX is the more direct choice. APISIX is
a complete gateway you can run immediately, with a built-in control plane and a
100+ plugin ecosystem. Envoy is a powerful, programmable proxy, but on its own
it is not an API gateway: it is a data plane that has to be driven by a
separate control plane, and it is most at home as the sidecar inside a service
mesh. For the typical north-south API gateway need, APISIX gets you to a
working gateway with far less [...]
+
+## Overview
+
+Envoy is a CNCF graduated project, a high-performance L7 and L4 proxy written
in C++. It was created as a universal data plane and is best known as the
sidecar proxy in service meshes such as Istio, as well as a building block for
edge gateways like Gloo and Contour. Envoy is configured statically through a
bootstrap file or dynamically through the xDS family of APIs, which requires a
control plane to supply that configuration.
+
+Apache APISIX is an Apache Software Foundation top-level project: a gateway
built on NGINX and LuaJIT, with configuration in etcd and a 100+ plugin
ecosystem. It includes its own control plane, so a single deployment gives you
a fully functional API gateway without assembling additional components.
+
+## Architecture Comparison
+
+### Apache APISIX Architecture
+
+APISIX bundles the data plane and control plane together. The Admin API writes
configuration into etcd, which pushes changes to all proxy nodes in real time.
Gateway features are delivered as plugins that run in the request lifecycle,
and an optional dashboard provides a UI. Because the control plane is built in,
getting from zero to a working, dynamically configurable gateway is fast.
+
+### Envoy Architecture
+
+Envoy is intentionally just the data plane. Its power comes from the xDS APIs
(LDS, RDS, CDS, EDS, and others), which let an external control plane
reconfigure listeners, routes, clusters, and endpoints at runtime. This
separation suits large platforms that want to build their own control logic,
and it is the foundation of service meshes. For a team that simply needs an API
gateway, though, it is overhead: Envoy alone is not a turnkey gateway. You
either hand-write verbose bootstrap conf [...]
+
+## Extensibility
+
+APISIX extends through plugins. It ships with 100+ built-in plugins and
supports custom plugins in Lua, plus Go, Java, and Python through external
plugin runners and Wasm for sandboxed extensions. Adding a capability is
usually a matter of enabling and configuring a plugin.
+
+Envoy extends through native C++ filters and Wasm filters, and increasingly
through control-plane abstractions. This is extremely powerful and is how
advanced mesh features are built, but it generally demands deeper engineering
investment than enabling a plugin.
+
+## Feature Comparison
+
+| Feature | Apache APISIX | Envoy |
+|---------|--------------|-------|
+| Primary role | North-south API gateway | Service proxy / mesh data plane |
+| Control plane | Built in (Admin API + etcd) | External required (Istio,
Gloo, etc.) |
+| Configuration | etcd, dynamic, plugin-based | Static bootstrap or xDS |
+| Out-of-the-box gateway | Yes | No (needs a control plane) |
+| Extensibility | 100+ plugins, multi-language, Wasm | C++ and Wasm filters |
+| Implementation | NGINX + LuaJIT | C++ |
+| Authentication | Key, JWT, OAuth 2.0, OIDC, LDAP, mTLS | Via filters /
control plane |
+| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | Via custom
filters |
+| Learning curve | Moderate, gateway concepts | Steeper, proxy and xDS
concepts |
+
+## When to Choose Apache APISIX
+
+- **You need a complete API gateway** for north-south traffic without
assembling a control plane.
+- **Faster time to a working gateway**, with authentication, rate limiting,
and routing ready to enable.
+- **A plugin ecosystem** and AI gateway features available immediately.
+- **Lower operational complexity** for edge and ingress use cases.
+
+## When to Choose Envoy
+
+- **A service mesh** with sidecar proxies and service-to-service mTLS,
typically via Istio.
+- **A custom platform** where you want to build your own control plane on xDS.
+- **Deep, low-level programmability** through native C++ filters.
+- **Standardizing one data plane** across both edge and in-mesh traffic with
your own tooling.
+
+## Working Together
+
+These projects are not mutually exclusive. A common pattern places APISIX at
the edge as the API gateway, handling authentication, rate limiting, and
routing for incoming traffic, while Envoy operates inside the cluster as the
service mesh data plane for service-to-service communication. Choosing APISIX
for the gateway role does not preclude using Envoy where it excels.
+
+## FAQ
+
+### Are Apache APISIX and Envoy competitors or complementary?
+
+They overlap but often complement each other. APISIX is most commonly used as
a north-south API gateway for traffic entering your platform from clients,
while Envoy is most commonly used as the east-west data plane inside a service
mesh for service-to-service traffic. Many organizations run APISIX at the edge
and Envoy inside the mesh. They compete directly only when you evaluate one of
them for the edge gateway role.
+
+### Is Envoy faster than Apache APISIX?
+
+Both are high-performance proxies and both are fast enough that raw proxy
speed is rarely the deciding factor. Envoy is written in C++ and APISIX is
built on NGINX and LuaJIT; real-world throughput depends heavily on your
configuration, plugin or filter chain, and hardware. The more meaningful
difference is operational: APISIX gives you a complete gateway out of the box,
whereas Envoy's performance comes with a more complex configuration model.
+
+### Does Apache APISIX need a separate control plane like Envoy does?
+
+No. APISIX ships with its own control plane: an Admin API, etcd-backed
configuration, and an optional dashboard. You can run a working gateway
immediately. Envoy is a data plane only; to configure it dynamically you must
run a separate control plane that speaks the xDS protocol, such as Istio, Gloo,
or Contour. That control plane is additional software to operate.
+
+### Should I use Apache APISIX or Envoy for a service mesh?
+
+For a full service mesh with sidecar proxies and service-to-service mTLS,
Envoy (typically through Istio) is the established choice; it was designed for
that role. For an API gateway handling north-south traffic at the edge, with
authentication, rate limiting, and a plugin ecosystem ready to use, APISIX is
the more direct fit. The two roles are different, and many platforms use both.
+
+## Related
+
+- [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 Traefik](/learning-center/apisix-vs-traefik/)
+- [Get started with Apache APISIX](/docs/apisix/getting-started/)
diff --git a/website/learning-center/apisix-vs-kong.md
b/website/learning-center/apisix-vs-kong.md
index cea0502eef8..31d19a27788 100644
--- a/website/learning-center/apisix-vs-kong.md
+++ b/website/learning-center/apisix-vs-kong.md
@@ -5,6 +5,19 @@ 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?"
+ 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?"
+ 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: "Which gateway has better AI and LLM support?"
+ a: >-
+ Both gateways are investing in AI gateway capabilities, but they
approach it differently. APISIX provides the ai-proxy plugin in its open-source
edition, supporting multi-model routing, token-based rate limiting, and prompt
transformation for major LLM providers. Kong offers AI Gateway plugins
primarily through its enterprise edition and Konnect platform. For teams
building AI-powered applications on an open-source budget, APISIX currently
provides more built-in AI functionality wi [...]
+ - q: "How do the two gateways compare on gRPC and streaming support?"
+ 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.
---
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.
diff --git a/website/learning-center/apisix-vs-nginx.md
b/website/learning-center/apisix-vs-nginx.md
new file mode 100644
index 00000000000..07fe3ee7984
--- /dev/null
+++ b/website/learning-center/apisix-vs-nginx.md
@@ -0,0 +1,99 @@
+---
+title: "Apache APISIX vs NGINX: API Gateway vs Reverse Proxy"
+description: "Compare Apache APISIX and NGINX as API gateways. APISIX is built
on NGINX but adds dynamic config, 100+ plugins, and an Admin API; NGINX Plus
too."
+slug: apisix-vs-nginx
+date: 2026-06-24
+tags: [comparison, apisix, nginx, api-gateway]
+hide_table_of_contents: false
+faq:
+ - q: "Isn't Apache APISIX just NGINX with extra steps?"
+ a: >-
+ APISIX is built on top of NGINX and LuaJIT (via OpenResty), so it
inherits NGINX's proven performance, but it is not just NGINX. APISIX adds a
full API gateway layer that plain NGINX lacks: dynamic configuration through
etcd with no reloads, an Admin API, a 100+ plugin ecosystem for authentication,
rate limiting, and observability, service discovery, and a dashboard. You get
NGINX's data plane plus a complete control plane out of the box.
+ - q: "Do I need to know NGINX to run Apache APISIX?"
+ a: >-
+ No. APISIX is configured through its Admin API, declarative YAML, or its
dashboard, using high-level concepts like routes, upstreams, services, and
plugins. You do not write or maintain nginx.conf. Familiarity with NGINX
concepts can help with advanced tuning, but day-to-day operation does not
require editing NGINX configuration files.
+ - q: "How does Apache APISIX compare to NGINX Plus?"
+ a: >-
+ NGINX Plus is the commercial edition of NGINX, adding dynamic
reconfiguration, active health checks, JWT authentication, and a dashboard on a
subscription. APISIX provides comparable dynamic configuration, health
checking, and authentication, plus a much larger plugin ecosystem and AI
gateway features, as open-source software under the Apache 2.0 license with no
per-instance fee. Teams evaluating NGINX Plus for gateway features often find
APISIX covers the same needs without licens [...]
+ - q: "Can I migrate my nginx.conf to Apache APISIX?"
+ a: >-
+ Most nginx.conf reverse-proxy setups map cleanly onto APISIX concepts:
server and location blocks become routes, proxy_pass upstreams become APISIX
upstreams, and directives like rate limiting, header rewriting, and access
control become plugins. The main shift is moving from a static file that
requires reloads to dynamic configuration managed through the Admin API, which
removes reload-related downtime.
+---
+
+NGINX is the foundation that powers much of the web as a reverse proxy and
load balancer, and Apache APISIX is built directly on top of it. The real
comparison is not NGINX versus a competitor, but whether to assemble an API
gateway from NGINX yourself versus using a purpose-built gateway that already
provides the gateway layer on the same high-performance core.
+
+## Overview
+
+NGINX (open source) is a web server, reverse proxy, and load balancer. It can
act as an API gateway, but you build that capability yourself through
configuration files and, for advanced logic, the njs scripting module or Lua.
NGINX Plus, the commercial edition, adds dynamic reconfiguration, active health
checks, JWT authentication, and a monitoring dashboard.
+
+Apache APISIX uses NGINX and LuaJIT (through OpenResty) as its data plane,
then adds a complete API gateway on top: etcd-backed dynamic configuration, an
Admin API, 100+ plugins, service discovery, and a dashboard. It is an Apache
Software Foundation top-level project under the Apache 2.0 license.
+
+## Architecture Comparison
+
+### Apache APISIX Architecture
+
+APISIX keeps NGINX's event-driven request handling for raw performance, but
moves configuration out of static files and into etcd. Changes to routes,
upstreams, and plugins propagate to every node in real time, with no reloads.
Cross-cutting concerns are handled by plugins rather than hand-written
configuration, and everything is managed through a REST Admin API. The result
is NGINX-class throughput with the operational model of a modern, dynamic
gateway.
+
+### NGINX Architecture
+
+Plain NGINX stores its configuration in `nginx.conf` and related files.
Applying a change requires a reload, and while reloads are graceful,
configuration is fundamentally static at runtime. API gateway behavior such as
per-consumer rate limiting, token authentication, or request transformation
must be expressed through directives, njs, or Lua modules that you write and
maintain. NGINX Plus relaxes some of these limits with a runtime
reconfiguration API and built-in modules, on a commerc [...]
+
+## Dynamic Configuration
+
+This is the clearest practical difference. With open-source NGINX, adding a
route or changing an upstream means editing configuration and reloading the
process. In dynamic environments, such as Kubernetes with ephemeral pods or
frequent deployments, this static model adds friction.
+
+APISIX treats configuration as live data. Routes and policies can be created,
updated, and removed through the Admin API and take effect within milliseconds,
with no reload and no dropped connections. This makes APISIX a natural fit for
service discovery, canary releases, and automation-driven platforms.
+
+## Feature Comparison
+
+| Feature | Apache APISIX | NGINX (OSS) | NGINX Plus |
+|---------|--------------|-------------|------------|
+| Core data plane | NGINX + LuaJIT | NGINX | NGINX |
+| Configuration | etcd, dynamic, no reload | Static files, reload required |
Dynamic API (subset) |
+| Plugin ecosystem | 100+ built-in plugins | Modules / njs / Lua (DIY) |
Selected built-in modules |
+| Admin API | Full REST API | None (file-based) | Reconfiguration API |
+| Authentication | Key, JWT, OAuth 2.0, OIDC, LDAP, mTLS | DIY / njs | JWT,
basic |
+| Service discovery | Nacos, Consul, Eureka, DNS, Kubernetes | DNS (limited) |
DNS, some integrations |
+| AI gateway capabilities | ai-proxy plugin, multi-LLM routing | None | None |
+| Dashboard | Apache APISIX Dashboard (OSS) | None | Included |
+| License | Apache 2.0 (free) | BSD-like (free) | Commercial subscription |
+
+## When to Choose Apache APISIX
+
+- **You need API gateway features** (dynamic routing, authentication, rate
limiting, transformation) without hand-building them in NGINX configuration.
+- **Dynamic, automation-driven environments** where reload-based config is a
bottleneck.
+- **A rich plugin ecosystem and AI gateway** without a commercial license.
+- **NGINX-class performance** combined with a modern control plane.
+
+## When to Choose NGINX
+
+- **Simple reverse proxy, load balancing, or static web serving** without full
gateway requirements.
+- **An existing, finely tuned NGINX deployment** that already meets your needs.
+- **Deep, low-level control** over NGINX directives for specialized use cases.
+- **An existing NGINX Plus subscription** that already covers your dynamic
configuration and authentication needs.
+
+## FAQ
+
+### Isn't Apache APISIX just NGINX with extra steps?
+
+APISIX is built on top of NGINX and LuaJIT (via OpenResty), so it inherits
NGINX's proven performance, but it is not just NGINX. APISIX adds a full API
gateway layer that plain NGINX lacks: dynamic configuration through etcd with
no reloads, an Admin API, a 100+ plugin ecosystem for authentication, rate
limiting, and observability, service discovery, and a dashboard. You get
NGINX's data plane plus a complete control plane out of the box.
+
+### Do I need to know NGINX to run Apache APISIX?
+
+No. APISIX is configured through its Admin API, declarative YAML, or its
dashboard, using high-level concepts like routes, upstreams, services, and
plugins. You do not write or maintain nginx.conf. Familiarity with NGINX
concepts can help with advanced tuning, but day-to-day operation does not
require editing NGINX configuration files.
+
+### How does Apache APISIX compare to NGINX Plus?
+
+NGINX Plus is the commercial edition of NGINX, adding dynamic reconfiguration,
active health checks, JWT authentication, and a dashboard on a subscription.
APISIX provides comparable dynamic configuration, health checking, and
authentication, plus a much larger plugin ecosystem and AI gateway features, as
open-source software under the Apache 2.0 license with no per-instance fee.
Teams evaluating NGINX Plus for gateway features often find APISIX covers the
same needs without licensing cost.
+
+### Can I migrate my nginx.conf to Apache APISIX?
+
+Most nginx.conf reverse-proxy setups map cleanly onto APISIX concepts: server
and location blocks become routes, proxy_pass upstreams become APISIX
upstreams, and directives like rate limiting, header rewriting, and access
control become plugins. The main shift is moving from a static file that
requires reloads to dynamic configuration managed through the Admin API, which
removes reload-related downtime.
+
+## Related
+
+- [All API gateway comparisons](/comparisons/)
+- [What is an API gateway?](/learning-center/what-is-an-api-gateway/)
+- [Apache APISIX vs Envoy](/learning-center/apisix-vs-envoy/)
+- [Apache APISIX vs Traefik](/learning-center/apisix-vs-traefik/)
+- [Get started with Apache APISIX](/docs/apisix/getting-started/)
diff --git a/website/learning-center/apisix-vs-traefik.md
b/website/learning-center/apisix-vs-traefik.md
new file mode 100644
index 00000000000..ff4c1b279a1
--- /dev/null
+++ b/website/learning-center/apisix-vs-traefik.md
@@ -0,0 +1,103 @@
+---
+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."
+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?"
+ 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?"
+ 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?"
+ 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.
+---
+
+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 [...]
+
+## Overview
+
+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.
+
+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.
+
+## Architecture Comparison
+
+### Apache APISIX Architecture
+
+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.
+
+### Traefik Architecture
+
+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.
+
+## Performance
+
+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 [...]
+
+## Developer Experience and 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.
+
+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.
+
+## Feature Comparison
+
+| 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 |
+
+## When to Choose Apache APISIX
+
+- **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.
+
+## When to Choose Traefik
+
+- **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.
+
+## FAQ
+
+### Is Traefik easier to set up than 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.
+
+### How do Apache APISIX and Traefik compare on performance?
+
+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.
+
+### Which has a larger plugin ecosystem, Apache APISIX or 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.
+
+### Do both Apache APISIX and Traefik support Kubernetes and the Gateway API?
+
+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.
+
+## Related
+
+- [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/)
diff --git a/website/src/pages/comparisons.tsx
b/website/src/pages/comparisons.tsx
index c5834754ac6..0695f7a55c7 100644
--- a/website/src/pages/comparisons.tsx
+++ b/website/src/pages/comparisons.tsx
@@ -20,6 +20,36 @@ const COMPARISONS: Comparison[] = [
'Architecture, performance benchmarks, plugin ecosystem, Kubernetes
support, and when to choose each.',
to: '/learning-center/apisix-vs-kong/',
},
+ {
+ title: 'Apache APISIX vs AWS API Gateway',
+ description:
+ 'Self-hosted open source vs a managed cloud service — architecture, cost
at scale, and vendor lock-in.',
+ to: '/learning-center/apisix-vs-aws-api-gateway/',
+ },
+ {
+ title: 'Apache APISIX vs NGINX',
+ description:
+ 'APISIX is built on NGINX — what a purpose-built gateway adds over raw
NGINX and NGINX Plus.',
+ to: '/learning-center/apisix-vs-nginx/',
+ },
+ {
+ title: 'Apache APISIX vs Envoy',
+ description:
+ 'A turnkey API gateway vs a service proxy that needs a separate control
plane.',
+ to: '/learning-center/apisix-vs-envoy/',
+ },
+ {
+ title: 'Apache APISIX vs Traefik',
+ description:
+ 'Throughput and plugin breadth vs container-native auto-discovery and
automatic TLS.',
+ to: '/learning-center/apisix-vs-traefik/',
+ },
+ {
+ title: 'Apache APISIX vs Apigee',
+ description:
+ 'An open-source gateway vs a full enterprise API management platform —
scope and cost.',
+ to: '/learning-center/apisix-vs-apigee/',
+ },
{
title: 'Open-source API gateways compared',
description:
diff --git a/website/static/llms.txt b/website/static/llms.txt
index d6cb7d5ce15..eeeebbd46b4 100644
--- a/website/static/llms.txt
+++ b/website/static/llms.txt
@@ -48,15 +48,25 @@
## Learning Center
- [What is an API
Gateway?](https://apisix.apache.org/learning-center/what-is-an-api-gateway/):
Definition, benefits, and use cases
-- [API Gateway Authentication: Methods, Best Practices &
Implementation](https://apisix.apache.org/learning-center/api-gateway-authentication):
Auth at gateway layer (JWT, OAuth2, mTLS, HMAC)
-- [API Gateway for Microservices: Architecture, Patterns & Best
Practices](https://apisix.apache.org/learning-center/api-gateway-for-microservices):
Microservices architecture with API gateway
-- [API Gateway Rate Limiting: Algorithms, Strategies &
Configuration](https://apisix.apache.org/learning-center/api-gateway-rate-limiting):
Token bucket, sliding window, leaky bucket
-- [API Gateway vs Load Balancer: Key Differences
Explained](https://apisix.apache.org/learning-center/api-gateway-vs-load-balancer):
Gateway vs load balancer comparison
-- [Kubernetes API Gateway: Gateway API, Ingress Controllers & Best
Practices](https://apisix.apache.org/learning-center/kubernetes-api-gateway):
Kubernetes Gateway API and Ingress
-- [API Monetization: Models, Strategies & Implementation
Guide](https://apisix.apache.org/learning-center/api-monetization-guide): API
pricing and monetization models
-- [Open Source API Gateway Comparison: APISIX vs Kong vs Envoy vs
Traefik](https://apisix.apache.org/learning-center/open-source-api-gateway-comparison):
API gateway comparison
-- [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
-- [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
+- [API Gateway Authentication: Methods, Best Practices &
Implementation](https://apisix.apache.org/learning-center/api-gateway-authentication/):
Auth at gateway layer (JWT, OAuth2, mTLS, HMAC)
+- [API Gateway for Microservices: Architecture, Patterns & Best
Practices](https://apisix.apache.org/learning-center/api-gateway-for-microservices/):
Microservices architecture with API gateway
+- [API Gateway Rate Limiting: Algorithms, Strategies &
Configuration](https://apisix.apache.org/learning-center/api-gateway-rate-limiting/):
Token bucket, sliding window, leaky bucket
+- [API Gateway vs Load Balancer: Key Differences
Explained](https://apisix.apache.org/learning-center/api-gateway-vs-load-balancer/):
Gateway vs load balancer comparison
+- [Kubernetes API Gateway: Gateway API, Ingress Controllers & Best
Practices](https://apisix.apache.org/learning-center/kubernetes-api-gateway/):
Kubernetes Gateway API and Ingress
+- [API Monetization: Models, Strategies & Implementation
Guide](https://apisix.apache.org/learning-center/api-monetization-guide/): API
pricing and monetization models
+- [Open Source API Gateway Comparison: APISIX vs Kong vs Envoy vs
Traefik](https://apisix.apache.org/learning-center/open-source-api-gateway-comparison/):
API gateway comparison
+- [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 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 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
+- [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 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
