Apache APISIX Overview

By Khimananda Oli | Last reviewed: August 2026

Choosing the right API gateway often determines whether your infrastructure scales smoothly or becomes a bottleneck during peak traffic. This Apache APISIX overview explains why this high-performance, cloud-native gateway has become a standard choice for teams needing dynamic routing without restarts. If you are evaluating gateways for Kubernetes or bare-metal environments, understanding APISIX’s Nginx-plus-LuaJIT core and etcd-backed configuration model is essential before committing to production.

What is Apache APISIX and how does its architecture work?

At its core, Apache APISIX is a fork of OpenResty (Nginx + LuaJIT) optimized specifically for API gateway workloads rather than general-purpose web serving. The architecture separates the data plane from the control plane completely. The data plane consists of stateless APISIX nodes that handle all traffic processing using compiled LuaJIT bytecode. These nodes do not store persistent state locally; instead, they watch an etcd cluster for configuration changes.

This design solves the most painful operational issue in legacy gateways: the configuration reload. In traditional Nginx or Kong setups, changing a route often requires a config test and process reload, which can drop connections or cause latency spikes under load. APISIX eliminates this by maintaining a long-polling connection to etcd. When a route is added or modified via the Admin API, the change propagates to all data plane nodes within milliseconds. For teams managing thousands of routes across multiple regions, this difference is massive. I have seen migration projects where switching from a reload-based gateway to APISIX reduced deployment-related error rates to near zero.

The reliance on etcd means your gateway's availability is tied to your etcd cluster's health. In practice, always deploy etcd as a separate, highly available cluster with at least three nodes. Never co-locate etcd on the same pods as APISIX in Kubernetes unless you fully understand the failure domains. For teams already running Kubernetes ingress controllers, APISIX also offers a dedicated Ingress Controller that translates K8s resources into APISIX configurations automatically, bridging the gap between native K8s workflows and APISIX’s powerful runtime.

How do you configure routes and plugins dynamically in APISIX?

Configuration in APISIX is entirely declarative and API-driven. There are no static config files to edit on disk. Every route, upstream, consumer, and plugin binding is stored in etcd and managed through the Admin API or the Dashboard UI. This makes APISIX exceptionally friendly to GitOps workflows and infrastructure-as-code tools like Terraform.

Creating a basic route with rate limiting

To create a route that forwards traffic to an upstream service while applying a rate limit, you send a PUT request to the Admin API. Note that we use PUT with a specific ID to ensure idempotency, which is critical when automating deployments via CI/CD pipelines.

curl -X PUT http://localhost:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: your-admin-api-key" \
  -d '{
    "uri": "/api/v1/orders",
    "methods": ["GET", "POST"],
    "upstream": {
      "type": "roundrobin",
      "nodes": {
        "10.0.1.10:8080": 1,
        "10.0.1.11:8080": 1
      }
    },
    "plugins": {
      "limit-count": {
        "count": 100,
        "time_window": 60,
        "rejected_code": 429,
        "key_type": "var",
        "key": "remote_addr"
      }
    }
  }'

This configuration takes effect immediately across all APISIX nodes. No reload, no restart. The limit-count plugin enforces 100 requests per minute per client IP. If you need to adjust this threshold during an incident, simply re-issue the same PUT request with a new count value. The change propagates in under 100ms. This responsiveness is what makes APISIX superior for environments where traffic patterns shift unpredictably, such as e-commerce flash sales or event-driven platforms common in Nepal’s growing digital economy.

Plugin chaining and execution order

APISIX plugins execute in a defined lifecycle: rewrite, access, header_filter, body_filter, and log. You can chain dozens of plugins on a single route. Common combinations include authentication (JWT/OIDC), rate limiting, request transformation, and observability injection. Unlike some gateways where plugin order is implicit or hardcoded, APISIX allows explicit priority tuning via the _meta.priority field in plugin configuration. This prevents subtle bugs where auth checks run after logging, potentially exposing sensitive data in logs—a compliance risk I frequently flag during DevSecOps audits.

How does Apache APISIX compare to Kong and NGINX Ingress?

Selecting an API gateway requires honest trade-off analysis. While Kong shares APISIX’s OpenResty heritage, their architectural decisions diverged significantly. NGINX Ingress remains popular but serves a different primary purpose. Understanding these distinctions prevents costly re-architecture later.

In my experience, APISIX wins on raw performance and dynamic configurability. Kong offers a richer enterprise ecosystem and more mature third-party integrations, which may matter if you need vendor support contracts. NGINX Ingress is sufficient for simple Kubernetes routing but lacks the advanced traffic management features (canary releases, circuit breaking, request mirroring) that APISIX provides out-of-the-box. If your team needs deep observability integration alongside gateway functionality, consider pairing APISIX with the monitoring stack described in Prometheus and Grafana full monitoring stack guides, as APISIX exports metrics natively in Prometheus format.

How do you extend APISIX with custom plugins and observability?

While APISIX ships with over 80 built-in plugins covering authentication, security, traffic control, and observability, real-world deployments almost always require custom logic. APISIX supports multi-language plugin development, allowing teams to write business logic in Go, Python, Java, or WebAssembly without touching Lua. This is crucial for organizations where Lua expertise is scarce but Go or Python proficiency is abundant.

Writing a custom Go plugin

Custom plugins run as sidecar processes communicating via RPC. This isolation means a buggy custom plugin cannot crash the entire gateway. To create a custom header-enrichment plugin in Go:

1. Create a Go module implementing the plugin.RequestHandler interface.
2. Register the plugin name and version in the plugin registry.
3. Build the binary and mount it into the APISIX container via a volume or custom image layer.
4. Enable the plugin in config.yaml under ext-plugin.pre_req or post_req.
5. Reference the plugin by name in your route configuration just like any built-in plugin.

This approach maintains gateway stability while enabling rapid iteration on business-specific logic. For observability, enable the prometheus and opentelemetry plugins globally. APISIX exposes metrics at /apisix/prometheus/metrics by default, including request counts, latencies by route, status codes, and upstream health. Pair this with structured logging via the file-logger or kafka-logger plugins to feed centralized logging systems. Teams adopting OpenTelemetry standards will find APISIX’s native trace context propagation particularly valuable for end-to-end visibility across microservices.

Security hardening considerations

Never expose the Admin API publicly. Bind it to localhost or a private management network. Use mTLS for Admin API access in production. Enable the consumer-restriction plugin to enforce granular access policies beyond simple API keys. Regularly audit plugin configurations for overly permissive CORS settings or disabled rate limits—common misconfigurations I encounter during security reviews. For Nepal-based fintech or healthcare deployments handling sensitive data, combine APISIX with Vault for secret injection and ensure all TLS termination happens at the gateway level with modern cipher suites only.

When should you adopt Apache APISIX for your platform?

Adopt Apache APISIX if your primary constraints are low latency, high throughput, and frequent configuration changes. It excels in microservices environments with hundreds of routes, multi-protocol requirements (gRPC, WebSocket, MQTT), or teams practicing continuous deployment where gateway reloads cause unacceptable disruption. Avoid it if you require extensive enterprise vendor support, deep integration with non-etcd ecosystems, or have zero tolerance for operational complexity around etcd management.

For most modern cloud-native stacks in 2026, APISIX represents the best balance of performance, flexibility, and open governance. Start with the official Helm chart for Kubernetes deployments or Docker Compose for local development. Invest time early in building automated testing for your route configurations—treat gateway config as code with the same rigor as application code. If you need guidance on integrating APISIX into your existing infrastructure or designing a compliant API platform, reach out to discuss your specific architecture.