Apache APISIX Overview

By Kokil Thapa | Last reviewed: September 2026

Your Laravel API works fine behind Apache or Nginx until traffic spikes, partner integrations multiply, and every team wants its own rate limits and auth rules. An Apache APISIX Overview helps you decide whether this open-source gateway belongs in front of your services. APISIX sits on OpenResty (Nginx plus LuaJIT) and stores routes in etcd, so you change routing without reloading the whole edge. If you already ship REST API development in Nepal or maintain multi-service stacks, this guide covers what APISIX actually does in production.

What is Apache APISIX and how does its architecture work?

Apache APISIX is a cloud-native API gateway donated to the Apache Software Foundation. It terminates HTTP, HTTPS, gRPC, TCP, and WebSocket traffic at the edge. Configuration lives in etcd, a distributed key-value store. Data plane nodes read etcd and apply changes in near real time.

That split matters on real deployments. Traditional Nginx configs need a reload for every route tweak. APISIX pushes updates through its Admin API or declarative YAML. I've seen this pattern on production Laravel applications where mobile apps, partner webhooks, and admin dashboards all hit the same hostname with different auth and throttle rules.

Control plane versus data plane

The data plane handles every request. It runs the Nginx worker model with Lua hooks for plugins. The control plane is etcd plus the Admin API (or APISIX Ingress Controller on Kubernetes). You rarely SSH into gateway boxes to edit files. You POST JSON to the admin port or sync Git-backed YAML through CI.

APISIX also ships apisix-dashboard for visual route management. For teams without a dedicated platform group, the dashboard lowers the barrier. For GitOps shops, declarative config in version control is usually safer. Both paths write to the same etcd keys.

Why etcd instead of flat files?

etcd gives you watch-based propagation. When a route changes, all gateway nodes pick it up within seconds. That fits API rate limiting and abuse prevention workflows where you tighten limits during an attack without a full deploy window.

The trade-off is operational overhead. You need a healthy etcd cluster (typically three nodes for quorum). On a single VPS hosting one Laravel app, plain Nginx may still be the right call. APISIX earns its keep when you manage dozens of routes across multiple upstreams and environments.

How does Apache APISIX compare to Kong, Nginx, and Traefik?

Engineers often evaluate APISIX against Kong, raw Nginx, and Traefik. All four terminate traffic at the edge. The differences sit in config model, plugin ecosystem, licensing, and day-two operations.

For a brochure WordPress site on shared hosting, Nginx versus Apache for PHP sites is the more relevant debate. APISIX targets API-first architectures: mobile backends, partner B2B APIs, and microservices behind one public hostname.

Kong and APISIX feel similar because both use OpenResty under the hood. APISIX tends to ship more built-in plugins without a separate enterprise tier for basics like JWT auth and request rewriting. Kong's commercial support and Konnect cloud control plane appeal to larger orgs. APISIX fits teams that want Apache governance and full dynamic config without a vendor subscription.

How do you install and configure Apache APISIX on Ubuntu?

The official install path for Linux uses OS packages or Docker Compose. On Ubuntu 22.04 or 24.04 servers — the same boxes I use for Linux system administration — Docker Compose is the fastest way to stand up APISIX plus etcd for a proof of concept.

Docker Compose quick start

Create a project directory and add a compose file. The example below pins a recent APISIX release and bundles etcd:

mkdir apisix-poc && cd apisix-poc

cat > docker-compose.yml <<'EOF'
services:
  etcd:
    image: bitnami/etcd:3.5
    environment:
      ALLOW_NONE_AUTHENTICATION: "yes"
      ETCD_ADVERTISE_CLIENT_URLS: http://etcd:2379
    ports:
      - "2379:2379"

  apisix:
    image: apache/apisix:3.11.0-debian
    depends_on:
      - etcd
    ports:
      - "9080:9080"
      - "9180:9180"
      - "9443:9443"
    volumes:
      - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml:ro
EOF

Point APISIX at etcd in config.yaml:

deployment:
  role: traditional
  role_traditional:
    config_provider: etcd

etcd:
  host:
    - "http://etcd:2379"
  prefix: "/apisix"
  timeout: 30

plugin_attr:
  prometheus:
    export_uri: /apisix/prometheus/metrics
    export_addr:
      ip: "0.0.0.0"
      port: 9091

