Apache APISIX rate limiting and traffic control guide

Why Apache APISIX rate limiting needs a counter decision before go-live

An API platform team putting Apache APISIX in front of production APIs usually needs three things at once: request, count and connection limits that protect upstream services, and canary releases that shift a share of traffic to a new version without breaking those limits. APISIX provides traffic control plugins for these limits and for traffic splits. The main design choice is whether each gateway node counts requests on its own or whether nodes share counters, and that choice should be made before the first route goes live, because it determines what a limit actually protects.

A limit that looks correct on one node can be multiplied across a fleet. If each node keeps a local counter, a client allowed a fixed number of requests per window may effectively receive that number times the number of nodes that see its traffic, depending on how the load balancer spreads requests. Shared counters close that gap but add a dependency on a shared store, with its own latency, failure behavior and capacity. Test the limit against a multi-node deployment, not a single development instance, and confirm in the plugin documentation for your APISIX version how each limit plugin stores its counters and what happens when the shared store is unavailable.

Client identity changes what a limit protects. A limit keyed to a consumer, an IP address or a request header behaves differently in each case. Consumer-based limits follow an authenticated identity but only apply after authentication has run. IP-based limits are simple but break down behind shared proxies, carrier-grade NAT or corporate egress, where many users appear as one address. Header-based keys depend on values the client controls unless a trusted layer sets them. Write down, for each route, which identity the limit uses, who is allowed to set the identifying value, and which clients would be throttled by mistake.

Canary splits interact with both limits and authentication. A traffic split that sends a percentage of requests to a new upstream also moves those requests past different limit counters, possibly different authentication rules and different timeouts. A canary can therefore pass its functional tests while quietly changing the load profile or the rejection rate seen by clients. Plan the canary and the limit policy together: decide whether both versions share one counter, whether the split happens before or after authentication, and which metrics will show that the canary is not causing new 429 responses or authentication failures.

Before go-live, confirm the following with your APISIX version's documentation and your own environment: the exact limit and split plugins you will use, their counter storage model, the behavior of each under node failure, and the identity source for every limit. Run a test that sends traffic through several gateway nodes and checks the effective limit per client. The Apache APISIX documentation lists traffic control as one of its plugin groups, and APISIX is released under the Apache License 2.0 and built on NGINX and etcd, so these behaviors are configurable and testable rather than fixed. Settle the counter decision and the identity rules first, then build the routes and canaries around them.

Which APISIX objects carry rate limits, splits and counters

Rate limits, traffic splits and counters attach to different APISIX objects, and each object determines where a rule applies and how its counter is kept. The cards cover the routes, consumers and upstreams a rule can target, the scope of plugin configuration, the deployment mode that governs where configuration lives, and the Ingress Controller path for Kubernetes. Confirm exact plugin names and counter policies against the plugin reference for your release.

Routes set the request scope

A route matches incoming requests by attributes such as host, path and method, and a traffic control plugin attached to it applies to every request that matches. Most limits start here, so the match rules decide how far a limit reaches. Check for overlapping routes, because a request that matches more than one route needs a clear rule for which configuration applies. Confirm the matching order in the documentation for your release before you publish overlapping routes.

Consumers identify individual clients

A consumer is an identity, such as an API key or a JWT subject, that an authentication plugin resolves for each request. A traffic control plugin configured on a consumer can give each client its own counter, so one partner cannot exhaust a quota shared by every caller. A consumer exists only after authentication succeeds, so requests that fail authentication never reach that counter. Confirm how your chosen authentication plugin maps credentials to consumers.

Upstreams carry split and health decisions

An upstream groups the backend nodes a route forwards to, and it is where weighted distribution and health checks are configured. Canary releases usually combine a route with weighted upstreams or a split configuration, so the limit and the split can sit on different objects. Decide which object owns each limit before writing configuration, and record that decision with the route design. Confirm the weighting and health check fields in the plugin reference for your release.

Plugin configuration scope

Plugin configuration can attach to a route, a service, a consumer or a global rule, and APISIX applies its precedence rules when more than one level matches. The same limit defined at two levels can produce two separate counters or a combined one, so document the intended scope for each limit. Global rules apply to all traffic, which makes them useful for platform-wide protection and a common source of surprise during incident work. Confirm the merge and precedence behavior for your release.

Deployment mode sets counter behavior

