Production Readiness

Prepare each AISIX gateway for production before sending application traffic through it. The same runtime checks apply whether the gateway loads standalone resources or receives configuration from AISIX Cloud; differences in configuration and operational ownership are called out where they matter.

This page provides the production baseline. The remaining pages in this section explain capacity, startup configuration, network security, transport security, configuration updates, and health checks in detail.

Plan Capacity and Availability

Estimate the capacity of each gateway instance from representative request and response sizes, streaming behavior, and enabled policies. Leave headroom for bursts instead of sizing at measured saturation. See Performance and Sizing for the reference benchmark and sizing formula.

Run multiple instances when the traffic path must survive a process or host failure. Put them behind a load balancer, spread them across the failure domains that matter to your service, and ensure every instance receives the same dynamic resources.

Memory-backed rate-limit counters and cache entries are local to one gateway process. Use a shared Redis deployment when limits or cached responses must remain consistent across instances. For gateways connected to AISIX Cloud, see High Availability for the wider traffic and management topology.

Prepare Configuration and Dependencies

Confirm how the gateway receives dynamic resources before deploying replicas:

• An open-source AISIX gateway can load a declarative resources.yaml file and reload it on SIGHUP.
• An open-source AISIX gateway configured through etcd watches an etcd keyspace.
• A gateway connected to AISIX Cloud receives environment resources projected by the control plane.

Keep process settings such as listeners, resource source, Redis connections, and observability in startup configuration. Do not configure multiple dynamic-resource sources on the same gateway.

Protect every secret-bearing configuration source. A resources file should reference credentials through environment variables rather than contain plaintext values. A standalone etcd deployment needs persistence, backups, access control, and a private network path. Gateways connected to AISIX Cloud need their certificate bundle and runtime state directory protected and available across restarts.

Treat Redis as a runtime dependency when cache policies or rate limits select it. Use a topology that matches the availability requirement, and verify that every gateway instance points to the intended Redis deployment.

Secure Runtime Surfaces

Expose the proxy listener only to intended callers or the ingress tier in front of the gateway.

Keep the following surfaces on private networks:

• the metrics/status listener and its unauthenticated /metrics and /status/* routes;
• standalone etcd endpoints;
• files and directories containing provider credentials or AISIX Cloud certificates.

Configure listener TLS when AISIX terminates HTTPS. Configure etcd mTLS or AISIX Cloud mTLS for the corresponding management connection. Review Network and Security and TLS and mTLS before exposing the gateway.

Verify before Routing Traffic

Liveness proves that the process is running; it does not prove that an authorized request can reach a provider. Verify the runtime from the narrowest signal to the complete request path.

Set the proxy and metrics/status URLs:

PROXY_URL="https://gateway.example.com"
METRICS_URL="http://gateway.internal.example.com:9090"

Check process and traffic readiness:

curl -i "${PROXY_URL}/livez"
curl -i "${PROXY_URL}/readyz"

Inspect configuration and model status:

curl -sS "${METRICS_URL}/status/config"
curl -sS "${METRICS_URL}/status/models"

Then exercise behavior the health endpoints cannot prove:

• Call GET /v1/models with the caller API key the application will use.
• Send a provider-backed request through every endpoint family you plan to expose.
• Find the request in logs, metrics, usage reporting, or the configured exporter.
• Send an invalid caller API key and confirm that AISIX rejects it.

Use Health Checks to choose and interpret operational probes. If a configuration change has not reached the proxy path, see Configuration Propagation.

Plan Shutdown and Recovery

AISIX handles SIGINT and SIGTERM as graceful shutdown signals. During shutdown, it stops accepting new work, coordinates listener shutdown with background tasks, and reports failed liveness so the traffic layer can remove the instance.

Give the load balancer or orchestration platform enough time to stop assigning connections before the process exits. Set the termination grace period longer than the longest request or stream you intend to preserve.

Document how each deployment recovers its configuration:

• retain and validate the standalone resources file;
• back up and restore standalone etcd;
• preserve the AISIX Cloud certificate bundle, gateway identity, and latest accepted configuration according to the deployment design.

Test restart and replacement behavior before depending on it during an outage.

Production Checklist

Before widening traffic, confirm that:

• Capacity includes headroom and the intended number of gateway instances.
• Every instance uses the intended startup configuration and dynamic-resource source.
• Shared Redis is configured wherever cross-instance limits or cache entries are required.
• Proxy, metrics/status, and configuration-store surfaces have the intended network exposure.
• TLS, mTLS, certificate paths, and runtime-state permissions are valid.
• At least one provider key, model alias, and caller API key are available to the gateway.
• The model alias appears through the caller-facing proxy path.
• A real provider-backed request succeeds.
• Logs, metrics, usage reporting, or exporters contain the verification request.
• Shutdown, replacement, and configuration recovery have been tested.

Next Steps

Continue with Performance and Sizing to plan gateway capacity, then configure the runtime with Startup Configuration.