Start the stack and verify the admin API responds:

docker compose up -d
curl -i http://127.0.0.1:9180/apisix/admin/routes \
  -H "X-API-KEY: edd1c9f034335f136f66ad894625facd"

Change the default admin key immediately. The shipped demo key is public knowledge. Store a strong key in your secrets manager. You can generate one with the password generator tool on this site, then rotate it in config.yaml under deployment.admin.admin_key.

Register your first upstream route

Suppose a Laravel 13 API listens on port 8000 on a private network. Register an upstream and route through the Admin API:

curl "http://127.0.0.1:9180/apisix/admin/upstreams/1" -X PUT \
  -H "X-API-KEY: YOUR_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "roundrobin",
    "nodes": {
      "10.0.1.50:8000": 1
    }
  }'

curl "http://127.0.0.1:9180/apisix/admin/routes/1" -X PUT \
  -H "X-API-KEY: YOUR_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "uri": "/api/*",
    "upstream_id": 1,
    "plugins": {
      "limit-count": {
        "count": 100,
        "time_window": 60,
        "rejected_code": 429,
        "key": "remote_addr"
      },
      "prometheus": {}
    }
  }'

Traffic to http://gateway-host:9080/api/v1/users now proxies to Laravel with a 100-requests-per-minute cap per IP. Your application still validates business rules. The gateway handles edge throttling before PHP-FPM workers get saturated.

1. Provision etcd with odd-numbered nodes for production quorum.
2. Install APISIX data plane nodes behind a load balancer.
3. Lock down port 9180 to admin IPs or a VPN only.
4. Define upstreams for each backend service.
5. Attach route-level plugins for auth, CORS, and logging.
6. Export Prometheus metrics and wire alerts into your stack.

For JSON payload testing during route setup, paste Admin API responses into the JSON formatter to catch typos before they hit etcd.

Which Apache APISIX plugins matter most in production?

APISIX ships 80+ plugins covering security, traffic control, observability, and serverless hooks. You enable plugins per route, per service, or globally. Below are the ones I reach for first on client API projects.

Security and identity

• key-auth — simple API keys for partner integrations and internal tools.
• jwt-auth — validate Bearer tokens before requests reach Laravel Sanctum or Passport.
• openid-connect — delegate login to Keycloak, Auth0, or similar IdPs.
• ip-restriction — allowlist office IPs for admin-only routes.
• cors — centralise cross-origin rules instead of duplicating them in every service.

Traffic management

The limit-count and limit-req plugins protect upstreams from bursts. Pair them with Redis 8.10 for cluster-wide counters when you run multiple gateway nodes. The proxy-cache plugin caches GET responses at the edge — useful for read-heavy catalog endpoints on eCommerce APIs similar to stacks behind Quick And Easy Nepalese Grocery.

traffic-split supports canary releases. Send 5% of traffic to a new Laravel release while 95% stays on stable. That beats blue-green DNS flips for API clients that cache hostnames aggressively.

Observability

Built-in prometheus, zipkin, and opentelemetry plugins export latency and status codes. Wire Prometheus into Alertmanager using patterns from alerting with Prometheus Alertmanager. You get per-route error rates without instrumenting every controller.

The http-logger and kafka-logger plugins push access logs to external systems. If you already run event pipelines, see Apache Kafka fundamentals for how log sinks feed analytics downstream.

When should you put Apache APISIX in front of Laravel or legal-tech portals?

Not every project needs a dedicated gateway. A law-firm brochure site on WordPress 7.1 with a contact form rarely justifies etcd. A client portal with document uploads, payment callbacks, and mobile API access is a different story.

On legal-tech portals I've shipped — platforms with booking, document sharing, and third-party payment webhooks — the edge layer carries real load. Khalti, eSewa, and Stripe callbacks need stable public URLs. APISIX can terminate TLS, enforce IP allowlists on webhook paths, and log every callback attempt before Laravel processes it.

Consider APISIX when three or more of these apply:

• Multiple backend services share one public domain.
• Partner APIs need per-client rate limits and API keys.
• You run canary or A/B traffic splits between app versions.
• Centralised observability across services is missing today.
• Config changes happen weekly and Nginx reloads feel risky.
• You plan Kubernetes migration within the next year.

Skip APISIX when a single Laravel 13 monolith serves everything and your team has no etcd experience. A well-tuned Nginx reverse proxy with limit_req zones covers many Nepal SMB workloads at lower ops cost. Read Nginx versus Apache performance and use cases for that simpler path.

For enterprise multi-service builds, APISIX pairs naturally with work described under enterprise application development. The gateway becomes the contract point for external consumers while internal teams ship services independently.

Integrating with Laravel Sanctum and queues

APISIX validates JWT or API keys at the edge. Laravel Sanctum still owns session and token issuance inside the app. Do not duplicate auth logic in Lua unless you have a clear reason. Let the gateway reject obviously bad tokens early. Let Laravel policies enforce resource-level permissions.

For webhook endpoints, disable CSRF as you normally would in Laravel. Add APISIX ip-restriction or mTLS plugins on those routes. Payment gateways publish IP ranges you can allowlist. That cuts junk POST traffic before it hits your queue workers.

High availability and multi-region notes

Run at least two APISIX data plane nodes behind a load balancer. etcd needs three nodes minimum for fault tolerance. Cross-region etcd is painful. Prefer one etcd cluster per region with DNS geo-routing, as outlined in active-active versus active-passive multi-cloud patterns.

After gateway deploys, run load tests through testing and optimization workflows. Watch P99 latency at the gateway and upstream. A misconfigured limit-req plugin can starve legitimate burst traffic from mobile clients.

Key Takeaways

• Apache APISIX is a dynamic API gateway on OpenResty plus etcd — routes update without full Nginx reloads.
• Use it when multiple services, partner APIs, or frequent config changes justify etcd operations.
• Start with Docker Compose, lock down the admin key, and attach limit-count plus prometheus plugins on day one.
• Keep Laravel auth and business validation in PHP; let APISIX handle edge throttling, TLS, and logging.
• Compare against Kong for enterprise support needs and against plain Nginx for single-monolith simplicity.
• Export metrics to Prometheus and treat gateway config as code through Git-backed Admin API calls or declarative YAML.

People Also Ask

Is Apache APISIX free to use in production?

Yes. APISIX is Apache License 2.0 open source. You pay for infrastructure (servers, etcd, Redis, load balancers) and the engineering time to operate it. There is no per-request vendor fee unlike some commercial API management platforms.

Does Apache APISIX replace Nginx entirely?

APISIX builds on OpenResty, which is Nginx plus Lua. It replaces hand-edited Nginx configs for API routing scenarios. Static asset sites and simple PHP-FPM vhosts may still run faster on a plain Nginx or Apache stack with less moving parts.

What database does Apache APISIX use?

APISIX stores configuration in etcd, not MySQL or PostgreSQL. Some plugins (like limit-count with Redis policy) use Redis 8.10 for shared counters. Application data still lives in your own MySQL 9.7 or PostgreSQL 18 databases behind the gateway.

Can Apache APISIX run on Kubernetes?

Yes. The APISIX Ingress Controller watches Kubernetes resources and syncs them to etcd. This is the standard path for teams already on K8s who want Gateway API-compatible routing without bolting on a separate proprietary control plane.

Deploy the Right Edge Layer for Your API Stack

This Apache APISIX Overview should give you enough context to decide, install, and harden a gateway in front of Laravel, Node, or mixed upstreams. Start small with one staging route, prove rate limiting and metrics export, then expand. If you want help designing the edge layer for a multi-service platform — or you're unsure whether Nginx alone is enough — contact us to walk through your traffic profile. You can also browse the Mijar Law Associates portfolio for an example of a secure client portal where edge routing and app-level auth must work together, or explore web development services for full-stack delivery from gateway to database.

Official references worth bookmarking: the Apache APISIX getting started guide, the plugin hub documentation, and the etcd documentation for cluster sizing and backup procedures. Pair those with internal guides on admission controllers and validating webhooks if you're standardising edge policy across Kubernetes and bare-metal gateways. For ongoing ops after launch, support and maintenance keeps both the gateway layer and upstream apps patched through PHP 8.5 and Laravel 13 upgrade cycles.

Read more on the blog, review customer reviews, or visit the homepage to see how production systems are built and operated from Kathmandu for clients in Nepal and abroad. When your API surface grows beyond a single controller file, APISIX gives you one place to enforce the rules — as long as you respect the etcd tax and treat gateway config with the same discipline as application code.