Traditional, decoupled and standalone modes place configuration in different locations, and that placement affects how counters are shared across gateway nodes. In traditional mode, client traffic arrives on port 9080, the Admin API listens on port 9180, and configuration is held in etcd. Decoupled mode separates the data plane from the control plane while sharing one etcd cluster, and standalone mode reads configuration from a file or the API without etcd. Confirm how each mode stores counters in the release you run.

Ingress routes come from Kubernetes

When the APISIX Ingress Controller builds routes from Kubernetes resources, limits and splits must be expressed in those resources or in objects the controller manages. Changes made directly through the Admin API may be overwritten during reconciliation, so decide the source of truth before go-live. Keep rate limit settings in version-controlled manifests where possible. Confirm the annotation or custom resource fields in the controller documentation for the version you deploy.

Which counter, key and split decisions fit your gateway

This table compares the main counter, key, excess-handling and split choices for APISIX rate limiting and traffic control, with the operational cost of each. Read each row for the decision it supports, then check the cost column against your node count, identity model and load balancer layout. The main takeaway is that local counters are simpler but give every node its own budget, while shared counters enforce a fleet-wide limit at the price of a store dependency.

Decision	When it fits	What it costs you operationally
Local per-node counters	Single gateway node, or limits that can tolerate each node enforcing its own budget	Effective limit grows with node count, so a client can exceed the intended total. Capacity planning must account for each node's share.
Shared counters in an external store	Fleet-wide limits that must hold across many gateway nodes	Adds a dependency on the store. Confirm its latency, failure behavior and whether requests are allowed or rejected when it is unreachable.
Limits keyed per consumer	Authenticated clients with agreed quotas, such as partners or internal applications	Needs consistent consumer identity from the authentication plugin. Anonymous traffic falls outside these limits unless a fallback key is defined.
Limits keyed per client IP	Unauthenticated endpoints or coarse protection against abusive sources	Behind load balancers or proxies the gateway may see one upstream address for many clients. Confirm how the client address is forwarded and trusted before relying on it.
Limits keyed per header or route	Tenant, API key or route-specific limits, or protecting a single expensive endpoint	Keys built from client-supplied headers can be spoofed or rotated. Define which header is trusted and how missing values are handled.
Reject versus delay on excess requests	Rejecting suits strict protection; delaying suits bursty but legitimate clients	Delayed requests hold connections and memory while they wait. Rejected requests need clear status codes and client retry guidance.
Weighted upstreams	Splitting traffic across upstream versions by weight when the rule is simple and stable	Changing weights means editing upstream configuration. Confirm how weight changes are rolled out and reviewed across environments.
Traffic split plugin for canaries	Canary releases that need rules based on request attributes, such as headers or cookies	Rule sets grow with each release and need review. Test rule ordering and fallback behavior before traffic moves.
Traditional deployment for limit configuration	Teams that want a shared etcd-backed control plane and dynamic changes through the Admin API	Requires operating and backing up etcd and protecting the Admin API on port 9180. Plan for etcd availability alongside gateway availability.
Standalone deployment for limit configuration	Environments where configuration is versioned in files and deployed through existing pipelines	Changes ship as file updates rather than API calls. Confirm how files are distributed to each node and how drift between nodes is detected.

How to build rate limits and canary splits in APISIX

This sequence takes a gateway team from deployment decisions to tested rate limits and staged canary splits, with a check at each step. The result is a set of limits and traffic splits that behave the same way across every gateway node and are recorded in version control.

