Docs

Run API7 Gateway in Production

What to settle before go-live, what to do on a recurring basis afterwards, and where the executable procedure for each task lives.

This page is the index for operating API7 Gateway: a go-live checklist, then the recurring work that keeps a deployment healthy. It deliberately does not restate sizing numbers, commands or thresholds that are maintained elsewhere — each item points at the page that owns it, so there is one place to change when the product changes.

If you are deploying on Kubernetes, Kubernetes Production Tuning is the companion runbook with the actual manifests and helm commands.

Before go-live

Work through these in order. Each one has a page that tells you how; this list only tells you that it is not optional.

Capacity and placement

  • Size the control plane and data plane against System Requirements. Size the control plane by the number of gateway instances and configuration churn; size the data plane by plugin mix, not just request rate.
  • Establish a throughput baseline with Performance Benchmark, using the plugins and route counts you actually plan to run. Sizing tables are a starting point; your plugin mix is what decides.
  • Size the shared dictionaries — see Shared Memory Sizing. Under-sized dictionaries make rate limiting fail silently rather than loudly.
  • Decide the failure domain. Multiple Availability Zones and Multi-Region Deployment Patterns cover placement.

Availability

  • Deploy for HA — Deploy for High Availability covers both planes.
  • Configure a fallback control plane so data planes keep serving when the control plane is unavailable: Data Plane Resilience.
  • Wire health probes into Kubernetes or your load balancer: Configure Readiness and Liveness Probes. Use /status/ready, not /status, for traffic decisions.
  • Plan PostgreSQL availability yourself. API7 does not configure replication, promotion or backups for its database — that is your deployment's responsibility, and it is the most common single point of failure.

Security

Observability

Recoverability

Change management

  • Keep configuration in Git. Define routes, services and plugins declaratively with ADC, review changes like code, and apply them from CI rather than by hand in the Dashboard.
  • Use a non-production gateway group as the staging target — Manage Gateway Groups. Data planes in a non-production group are metered differently; see License Management.
  • Know the rollback path for each change type before the first production change.

One ADC pitfall worth knowing before you automate anything: request metrics depend on a prometheus global rule that every deployment starts with. If your declarative configuration does not include global_rules.prometheus, a sync deletes it — and --label-selector does not protect global rules. What stops is apisix_http_status, apisix_http_latency and apisix_bandwidth; node-level metrics keep reporting, so the deployment still looks healthy while traffic, error and latency data silently goes to zero. Manage Gateway Configuration with GitOps covers the safe pattern.

After go-live

CadenceTaskWhere
ContinuousAlerting on error-budget burn, control-plane reachability, dictionary saturationAlerts and SLOs
WeeklyCheck licence utilisation against entitlementLicense Management
MonthlyReview role assignments and audit accessAudit Logs
MonthlyApply patch releasesPlan an API7 Gateway Upgrade
QuarterlyRestore drill — restore a real backup into a scratch environment and time itRestore API7 Gateway
QuarterlyRe-run capacity planning against observed growthPerformance Benchmark
Before expiryRotate the control-plane/data-plane mTLS certificates. Rotation is manual; the Dashboard alert is the only thing that tracks the date for youMutual TLS between Control Plane and Data Plane

Promoting a change

  1. Apply to a non-production gateway group and verify there.
  2. Confirm data planes actually received it. An instance that has lost its control-plane connection keeps serving its last known configuration and looks healthy — watch apisix_etcd_reachable.
  3. Roll out to production incrementally, checking readiness between batches.
  4. For data-plane version changes, use Data Plane Rolling Upgrade, which adds before it drains.

Scaling