Who needs Apache APISIX upgrades and support after go-live
Upgrades and support for Apache APISIX are recurring work, not a one-time project that ends at go-live. Once the gateway carries production traffic, someone has to track new releases, decide when to move, test the change and keep the platform patched for as long as it runs. Teams that treat the launch as the finish line usually discover this when a release lands and nobody owns the decision. The gateway is live, the engineers who built it have moved on to other work, and the release feed keeps moving. The APISIX downloads page lists APISIX 3.19.0, released September 28, 2026, and APISIX Ingress Controller 2.2.0, released August 18, 2026. Those dates are a reminder that the release line does not pause for a project plan. Two different products also move on separate schedules, so a gateway and its Kubernetes ingress layer can drift apart without anyone noticing.
A common split works well for small teams. Routine patching and minor updates stay in-house, handled by the platform or operations team with a standing change window. Planned version moves, changes to plugins and their configuration, and work on the etcd cluster or the Kubernetes layer go to a partner who can review the release notes, rehearse the change in a non-production environment and document the rollback path. The exact boundary depends on who holds on-call duty and how much APISIX knowledge remains in the team, so it should be written down rather than assumed. Before you plan any cadence, check the support window. The APISIX downloads page does not mark any release as long-term support. That means the length of support for the version you run must be confirmed with the Apache APISIX project and in your own vendor terms if you use a commercial build. Ask which release lines receive fixes, for how long, and what happens to a version that falls out of that window. Do not build a maintenance calendar on an assumed support period.
Several decisions shape how much ongoing work you will carry. Note which deployment mode you run, because traditional, decoupled and standalone modes place upgrade risk in different components. Record which plugins are enabled, including any custom code, since plugin behavior can change between releases and custom plugins must be retested. Confirm who owns the etcd cluster, its backups and its version, and who watches the Admin API on port 9180 for access changes. Each of these items becomes a recurring task, and each needs a named owner before the next release arrives.
For a planning conversation, ask a partner to separate one-time work from recurring work in writing. One-time items include a baseline inventory of versions, routes and plugins, and a first upgrade rehearsal. Recurring items include release monitoring, scheduled patch windows, regression testing of critical routes, and incident support. Ask what the agreement covers, which releases are included, how urgent security fixes are handled, and how changes are scoped. A written scope lets you compare an internal team with an outside partner on the same terms.
What an upgrade and support engagement includes
An APISIX upgrade touches the gateway, its routes and plugins, the etcd cluster that stores configuration, and in Kubernetes the Ingress Controller. The work packages below follow that order, so each change is tested before it reaches production. The optional ongoing support layer sits on top of them, and its scope is agreed in writing before work starts.
Release review and upgrade plan
We compare your running APISIX version with the target release on the downloads page and the project's release notes, then list the changes that affect your deployment mode, enabled plugins and configuration. The output is a written upgrade plan with the target version, the order of components, and the items that need your decision. Confirm with your team which release line you intend to follow, because the downloads page does not mark any release as long-term support.
Staging upgrade and regression testing
We rebuild a staging environment that mirrors production and upgrade it first. Regression tests replay representative requests across routes, consumers and plugins, including authentication flows such as openid-connect and key-auth, and compare status codes, headers and latency with the baseline. Failing cases are reported with the route, plugin and configuration that caused them. Ask for the list of test cases and the traffic sample used, since regression coverage is only as good as those inputs.
Production rollout with rollback steps
The production rollout follows the approved plan in a defined sequence, with a check after each node. Each step has a rollback procedure written before the change, covering the previous package or image, the configuration snapshot, and the conditions that trigger a rollback. We confirm that health-checked upstreams and load balancer targets stay healthy during the rolling restart. Ask how rollback is tested in staging, not only described.
etcd version and backup checks
In traditional and decoupled modes, etcd holds all route and plugin configuration, so its version and health must be checked before and after the APISIX upgrade. We verify the etcd cluster version and quorum, confirm that backups run and restore to a test cluster, and review etcd authentication and TLS settings. Standalone deployments have no etcd, so this package applies only to the modes you run. Confirm the etcd version compatibility with the APISIX release notes before scheduling.
Ingress Controller upgrades on Kubernetes
The APISIX Ingress Controller is a separate project with its own release line, so it is upgraded on its own plan. We check the controller version against the gateway version, review the Kubernetes resources it reads and writes, and test the change in a non-production cluster before the production rollout. Where existing ingress runs alongside APISIX, we confirm that traffic routing does not change during the controller restart. Ask which Kubernetes versions your cluster provider supports.
Runbook handover
The engagement ends with a runbook written for your operations team. It covers the upgrade procedure, rollback steps, etcd backup and restore, health checks, Admin API access controls on port 9180, and the escalation path for incidents. We walk your team through the runbook and record who performed each step. Ask for the runbook format and whether it is stored in your own repository.
What makes an APISIX upgrade larger or smaller
This table lists the factors that move the effort of an APISIX upgrade up or down, with the reason each one matters and how to keep it manageable. Read each row as a lever you control before the upgrade window opens. The main takeaway is that fewer custom plugins, fewer unused routes and documented configuration as code shorten the test cycle more than any single platform setting.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| Gateway nodes and environments | Every node and every environment (dev, test, staging, production) must be upgraded, tested and rolled back in a defined order, so effort grows with the count of both. | Standardize node images and environment configuration, and confirm the rollout order and rollback path with your team before scheduling. |
| Deployment mode | Traditional, decoupled and standalone mode each change where configuration lives and which components restart, so the upgrade runbook differs for each. | Document the mode in use and keep one runbook per mode. Confirm component restart behavior against the deployment modes documentation. |
| Size and age of the etcd cluster | Larger or older etcd clusters need more careful backup, member-by-member handling and data compatibility checks before and after the upgrade. | Take a verified snapshot before each change, keep the cluster healthy, and confirm the etcd version support with the APISIX release notes. |
| Custom Lua and plugin-runner plugins | Custom code must be retested against each new APISIX release, and plugins built on internal APIs may break without warning. | Keep custom plugins few and small, track their dependencies, and run them in a staging environment on the target release before production. |
| Built-in plugins in use | The project documents more than 100 built-in plugins, and each one enabled in production is a behavior that must be regression-tested after an upgrade. | Enable only the plugins you need, remove unused configuration, and keep a list of enabled plugins with their settings per route. |
| Identity integrations such as openid-connect | Authentication flows depend on identity provider settings, redirect URIs, token handling and PKCE or client credentials behavior, all of which need end-to-end testing. | Test each flow (authorization code, client credentials, introspection) against your identity provider after every upgrade, and record the provider configuration as code. |
| Kubernetes Ingress Controller use | The Ingress Controller is a separate project with its own release line, so upgrading the gateway does not automatically upgrade it and the two must be matched. | Track the compatibility of gateway and controller versions in the release notes, and upgrade them in a planned sequence. |
| Number of version gaps crossed | Skipping several releases means more changed defaults, deprecated settings and configuration format changes to review at once. | Upgrade in small steps along the release line where possible and read the release notes for every version crossed. |
| Configuration as code and documentation | Without declarative configuration, teams must rediscover routes, consumers and plugin settings by hand, which slows testing and diffing. | Keep routes, consumers and plugin settings in version-controlled files, and run a comparison of configuration before and after each upgrade. |
How an upgrade moves from release notes to production
This sequence turns a new APISIX or Ingress Controller release into a tested, reversible change in production, with a written output at each phase. It keeps the decision to upgrade, the regression evidence and the rollback path visible to the people who approve the change.
Review release notes and dependency compatibility
Read the release notes for APISIX and the APISIX Ingress Controller, then check the etcd and plugin compatibility notes against your current versions. Confirm the project's support window and release cadence in the release notes and the downloads page before you schedule anything, because the downloads page does not mark releases as long-term support. The output is a short written decision that names the target versions, the breaking changes that apply to your deployment, and any plugin or etcd version that must move first.
Inventory routes, consumers, plugins and custom code
Export the current state from the Admin API or from your configuration files, depending on whether you run traditional, decoupled or standalone mode. Record every route, upstream, consumer, plugin configuration and any custom Lua, plugin runner or WebAssembly code, and note which items depend on a deprecated or changed field. The output is a versioned inventory that the staging test can be checked against, so a missing route or plugin shows up as a finding rather than as a production incident.
Upgrade staging and run regression tests
Build a staging environment that matches production in deployment mode, etcd topology and plugin set, then apply the target versions there first. Run the regression suite against the inventory: routing for each protocol you serve, authentication flows, rate limits, health checks and any custom plugin behavior. The output is a test report with pass and fail results per route and plugin, and every failure is either fixed in configuration or code or accepted in writing by the owner of that API.
Rehearse the rollback
Before the production window, practice reverting the staging environment to the previous APISIX, Ingress Controller and configuration state. Confirm that you hold a current backup of the etcd data or the standalone configuration file, that the previous package or image is still available, and that someone outside the platform team can run the steps from the runbook. The output is a timed, documented rollback procedure with its exit criteria, signed off by the change owner.
Execute the production change in an agreed window
Schedule the change in a window that your service owners and on-call staff have approved, and upgrade the components in the order set by the compatibility review, usually the etcd and control plane before the data plane nodes. Apply the change in stages and run the smoke tests after each stage. The output is a change record with the versions deployed, the time of each stage and the smoke test results, and a clear decision point at which the team either continues or triggers the rollback.
Monitor after the change and close out
Watch error rates, latency, upstream health, authentication failures and etcd health for the period set in your change plan, comparing them with the baseline captured before the change. Review gateway logs for plugin warnings that the regression suite did not cover. The output is a closure note that states the final versions, any issues found and their fixes, the updated inventory and the date of the next review against the project's release line.
Which upgrade tasks teams keep in-house and which they outsource
This table compares eight recurring APISIX upgrade and support tasks, the skill each one needs, and whether a small internal team usually covers it or a partner is worth scoping. Read each row as a decision about where your reliable capacity sits, not as a verdict on your team. The main takeaway is that routine change execution often stays internal, while etcd recovery, plugin regression and Ingress Controller rollouts are the rows where a partner's experience tends to pay off.
| Upgrade task | Skill it needs | Usually covered by |
|---|---|---|
| Reading APISIX release notes | Linux and NGINX operations, plugin and Admin API knowledge | Small internal team |
| Staging tests of a new release | Linux and NGINX operations, test automation for routes and plugins | Internal team, partner if no staging parity exists |
| Production change execution | Linux and NGINX operations, change control practice | Internal team with a documented rollback |
| etcd backup and restore checks | etcd administration, backup tooling, disaster recovery drills | Partner worth scoping if no one has run a restore |
| Admin API key and access reviews | Security review, Admin API configuration on port 9180 | Internal security team, with a partner for an independent review |
| Plugin regression tests for custom Lua or plugin-runner code | Lua or plugin-runner development, API testing | Partner worth scoping for custom plugins; internal for stock plugins |
| Kubernetes Ingress Controller rollouts | Kubernetes, Helm and ingress resource mapping | Partner worth scoping if the cluster team is small |
| Incident response and on-call | Linux and NGINX operations, etcd administration, Kubernetes | Internal on-call rota, with a partner for escalation cover |
What usually goes wrong when APISIX is upgraded in production
Most APISIX upgrade problems are not caused by the new release itself. They come from plugins, configuration and supporting components that were never tested against the target version, or from steps that were skipped because the gateway was already serving traffic. The cards below cover the failures we see most often and the prevention step for each.
Custom plugins break on a new release
Custom Lua plugins and plugin runner code depend on internal APIs that can change between releases, so a plugin that loads on the old version may fail or silently skip logic on the new one. Before any upgrade, run every custom plugin against the target version in staging, and check the release notes for changes to plugin interfaces. Pin the exact APISIX version in your deployment so the target is deliberate.
Configuration uses deprecated fields
Route, upstream and plugin configurations written against an older schema can rely on fields that are deprecated or renamed. The gateway may accept them on the old version and reject or ignore them after the upgrade, which changes routing without an obvious error. Export the current configuration, validate it against the target release, and fix deprecated fields in version control before the change window.
etcd version and data layout not planned
In traditional and decoupled modes, APISIX stores its configuration in etcd, so the etcd version and data layout are part of the upgrade, not a separate task. Confirm which etcd versions the target APISIX release supports, take a verified snapshot, and upgrade etcd in a planned order with a tested restore path. Ask your APISIX support provider to confirm the etcd requirements for your target version.
Admin API left exposed after a change
In traditional mode, the Admin API listens on port 9180, and configuration changes made during an upgrade, such as a new listener or a rebuilt container, can expose it on a network it should not reach. Confirm after every change that port 9180 is bound only to the management network, that default keys have been replaced, and that access is restricted. Include this check in the post-upgrade verification list.
Ingress Controller and gateway versions drift
The APISIX Ingress Controller is a separate project with its own release line, so upgrading the gateway without the controller, or the reverse, can leave the two out of step. Record the gateway and controller versions together in your change record, check the compatibility statement for each release pair, and upgrade them in a sequence agreed in advance. Confirm the supported pairing with the project documentation before you plan the window.
Rollback path never rehearsed
A rollback plan that has never been run is often the step that fails first. Restoring a previous container image, reverting a configuration commit or restoring an etcd snapshot each has its own dependencies and timing. Rehearse the full rollback in a staging environment that mirrors production, record how long it took and what needed manual work, and keep the rehearsed steps with the change record.
No owner for the release watch
Upgrades get delayed or skipped when nobody is accountable for tracking new releases, security notices and deprecation announcements. Assign a named owner for the release watch, set a regular review of the APISIX downloads page and project announcements, and decide in advance who approves an upgrade and who tests it. Ask any support provider to state in writing which of these tasks they carry and which stay with your team.
What recurring upkeep and support cost after go-live
The cost of running APISIX after go-live is mostly recurring, and it is easy to underestimate because the one-time migration or build work is what gets quoted first. Once the gateway is live, the ongoing bill comes from five places: infrastructure kept for staging and a rollback copy, hosting and backups for the etcd cluster that stores routes and plugin configuration in traditional and decoupled deployments, staff time spent watching releases and running upgrade windows, testing effort for each release, and either internal skills or a support agreement. Ask your team to name the owner for each of these before go-live, because costs that have no owner tend to be absorbed silently by whoever is on call.
Separate one-time work from recurring upkeep when you compare options. One-time work includes the initial deployment, route and consumer design, authentication setup, observability wiring and any cutover from an existing gateway. Recurring upkeep includes tracking the release line, reviewing release notes for changes to plugins and configuration, applying patch and minor upgrades, re-running regression tests against your routes and custom plugins, and restoring etcd from backup when something goes wrong. The recurring part grows with the number of custom plugins, the number of environments and how often your organization requires a change to pass review. Ask for the two figures separately in any quote so you can see what continues after the project closes.
If you buy a support agreement, read its scope closely rather than comparing headline hours. A typical agreement describes response scope (which incident severities are covered and how they are triaged), named exclusions (often custom plugin code, third-party plugins, unsupported modifications and issues caused by the underlying infrastructure), the number of upgrades included, whether your own Lua, plugin runner or WebAssembly code is covered, and the business hours during which the response commitments apply. Confirm whether an upgrade count includes the testing and rollback support around each upgrade, or only the act of changing the version. Where any of these points is unclear, get the answer in writing before signing.
DeployOpen does not publish a price list. A quote follows from written scope, so the useful request is a written scope that lists the environments, the number of custom plugins, the etcd topology, the release cadence you want to follow, the testing you expect to be performed for each release, the response expectations and the business hours. If you are also weighing API7 Enterprise, note that the vendor does not publish prices on its enterprise page. The commercial difference between an Apache-2.0 deployment you run yourself and a commercial APISIX-based product belongs in the cost-of-ownership comparison, where infrastructure, people, support and feature differences can be set side by side over the same period.
Before you approve the recurring budget, confirm three things with your own team: who will perform each upgrade and who approves it, where your staging and rollback copies will run and what they cost in your environment, and how long your change process needs to release a version update. Confirm the current release status and support position for any APISIX or Ingress Controller version directly from the official downloads page and project documentation at the time you decide, since release status changes over time and should not be assumed from older material.
How upgrades differ by deployment mode and environment
In traditional mode, the data plane and control plane run together on the same APISIX nodes, so one upgrade replaces both roles on each node. The Admin API listens on port 9180 and client traffic on port 9080, and both must respond after each node restarts. Because nodes carry live traffic, the upgrade is a rolling sequence rather than a single cutover.
- Node rollout: Upgrade one node at a time behind your load balancer so the remaining nodes keep serving traffic.
- Admin API checks: After each restart, confirm that port 9180 responds and that routes, consumers and plugins load without errors.
- Client traffic checks: Send test requests to port 9080 for representative routes, including routes that require authentication.
- etcd compatibility: Confirm in the release notes which etcd versions the target APISIX version supports, and check your cluster against that list before you start.
- Rollback path: Keep the previous package and a configuration backup so a node can return to the prior version.
Before the first node changes, confirm that your load balancer health checks remove a restarting node from rotation, and test that behavior in a non-production environment.
In decoupled mode, data plane nodes and control plane nodes are separate, and both depend on one shared etcd cluster. The control plane writes configuration that the data plane reads, so the two planes are upgraded in a planned order rather than at the same moment on every host. The order and the length of any mixed-version period are the decisions that shape the change window.
- Plane order: Use the release notes for your target version to decide whether the control plane or the data plane moves first, and record that order in the change plan.
- Shared etcd health: Check cluster health and take a verified backup before the first node changes, because both planes depend on the same data.
- Mixed-version testing: Rehearse a window in staging where one plane runs the new version and the other still runs the old one.
- Admin API access: Limit which systems can reach the control plane Admin API during the window so configuration writes are controlled.
- Data plane groups: Move data plane nodes out of rotation in small groups, and confirm each group reconnects to etcd before the next group starts.
Confirm mixed-version behavior in staging before you schedule the production window, and document which plane you upgrade first and why.
In standalone mode there is no etcd. APISIX reads its configuration from conf/apisix.yaml or conf/apisix.json, checks that file for changes every second, and hot reloads without a restart. A change to the file therefore reaches every node that reads it within moments, so configuration changes are the main upgrade risk, and the binary change is secondary to them.
- Version the file: Keep the configuration file in source control so each release has a known baseline and a reviewable diff.
- Validate before deploy: Load the same file in a test environment with the target APISIX version before it reaches production nodes.
- Canary delivery: Apply the file to one node first, confirm that routes respond as expected, and then roll it to the others.
- Pause automatic sync: Stop any automated file delivery during the binary upgrade so that a partial change cannot reach every node at once.
- Separate the two changes: Test the new binary with the existing file and the updated file as separate steps, so you can identify which change caused a fault.
Before you begin, confirm that your sync tooling can be stopped and that the last known good file can be restored before you change the binary.
When APISIX runs as a Kubernetes ingress through the APISIX Ingress Controller, the controller is a separate project with its own release line. Upgrading the gateway does not upgrade the controller, and the reverse is also true. The version pairing between the two must be confirmed in the official documentation for each target, and the downloads page lists the current releases of each component.
- Separate change records: Track the gateway and the controller as two upgrade items, each with its own version, approval and rollback step.
- Pairing confirmation: Confirm the supported gateway and controller combination before you schedule either upgrade.
- Custom resource changes: Review custom resource definition changes in the controller release notes and apply them before the controller pods restart.
- Chart and manifest diffs: Compare Helm values or manifests between versions so changed defaults do not reach production unnoticed.
- Resource mapping check: After the controller restarts, verify that Kubernetes resources still map to the expected routes on the gateway.
Run the full sequence in a non-production cluster that uses the same ingress classes and resource definitions, and confirm the version pairing there before you change production.
In air-gapped environments, nodes cannot pull packages, images or plugin dependencies from public sources during the upgrade. The steps match the connected modes, but every artifact must already be inside your boundary before the change window opens. The preparation work, including media transfer and approval, usually takes longer than the upgrade itself, so it should start early.
- Mirror inventory: List every package, container image, chart and plugin dependency that the target version needs, and mirror each one into internal repositories.
- Integrity checks: Verify mirrored artifacts against the publisher's published checksums or signatures before they enter the network.
- Offline rehearsal: Run the complete upgrade in an isolated test environment that can reach only the mirrored sources.
- Hidden fetches: Confirm that the plugins and runners you use do not download components at start-up.
- Transfer approvals: Ask your security team to confirm the media transfer and approval steps, and schedule them ahead of the window.
Confirm that the mirror is complete by performing a clean offline install from it before the change window, and keep a record of the artifacts used.
What your team needs to provide before an upgrade or support start
The fastest way to start an APISIX upgrade or support engagement is to have the inputs ready before the first working session. The most important is a current inventory of routes, upstreams, consumers and plugins, exported from the Admin API or from the configuration files that drive your deployment. If your gateway runs in file-driven standalone mode, the source of truth is the YAML or JSON file under conf/. If it runs in traditional or decoupled mode, export the configuration through the Admin API on port 9180 and keep the export with a timestamp. Without this inventory, nobody can say which plugin versions a change touches or which consumers would be affected by a plugin behavior change.
Your team also needs to supply access to a staging environment that mirrors production closely enough to test upgrades, plus a documented path into production for the change window. Confirm who holds the credentials for the Admin API, whether the Admin API key has been changed from its default, and how those credentials are rotated. For the etcd cluster in traditional and decoupled deployments, provide the existing backup and restore procedure, the location of recent snapshots and the last date a restore was rehearsed. Ask your platform team to confirm that a restore has been tested on a non-production copy. Snapshot files that have never been restored are not evidence of recoverability.
Authentication is the area most often missed. If the openid-connect plugin or other auth plugins such as key-auth, jwt-auth, ldap-auth or forward-auth protect your APIs, provide the identity provider settings the plugin depends on: issuer, client identifiers, redirect URIs, the flow in use (authorization code, client credentials or introspection) and any PKCE configuration. Where the identity provider is Keycloak, Auth0, Microsoft Entra ID, Google or Okta, confirm the current administrator contact and whether client secrets are scheduled for rotation during the same window. A plugin upgrade that changes how tokens are validated can break sign-in for every consumer at once, so these settings must be in hand before testing begins.
If the APISIX Ingress Controller runs in your Kubernetes clusters, provide read access to the relevant namespaces and the Helm values or manifests used for installation, along with the cluster version and the ingress resources currently mapped to APISIX. Name the owner of each cluster. Then name one accountable owner who approves change windows and can make a go or no-go decision during an upgrade. This person should be able to speak for the API owners and the security function. Agree in advance how emergency changes are approved, because a security advisory may require a patch outside the normal schedule.
Finally, decide the support window and response expectations before signing the written scope. Record the hours your teams need coverage, who may raise an incident, how severity is classified and how quickly you expect an initial response. Confirm whether your organization needs upgrades on a fixed cadence or only when a vendor or project release addresses a risk you have assessed. APISIX releases on its downloads page are not marked as long-term support, so your upgrade policy should state how far behind the current release line you are prepared to run. DeployOpen keeps your environments, configuration and data inside your own infrastructure throughout, and those systems remain under your ownership and control.
Questions buyers ask before hiring a partner for APISIX upgrades
How much does an APISIX upgrade or support agreement cost?
The cost follows from the written scope. DeployOpen does not publish a price list, so a quote is prepared once the scope, deliverables and environments are agreed. The main cost drivers are the number of gateway nodes and environments, whether etcd is clustered and must be upgraded in step with APISIX, how many custom plugins and identity integrations need retesting, whether the APISIX Ingress Controller is in scope, and how many change windows the work requires.
What is one-time and what recurs: the upgrade itself is usually a one-time, fixed-scope engagement. Ongoing support, release watch and upgrades on a regular cycle are normally a recurring retainer.
Ask the quote to show: the work items, who performs each one, the test evidence produced, the rollback plan, and what happens if the scope changes.
How long does an APISIX upgrade take?
It depends on scope, so no fixed duration can be given before the work is defined. The time is driven by the number of gateways, the etcd topology, the count of custom plugins and authentication flows that must be retested, the gap between your current version and the target release, and the change windows your organization allows. Plugin behavior and configuration are the parts most often underestimated.
The current release line matters for planning. APISIX 3.19.0 was released on September 28, 2026, and the downloads page does not mark any release as long-term support, so confirm the support window for your chosen version with the project and in your own agreement before you schedule the work.
Ask for a written plan that states phases, test gates, the rollback point for each phase and the expected duration of each phase.
Can our own team upgrade APISIX without an outside partner?
Yes, for routine patch and minor upgrades, provided the team is trained on APISIX, etcd and the plugins in use. A major jump, a change to the deployment mode, or a Kubernetes ingress change usually needs more planning and deserves a second set of eyes.
An internal team that handles upgrades on its own should have:
- A release watch: someone subscribed to release announcements who reviews changes to plugins and configuration each cycle.
- A staging copy: a non-production environment with production-like routes, consumers and plugins.
- Documented rollback steps: tested procedures for reverting the gateway and the etcd state, with a named owner who can execute them.
- Regression checks: scripted tests for authentication, rate limits and key routes.
If any of these is missing, an outside partner can supply it as part of a fixed-scope engagement.
What do we need to give a partner before an APISIX upgrade?
The partner needs an accurate inventory, access to the environments, and named owners who can make decisions. Without these, the scope cannot be fixed and the quote will carry more risk.
Inventory: the APISIX version, deployment mode (traditional, decoupled or standalone), etcd cluster layout, routes, upstreams, consumers, enabled plugins, custom plugins and their language or runner, and any Ingress Controller resources.
Access: read access to configuration and logs in staging and production, a staging environment that matches production, and access to your change management system. Access should follow your own security policy and the principle of least privilege.
Owners: one business owner for each API, one platform owner for the gateway and etcd, and a security contact who approves changes to authentication and access control.
Does DeployOpen's support cover the APISIX Ingress Controller?
It can, but only if the written scope says so. The APISIX Ingress Controller is a separate project from the gateway, with its own release line. The downloads page lists the APISIX Ingress Controller 2.2.0, released on August 18, 2026, and it is versioned independently of APISIX.
Because the two release on different schedules, the agreement should name both components and their versions. Ask whether upgrades cover the Ingress Controller, the Kubernetes resources it manages, the custom resource definitions it depends on, and the Helm or manifest deployment in your cluster.
If the Ingress Controller runs alongside an existing ingress, ask how traffic is split between the two during the upgrade and who owns the cutover decision.
How do we tell if a support agreement covers custom plugins?
Check the agreement for a named list of plugins, not a general reference to "APISIX support." Custom plugins sit outside the upstream project, so a standard gateway upgrade does not automatically test them.
Look for these items in writing:
- Inventory: each custom plugin listed by name, version and implementation language.
- Runner or runtime: whether the plugin is written in Lua, runs through a Java, Go or Python plugin runner, or is WebAssembly, and which runtime versions it supports.
- Testing: the test suite that runs on each upgrade and who maintains it.
- Changes: whether fixes to a custom plugin are in scope, and how changes to it are approved.
If a plugin is not on the list, assume it is not covered until the agreement says otherwise.
Which APISIX release should we run after go-live?
Choose a release that your organization can support for the length of its planning cycle, and confirm the support window in writing before you commit. The APISIX downloads page reports the 3.19.0 release, released on September 28, 2026, and does not mark any release as long-term support, so a single version cannot be assumed to receive fixes indefinitely.
Plan on a regular upgrade cadence rather than a one-time install. Read each release note for changes to plugin behavior, configuration fields and etcd requirements. Test the upgrade in staging against your own routes and plugins before production.
Ask your partner which version they will test against, how long they will keep that version in their test matrix, and how they will notify you when a release is no longer supported.
What breaks most often during an APISIX or etcd upgrade?
Most failures come from configuration and dependencies rather than from the gateway binary itself. Common causes include plugin configuration fields that change between versions, custom plugins compiled against an older runtime, identity provider settings that expire or change, and etcd version or cluster changes that disturb the configuration store.
Checks that catch most of these:
- Validate the configuration against the target version in staging before the change window.
- Run authentication flows end to end, including token introspection for machine clients.
- Confirm the Admin API on port 9180 is restricted to the expected network and that the change does not expose it.
- Verify the etcd cluster is healthy before and after each step, and keep a tested backup of its state.
- Confirm the rollback procedure returns both the gateway and the configuration store to a known state.
How DeployOpen scopes, upgrades and hands over APISIX support
DeployOpen plans and performs Apache APISIX upgrades and support inside your own infrastructure, from a written scope agreed before work starts. Each change to the gateway, its plugins and its Ingress Controller is tested against your routes and then documented for your team to run.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any upgrade work begins.
- The written scope lists the APISIX and Ingress Controller versions covered, the deployment mode, and the plugins and routes in use.
- Ask the vendor for the current release status of your target version before choosing the upgrade path, since the downloads page does not mark releases as long-term support.
How we build
- Upgrades are rehearsed in a non-production environment that mirrors your routes, consumers, plugins and etcd topology.
- Plugin and configuration changes are tested against representative traffic, including authentication flows and rate limits.
- Rollback steps are written and rehearsed for the gateway nodes, the etcd cluster and the Ingress Controller before production changes.
How we hand over
- Handover includes updated configuration, a record of each upgrade, and the test evidence gathered for each change.
- Runbooks cover etcd backup, restore checks, Admin API access on port 9180 and the steps for applying future releases.
- Your team receives a walkthrough so it can run routine upgrades and recognize changes that need a new scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the written scope.
- A retainer can cover following the release line, testing plugin changes and reviewing etcd upkeep on a schedule you agree.
- Confirm with DeployOpen which responsibilities stay with your team, such as on-call response and vendor license terms.