Confirm deployment mode and gateway fleet sizing
The platform engineering lead chooses traditional, decoupled or standalone mode and records how many gateway nodes will serve client traffic. The choice sets where the Admin API runs, since traditional mode serves it on port 9180 alongside client traffic on port 9080, and it determines whether counters can be shared across nodes. Check: a written decision record names the mode, the node count per environment and the etcd or file configuration source, and the team confirms the port layout against the deployment modes documentation for the APISIX version they run.
Inventory APIs and assign a client identity per limit
The API owners list every route and service, the consumers that call each one and the traffic each one carries. For each limit, the team picks the key the limit counts against: a consumer identity from an authentication plugin, a client IP address or a request header such as an API key or tenant ID. Check: every route in the inventory has a named limit key or a documented reason it has none, and the security lead confirms that IP-based keys account for proxies and load balancers in front of the gateway.
Define limit policy with reject behavior and headers
For each route or service, the API owner writes the limit policy: the request, count or connection threshold, the time window where it applies and the status code and body returned when a client is over the limit. The team also decides which rate limit response headers clients receive, so callers can back off without guessing. Check: a policy table lists each route, its key, its threshold and its reject behavior, and the team confirms the plugin names and options (for example the limit-req, limit-count and limit-conn plugins) against the documentation for their APISIX version.
Choose local or shared counters and secure the store
The platform team decides whether each limit uses counters held in each gateway node or a shared store that all nodes write to. Local counters are simpler to run but allow a client to receive more requests overall when traffic is spread across nodes, so the team weighs that against the cost of running a shared store. If a shared store is chosen, it gets its own credentials, network restrictions and access controls, separate from the gateway's Admin API. Check: the team can show which nodes write to the store, that the store rejects connections from outside the gateway subnet, and that a deliberate test request is counted once across the fleet.
Apply limits in staging and confirm counts
The QA or performance engineer applies the policies to a staging environment that matches production node count and mode, then runs a load generator against each limited route. They send traffic through every node and compare the counts each node records with the total the load generator sent. Check: the per-node counters, the aggregate count and the rejected-request responses match the policy table within the tolerance the team defined, and the headers and status codes returned to the client match what the policy specifies.
Design canary splits with per-version upstreams
The release engineer defines one upstream per application version, then configures a traffic split that sends a small share of requests to the new version while the rest stay on the current one. The split plan includes the share for each stage, the metrics that gate each increase and a rollback path that returns all traffic to the stable upstream by changing the split configuration. Check: a staging drill moves the split to the new version and back, and the team confirms that error rates and latency for each upstream are visible separately before the first production change.
Lock down the Admin API on port 9180
The security engineer confirms that the Admin API listener on port 9180 is bound only to management networks and is not reachable from client networks or the internet. They test from a client subnet and from the public side of any load balancer, and they confirm that the Admin API key has been changed from the default. Check: connection attempts to port 9180 from client networks fail, the management network can reach it, and the result is recorded with the date and the person who ran the test.
Record every limit and split in version control
The platform team stores each route's limit policy, counter configuration, canary split and rollback configuration as files in version control, with a review step before any change reaches production. Each change carries a commit message that names the owner and the reason, so the history shows who changed a threshold or moved a split. Check: a fresh staging environment built only from the repository reproduces the limits and splits tested in the earlier steps, and the team can roll back a split by reverting a commit.

What drives the effort of rate limiting and canary work

This table lists the factors that change how much work a rate limiting and canary rollout takes in Apache APISIX, with the reason each one matters and how to keep it under control. Most of the effort sits in policy design, testing and the shared counter store rather than in writing plugin configuration, so read the rows as the questions to settle before a quote. Ask for policy design, store setup, testing and handover to be priced as separate lines.

Driver	Why it raises effort	How to keep it down
Routes and consumers needing distinct limits	Each route, consumer or consumer group that needs its own limit is a separate policy to define, test and document. Exceptions multiply quickly across teams.	Group consumers into a small number of tiers and apply limits per tier. Limit only the routes with a clear capacity or abuse reason.
Gateway nodes and whether counters must be shared	Local counters are simple but each node counts alone, so a client can exceed the intended total across nodes. Shared counters need a store and extra load and failure testing.	Decide per limit whether approximate per-node enforcement is acceptable. Reserve shared counters for limits that must hold across the cluster.
Shared counter store: existing service or new cluster	Reusing an existing service means access, network paths and backup rules must be agreed with its owner. A new cluster adds setup, monitoring, patching and an on-call owner.	Confirm early whether an existing service is approved for this traffic. Name the team that will run the store before design starts.
Client identity types and mapping from existing authentication	Each identity type (API key, JWT claim, OAuth client, IP address) needs its own key logic. Mapping from current authentication often requires reading claims or consumer records from systems that are not yet documented.	List identity types in the inventory stage. Reuse the claims or consumer IDs your authentication already issues instead of creating new identifiers.
Canary count and release frequency	Each canary needs a split plan, success criteria, a rollback step and a record of the result. Frequent releases multiply this work and the regression checks behind it.	Standardize one canary template with fixed metrics and rollback triggers. Limit the number of active canaries at any time.
Load testing needs	Limits only prove correct under realistic concurrency and bursts. Designing the load profiles, running them against the shared store and reading the results takes skilled time.	Agree a small set of test scenarios that cover normal, burst and node-failure cases. Reuse them for later changes.
Environments and staging parity with production	A staging gateway with different node counts, store topology or route data produces results that do not transfer to production. Building and keeping a closer copy adds setup and upkeep.	Match node count, plugin set and store configuration where practical. Document any known differences so test results are read correctly.

How rate limiting differs across single node, cluster and Kubernetes

A single gateway node usually keeps rate limit counters in local memory, so each limit applies only to the requests that node receives. For many teams this is a sound starting point: the configuration is simple, there is no shared store to run, and limits are easy to test. The main risk is that the gateway itself is the single point of failure. If the node stops, no traffic passes, and nothing else enforces the limits.

What to plan for:

Limit scope: a per-consumer or per-route limit applies only to the traffic this node sees.
Restart behavior: local counters typically reset when the node restarts, so a burst right after a restart may pass.
Availability: decide whether a maintenance window or a standby node is acceptable for your service level.
Capacity: test that one node handles peak request volume with the plugins you enable.
Ports: in traditional mode, client traffic uses port 9080 and the Admin API uses port 9180, which should stay away from client networks.

Before you rely on local counters, confirm in the APISIX documentation for your version which rate limiting plugins keep counters locally and how they behave on restart.

How to keep limits from being bypassed or leaking secrets

Rate limits, canary splits and traffic rules only protect you if clients cannot change the inputs they key on, reach the controls that set them, or read more about them than they should. The points below cover the places where traffic control is most often weakened, and each one links to the wider security hardening work for the full set of controls.

Trusting client identity headers

If a limit keys on a header such as X-Forwarded-For or a custom client identifier, any client that can send that header can rotate its apparent identity and avoid the limit. Configure APISIX to trust forwarded addresses only from the proxies and load balancers you operate, and check that a request arriving directly from the internet cannot supply its own forwarded value. Test this by sending spoofed headers from outside your network and confirming the counter does not change.

Protecting the Admin API on port 9180

In traditional mode the Admin API listens on port 9180, and anyone who can reach it can change routes, rate limits and canary weights. Restrict it to a management network or bastion, separate it from client traffic on port 9080, and replace the default Admin API key before any environment is exposed. Confirm the restriction from outside the management network, not only in the configuration file.

Credentials for the shared counter store

Multi-node gateways that share counters depend on a backing store, and whoever can connect to it can reset or inflate counts. Give the gateway its own account with the least access it needs, restrict network paths to the store, and enable authentication and encryption in transit where the store supports them. Confirm the exact options with your chosen store's documentation before you finalize the design.

Keeping secrets out of plain configuration

Consumer keys, upstream credentials and store passwords tend to end up in apisix.yaml, route JSON or version control. Reference secrets through APISIX's secret management integrations where your deployment supports them, or inject them at deploy time from your existing secrets manager. Check that no configuration file, sample or export in your repository contains a live value.

Shielding canary upstreams from unintended clients

A canary route that splits a small share of traffic to a test version is only safe if that version is reachable by the intended users alone. Match canary rules on a controlled attribute such as a header set by your own edge, keep the test upstream off public DNS, and apply the same authentication and limits as production. Review the weights and match conditions after each change, since a broad match can send ordinary users to unfinished code.

Auditing limit and route changes

A changed limit, split or route can alter who gets blocked or served, and the change may not be visible in application logs. Record every Admin API write with the caller, time and object changed, and send those records to a store that the gateway operators cannot edit. Review the trail when traffic patterns shift, so you can tell a deliberate change from an accidental one or an intrusion.

How to test that APISIX limits hold and fail safely

Before a limit, failover rule or canary split carries production traffic, the team should test that it produces the behavior the policy describes. The plan below works as a checklist: exceed each limit, repeat the tests across several gateway nodes, break the counter store on purpose, split canary traffic in known proportions, roll back to the stable version, and confirm that one client's traffic cannot throttle another. Run the checks on a staging copy of the production route configuration with the same plugin versions and a comparable node count, since a single-node test on a different version tells you little about the production fleet. Keep the configuration in version control so every test run names the exact revision it covers.

Start with the limits. For each limiting plugin in use, such as limit-req for request rate, limit-count for quota windows or limit-conn for concurrent connections, drive traffic above the configured threshold with a load generator. Confirm that excess requests receive the rejection status code and any rate-limit headers the policy specifies, and that requests below the threshold still succeed at normal latency. Test with at least two consumers and two client addresses, because a single test client cannot show whether the key is applied per consumer or per IP. Check that the rejection response does not expose upstream hostnames, stack traces or internal error text. Record the status code distribution and the headers the client actually received, not only a pass or fail result.

Next, test the fleet as a whole. Send load through the same load balancer that production uses so requests spread across every gateway node, then compare total admitted requests with the policy. A counter kept locally on each node enforces the limit separately on that node, so the fleet-wide total grows with the number of nodes. A shared counter, where the plugin is configured to use a common store, should keep the fleet total close to the policy. Confirm which mode your plugin version and configuration use, because the answer changes what the limit means to the business. Record the node count during the run, since a scaling event mid-test will distort the totals.

Break the counter store on purpose in staging, for example by stopping it or blocking the network path from the gateway nodes, and observe whether requests are allowed or rejected. Confirm that the observed behavior matches the fail open or fail closed decision the service owners signed off, and that operators can see the failure in logs or alerts. For canary releases, send requests through the traffic split in a known proportion, then count which upstream version served each request using a response header or log field added for the test. Compare those counts with the configured weights. Finally, time a rollback to 100 percent of the stable version and confirm it completes inside the change window with the on-call engineer who will perform it in production.

Last, test that clients with valid identity are not limited by someone else's traffic. Flood the route with one consumer credential, then send normal requests with a second valid credential and confirm they still succeed. Repeat the test with JWT or introspected tokens if those are used for authentication. Record evidence for every test: the configuration revision, plugin versions, load profile, start and end times, raw results, observed headers, store behavior logs, and the name of the person who accepted each result. Attach this record to the change ticket so the operations team and any independent auditor can see what was tested, and rerun the suite after every upgrade or policy change.

What to monitor, back up and document after go-live

This table lists what to watch, preserve and document once Apache APISIX rate limits and canary routes are live. Read each row as an operational task with its reason attached. The main takeaway is that limit behavior can change between APISIX releases, so upgrade testing and runbook updates belong in every change process.

Area	What to do	Why it matters
Rate-limit rejections per route and consumer	Track rejected requests by route and consumer, and watch for sudden shifts after any configuration change.	Shows whether limits are too tight for legitimate clients or too loose to protect upstream services.
Gateway latency and error rates	Chart latency and 5xx responses at the gateway and per upstream, separate from the limiter's own rejections.	Distinguishes a slow or failing backend from a gateway problem, since limit and auth plugins add work to each request.
Shared counter store health	Monitor availability and latency of the store behind shared limit counters, as configured in your limit plugin, and alert on its errors.	Shared counters depend on this store, so slow or unreachable counters can change enforcement across all gateway nodes.
Canary error rates and traffic split	Compare error rates and latency of canary and stable versions, and confirm the observed split matches the configured weights.	A gap between configured and observed split can mean sticky sessions, client retries or caching are skewing the test.
Configuration change history	Record every change to routes, upstreams, consumers, plugins and limit values, with author, time and reason, in your config repository or audit trail.	Lets you tie a spike in rejections or errors to a specific change and roll back the correct one.
Backups of route and plugin configuration	Back up route, upstream, consumer and plugin settings on a schedule and after each change. Include etcd snapshots where etcd is used, or the YAML or JSON file in standalone mode.	A restored gateway needs its limits, canary weights and credentials. Test restores in a non-production environment.
Upgrade testing of limit behavior	Before moving to a new APISIX release, replay representative traffic against limits and canary splits in staging. Confirm the release line you run and review its release notes for plugin changes.	Limit behavior and plugin defaults can change between releases, so retest rate limits and traffic splits after every upgrade.
Runbook for limit changes and canary rollback	Document steps to change a limit value, verify its effect, set canary weight to zero and restore the previous configuration, with named owners.	During an incident, the on-call engineer should work from tested steps, with the owner and rollback path agreed in advance.

What buyers ask before hiring help with APISIX traffic control

How much work does rate limiting and canary setup take in APISIX?

The effort depends on how many routes and consumers need limits, how many distinct policies you need, and how much testing your release process requires. A single route with one limit and a simple percentage canary is a small change. Effort grows when limits differ by consumer tier, when several services share one quota, or when canaries must be gated on metrics from your observability stack. Ask for a written scope that lists the routes, policies and canary criteria in play, since those items set the work. No duration is given here because it follows from that inventory.

Can our own team configure APISIX rate limiting without a partner?

Yes, for single-node deployments or simple policies such as a fixed request count per consumer on a few routes. Your team needs working knowledge of APISIX routes, plugins and the Admin API, familiarity with the limit-count and limit-req style plugins, and the ability to test in a non-production environment before changing live traffic. Effort rises when you need shared counters across nodes, per-consumer tiers managed from an identity source, or canaries wired to automated rollback. A partner is most useful for those multi-node or multi-policy cases, or when your team lacks capacity to test them properly.

Do shared rate limit counters need a new service, and who should own it?

Usually yes. When several gateway nodes must enforce one limit, counters have to live in a store they all can reach, such as a Redis-compatible service, rather than in each node's memory. Local counters are simpler and work well when each node can enforce its own share. Choose the store with your platform team, because they will carry its availability, backups, network paths and capacity. Assign the gateway team ownership of the policy definitions and the platform team ownership of the store. Confirm the exact store types supported by your APISIX version in its plugin documentation.

What does the rate limiting work need from our side?

Plan to provide an inventory of the APIs and routes in scope, with their upstreams and current traffic patterns where you have them. You will also need a consumer model that states who calls each API and what limits each consumer type should get. A test environment is essential, and it should match production closely in gateway version, deployment mode and plugin settings, so that limit behavior tested there holds in production. Access to the shared counter store, the etcd cluster if you use traditional or decoupled mode, and your logs and metrics is also required. Missing items usually extend the work more than the configuration itself.

How are canary releases rolled back in APISIX?

A canary is a route or upstream configuration that sends a defined share of traffic to a new version, so rollback means setting that share back to zero or pointing all traffic at the stable upstream. In APISIX this is a configuration change, applied through the Admin API or your declarative files, so it can be reverted quickly if your change process allows it. The rollback plan should name the trigger metrics, such as error rate or latency thresholds, the person authorized to act, and the exact configuration to restore. Rehearse that path in staging before the first production canary.

Will our rate limits carry over when we upgrade APISIX?

Not automatically. Limit configuration usually survives an upgrade, but plugin behavior, default values, option names and counter storage can change between releases. Read the release notes for every version between your current and target release, confirm how each affected plugin behaves, and retest limits on a staging copy of your real routes. Compare request-rate outcomes with and without limits, and verify that shared counters still reach their store after the upgrade. Treat the upgrade as a change to traffic control, not only a package update, and keep a tested rollback path.

What does a fixed-scope rate limiting engagement include and how is it priced?

A fixed-scope engagement covers a written list of routes, policies, canary workflows and test cases, along with the deliverables and timeline agreed before work starts. Typical deliverables are the configured limits and canary definitions, test results, a rollback runbook and handover notes for your team. DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that matter most are the number of policies, whether shared counters are needed, the state of your test environment and whether your team will do part of the work. Ask for the quote to separate one-time build work from any ongoing support you choose to add.

How DeployOpen scopes, builds and hands over APISIX traffic control

DeployOpen plans, implements and hands over Apache APISIX rate limiting and traffic control inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped network. Each engagement starts from a written, fixed scope that names the routes, consumers, limits and traffic rules to be delivered, so your team knows what it receives before work begins.

How we scope

Inventory the routes, upstreams and consumers that need request, count or connection limits.
Agree which deployment mode (traditional, decoupled or standalone) fits your gateway topology.
Define canary and traffic-split rules, and whether counters stay local or are shared across nodes.
Record the scope, deliverables and timeline in writing before any work starts.

How we build

Configure limit plugins and traffic-split rules as code, tested against representative request patterns.
Test limit behavior on a single node first, then across multiple gateway nodes with your chosen counter model.
Verify canary weights and rollback steps in a non-production environment that mirrors production routing.
Confirm each limit's response codes and headers match what your client applications expect.

How we hand over

Deliver the configuration, with a record of each limit, its owner, and the reason it was set.
Document the counter model, its failure behavior and the steps to change limits without a restart.
Walk your operations team through dashboards, logs and the runbook for raising or lowering limits.
Provide a test script your team can rerun after any routing or plugin change.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer.
Review limit and traffic-split changes against the release notes of each APISIX version you run.
Retest rate limits after upgrades of APISIX, etcd or the Ingress Controller where they touch your routes.
Ask your quote to state which support tasks are included and how change requests are priced.

Apache APISIX rate limiting and traffic control