What this service covers and who it is for
Apache APISIX is released under the Apache License 2.0 (Apache-2.0) and is a top-level Apache Software Foundation project, so running the gateway carries no project license fee. The cost decision therefore turns on what surrounds the software: the infrastructure it runs on, the etcd cluster that stores its configuration in the standard deployment modes, engineering time for routes, plugins and upgrades, the support arrangement you choose, and any features that exist only in a commercial edition. Those items are where a multi-year figure will be won or lost.
This analysis tends to start from one of four triggers. A gateway pilot is moving toward production and someone needs a budget line. A renewal of a commercial API gateway is approaching and the team wants a credible alternative to compare against. The organization is choosing between self-managing APISIX and buying API7 Enterprise, which API7.ai sells as an APISIX-based product. Or a board or finance function has asked for a multi-year figure that covers the next three to five years of operation.
The short answer: many teams build the cost model in-house, because the inputs (current gateway spend, staffing, cloud pricing and the plugins they actually need) are internal knowledge. Teams often bring in an outside partner for the scenario analysis and the vendor comparison, where an independent view of what each option includes is useful. DeployOpen does not assume any partner relationship with API7.ai and does not publish vendor prices, so any commercial figure should come from the vendor in writing.
Before modeling anything, confirm three things with the vendor and with your own environment: the edition features you would need, the support terms and the upgrade policy that apply to each option. The release and support details for the open-source line are on the Apache APISIX downloads page, which does not mark any release as long-term support, so your own support assumptions need to be stated explicitly in the model.
What the cost of ownership work includes
The work produces a written evidence set that lets your team compare running Apache APISIX yourself against a commercial APISIX-based product. It is delivered under a fixed-scope written agreement that sets the deliverables before work starts.
Current-state gateway inventory
A catalog of every gateway in use, its routes, enabled plugins, upstream services, traffic volumes and environments such as development, staging and production. This inventory is the baseline for every cost line, because a route using a rarely needed plugin can drive a different support need than a simple proxy. Check that traffic figures come from your own logs, not estimates.
Infrastructure cost model
A model of the compute and network cost for gateway nodes, the etcd cluster in traditional or decoupled mode, load balancers and the observability stack that receives logs and metrics. It separates one-time setup from recurring hosting, and shows how node count changes with peak traffic and failover needs. Ask for the sizing assumptions behind each line.
People model by role and phase
A breakdown of who does the work in each phase: platform engineers, security reviewers, application teams writing routes, and whoever owns on-call and upgrades after go-live. It estimates effort per role for build, run and upgrade periods, so you can see which skills you already have and which you would need to hire or contract. Confirm the model against your own staffing, not a generic ratio.
Edition comparison checklist
A checklist that maps Apache-2.0 APISIX and any commercial APISIX-based edition against your requirements. Items include the plugins you rely on, Kubernetes ingress through the APISIX Ingress Controller, support hours and response scope, and the upgrade path between releases. Each requirement gets a written yes, no or unknown with the source of the answer.
Multi-year scenario workbook
A spreadsheet that projects infrastructure, people, support and licensing cost over several years under stated assumptions. It includes sensitivities for traffic growth, node count, staff turnover and support tier, so the range of outcomes is visible rather than a single number. Ask for every assumption to be editable and labeled with its owner.
Written decision memo
A memo that records the options considered, the cost and risk findings, the open questions and a recommendation with its conditions. It is written so that finance, security and engineering leads can each review the parts that concern them. Keep the memo as the record of why the choice was made when the gateway is reviewed later.
What drives the cost and the effort
This table lists the decisions that change what APISIX costs to run and build, why each one matters, and how to keep it contained.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of gateways and environments | Each gateway node and each environment (development, test, staging, production, disaster recovery) adds compute, certificates, monitoring and configuration to maintain. | Standardize one gateway image and configuration template, and promote the same artifacts across environments instead of hand-tuning each one. |
| Deployment mode | Traditional and decoupled modes run an etcd cluster that needs its own sizing, backups, upgrades and monitoring. Standalone mode removes etcd from the cost base but changes how configuration is versioned and delivered. | Confirm early whether file-driven standalone mode fits your change process and availability targets, since that choice removes an entire component from operations. |
| Number and complexity of plugins | Each enabled plugin is a configuration surface to test and an upgrade risk. Built-in plugins cover many needs, but combinations of traffic, security and observability plugins multiply test cases. | Inventory the routes and plugins you actually need, enable only those, and prefer built-in plugins before writing custom code. |
| Custom plugins (Lua, plugin runners, WebAssembly) | Lua plugins run inside the gateway process and need APISIX-specific skill. Plugin runners for Java, Go and Python and WebAssembly add runtime boundaries, packaging and version compatibility work for each language your team owns. | Limit custom plugins to one or two implementation languages your team already maintains, and keep each plugin covered by automated tests tied to the APISIX version in use. |
| Authentication scope (openid-connect and other plugins) | Integrating the openid-connect plugin with an identity provider such as Keycloak, Microsoft Entra ID or Okta requires client registration, scope and claim mapping, and testing of each flow your applications use (authorization code, client credentials, introspection, PKCE). | Start with the flows and applications in scope for the first release, and reuse one identity pattern across routes instead of defining a new one per API. |
| Kubernetes ingress through the APISIX Ingress Controller | The Ingress Controller is a separate project with its own release line, so it adds a second version to track, a second set of Kubernetes resources to map and separate upgrade testing. | Decide whether Kubernetes ingress is in scope for the first phase, and if so, pin compatible gateway and controller versions together in one test plan. |
| Compliance evidence needs | Assessors often ask for change records, access reviews for the Admin API, audit logs, TLS configuration and backup test results. Producing this evidence takes ongoing effort and tooling beyond the gateway itself. | Ask which controls your assessor will test and map them to gateway configuration and logging from the start, so evidence is collected as part of normal operations. |
| Edition features you must validate | Commercial editions built on APISIX, such as API7 Enterprise, may add lifecycle management and other capabilities. Each feature you rely on needs a validation step, and the open-source project does not provide the same packaged feature set. | List the lifecycle, management and support features your team needs, then ask each vendor in writing which ones are included, how they are licensed and what they cost. |
| Support and upgrade cadence | Upgrades follow the release line you choose. The downloads page does not mark any release as long-term support, so your team or a support provider must decide the upgrade rhythm, test each release and maintain etcd and plugin compatibility. | Agree a fixed upgrade cadence and test window, confirm in writing what a support agreement covers, and ask any vendor to state its support lifecycle for the versions you run. |
How the cost model is built
The sequence turns an open-ended question about running APISIX yourself or buying an APISIX-based edition into a written, sensitivity-tested multi-year comparison that your decision owners can sign off.
Confirm requirements and decision owners
DeployOpen interviews your platform, security, finance and procurement leads to list the traffic, protocols, authentication needs, compliance obligations and budget horizon the model must cover. Done when each requirement has a named owner and the decision makers and their approval path are written down.
Inventory current traffic, routes and plugins
Your current gateway configuration, route counts, upstream services, consumers, authentication methods and traffic patterns are catalogued, including any custom logic. Done when the inventory is a reviewed document that sizes the work and shows which features your estate depends on.
Define the options to compare
The team sets out the candidate paths: self-managed APISIX in traditional or decoupled deployment mode, self-managed standalone mode, and the commercial APISIX-based edition such as API7 Enterprise. Done when each option has a written description of its topology, operating responsibilities and support boundary.
Validate edition features against requirements
Each requirement from the first two steps is checked against the open-source release and each commercial edition, and vendor claims are confirmed in writing. Your procurement team sends a written quote request with the scope above. Done when every requirement is marked as met, partly met or unconfirmed, with the vendor's answer attached.
Build the multi-year model with sensitivities
The cost components (infrastructure, etcd and operations effort, staff time, support and licensing) are modeled per option over the agreed horizon, separating one-time from recurring costs. Sensitivity cases test the main drivers such as traffic growth, staffing and quoted terms. Done when the model is delivered as a working spreadsheet with its assumptions listed and each figure traced to a source.
Decide and hand over
The model and findings are reviewed with decision owners, a recommendation is recorded, and the assumptions, open questions and vendor commitments are handed to the team that will own the decision. Done when the decision is signed off and the owners know which figures need re-checking and when.
Recurring costs after go-live
This table lists the cost areas that continue after an APISIX gateway goes live, what each one pays for, whether it recurs, and what to request in a quote or check against your own records.
| Cost area | What is paid for | One-time or recurring |
|---|---|---|
| Gateway and etcd hosting | Compute, storage and network for APISIX data plane nodes and the etcd cluster in your cloud or data center. Ask for node counts, etcd member count and the sizing basis. | Recurring |
| Observability and log storage | Metrics, access logs and traces retained from the gateway and its plugins. Confirm retention periods and storage growth with your own traffic records. | Recurring |
| Load balancing and certificates | The load balancer in front of gateway nodes, TLS certificate issuance and renewal, and DNS. Check whether these are already covered by your platform team. | Recurring |
| Platform engineering and on-call | Staff time to operate routes, plugin configuration, incidents and access reviews. Compare against the hours your own team has available. | Recurring |
| Security reviews and plugin regression testing | Periodic review of Admin API exposure, plugin configuration and custom plugins, plus regression tests run before each upgrade. Confirm what the quote includes. | Recurring |
| Upgrades (APISIX 3.19.0, released September 28, 2026; Ingress Controller 2.2.0, released August 18, 2026) | Testing and rolling out new releases. The APISIX downloads page does not mark any release as long-term support, so confirm the support window with the project or vendor before budgeting upgrade cycles. | Recurring |
| Support subscriptions or retainers | Vendor or partner support hours, response commitments and upgrade assistance. Ask for the written service levels and what they cover. | Recurring, if chosen |
| API7 Enterprise license | Commercial license fees for the APISIX-based product. The vendor does not publish prices on its enterprise page, so the vendor quote is the only pricing source. | Recurring, if chosen |
| Training | Courses or workshops for engineers who will author routes, plugins and runbooks. Ask whether training is one-time or repeated for new hires. | One-time, with repeats for turnover |
What usually goes wrong in these comparisons
Cost comparisons between running Apache APISIX yourself and buying a commercial APISIX-based product often fail in predictable ways. The cards below name the most frequent gaps and the checks that prevent them.
Comparing marketing feature lists
Edition comparison pages list features in broad terms, and a checkmark can hide major differences in configuration, limits or support boundaries. Build a list of your tested requirements, such as the authentication flows, plugins and deployment modes you need, and verify each one against both editions before comparing prices.
Omitting etcd and on-call time
Traditional and decoupled deployments depend on an etcd cluster that stores APISIX configuration, and that cluster needs backups, upgrades, monitoring and recovery drills. Estimate the staff hours for these tasks and for on-call rotation, then add them to the self-managed column. Standalone mode removes etcd but changes how configuration is delivered and reviewed.
Undercounting upgrade and plugin testing
Each APISIX release and each custom plugin adds regression testing across routes, authentication and traffic policies. Ask your team to list the environments, test suites and sign-off steps for one upgrade cycle, and include the time for that work every year, not only at go-live.
Assuming commercial feature parity
A commercial product built on APISIX can add, remove or change capabilities relative to the Apache-2.0 release, and those differences may affect your design. Get written confirmation from the vendor of which features, plugins and interfaces are included, and test the ones your architecture depends on before you rely on them.
Ignoring custom plugin maintenance
Custom plugins written in Lua, through a plugin runner or as WebAssembly must be rebuilt, retested and redeployed when APISIX or the runtime changes. Record each plugin's owner, language, dependencies and upgrade test cases so that maintenance effort appears as a recurring line in the cost model.
Accepting a quote without term comparison
A single-year quote can look lower than a multi-year agreement while costing more over the period you plan to run the gateway. Compare the total across the same term, and ask how renewal increases, support levels, data export and exit terms are handled before you sign.
How the model changes by starting point
When the current gateway is NGINX, Kong or a cloud API gateway, the migration itself becomes a cost line that the other starting points do not carry to the same degree. The model is most sensitive to how long both gateways must run side by side.
- Route and plugin inventory: the effort depends on how many routes, policies and custom plugins exist and how many have no direct equivalent in APISIX.
- Parallel running: the cost of keeping two gateways, their certificates and their monitoring alive during traffic shifting.
- Authentication mapping: consumer and token logic that must be rebuilt or re-tested.
- Rollback capacity: the infrastructure held in reserve in case cutover must be reversed.
- Ask for: an estimate that separates one-time migration effort from the recurring cost of the old gateway's remaining term.
Where a Kubernetes platform already runs, the gateway cost shifts toward the people who operate the cluster. The Ingress Controller and its interaction with existing ingress resources change who is responsible for each change.
- Ingress Controller ownership: the APISIX Ingress Controller is a separate project with its own release line, so it adds an upgrade path to the platform team's calendar.
- Coexistence with current ingress: running APISIX alongside an existing ingress controller during transition adds configuration and testing work.
- Cluster operations: etcd, node upgrades and resource requests may already be covered by the platform team, which lowers the marginal cost.
- Policy as code: existing GitOps pipelines can absorb gateway configuration, but the mapping work is still billable.
- Ask for: which platform tasks are already staffed and which need a named owner.
A small team with no dedicated platform engineers carries the same gateway workload with fewer people who can absorb it. Support, training and out-of-hours coverage weigh more heavily in this case than infrastructure.
- Training: time for the team to learn the Admin API, plugin configuration and the deployment mode chosen.
- Support coverage: whether a support agreement or retainer is needed for incidents when no one is on call for the gateway.
- Upgrade discipline: scheduled upgrades that someone must own, test and roll back.
- Key-person risk: knowledge concentrated in one or two engineers, which is a cost to reduce through documentation and handover.
- Ask for: the support hours, response expectations and training content included in each option.
In regulated or air-gapped environments, the technology cost is often smaller than the evidence and offline maintenance work around it. The model adds lines for documentation, change records and disconnected upgrades.
- Evidence preparation: configuration baselines, access reviews and audit logging records that assessors will ask for.
- Offline upgrades: packaging and transferring releases, plugins and dependencies into networks without internet access.
- Testing in a controlled environment: staging that matches production closely enough to support change approval.
- Vendor documentation and attestations: what the commercial provider can supply for the organization's assessment, which should be confirmed in writing.
- Ask for: whether the quote covers offline upgrade packages and the evidence artifacts, and who signs off on them.
An organization with a commercial API gateway already has a renewal date, a contract and an internal habit of comparing them. The renewal terms, not a list price, set the baseline that APISIX must beat or match over the planning period.
- Renewal terms: the notice period, price escalation clauses and any committed volume that the new option must account for.
- Feature parity: the features the business relies on and whether they map to APISIX plugins or to a commercial edition.
- Exit costs: contract termination fees, data export effort and any integrations that depend on the current vendor.
- Overlap period: the length of time both products are paid for during the move.
- Ask for: a side-by-side model using the actual renewal quote, the current feature list and the planned overlap.
What you need to provide
A cost of ownership comparison is only as good as the inputs behind it. Before the workbook is built, the client should gather the current gateway contracts and invoices, including license, support and any usage-based fees, so that the baseline reflects what is actually paid today rather than list prices. Route counts, consumer counts, traffic volumes and the number of environments (production, staging, disaster recovery, development) drive node sizing and etcd footprint, so they should be exported from the existing gateway or its logs where possible.
Plugin and authentication inventories matter as much as traffic. List every policy the current gateway enforces, including authentication methods such as key authentication, JWT, LDAP or OpenID Connect, rate limits, IP restrictions, transformations and custom code. Each item affects whether APISIX covers it with a built-in plugin, needs a custom plugin, or needs a commercial feature. Also provide staff time records or role estimates for platform, security and application teams, plus hosting rates from internal chargeback or cloud accounts.
Support and uptime expectations, compliance obligations and the named decision owner round out the list. Record the response times and availability targets the business requires, any regulatory obligations that affect logging, retention or change control, and any vendor quotes already received, including what each quote excludes. If a figure is missing, do not guess it. DeployOpen records missing inputs as open assumptions in the workbook, labels each one with an owner and a date to confirm, and shows how the totals change when the assumption is resolved.
Questions buyers ask before comparing costs
Is Apache APISIX free to use, and what does that cover?
Yes. Apache APISIX is released under the Apache License 2.0, so the software itself carries no license fee for use, modification or redistribution under those terms. The cost of running it sits around the software: servers or Kubernetes capacity, the etcd cluster in traditional and decoupled modes, the people who build and operate routes and plugins, staff time for upgrades and testing, and any support agreement you choose. Confirm the license terms for any add-on or bundled component with the project and your legal team before you rely on them.
What does API7 Enterprise add and what does it cost?
API7 Enterprise is a commercial product from API7.ai that the vendor describes as a full API lifecycle management product based on Apache APISIX. Its published materials list deployment on bare metal, virtual machines, Kubernetes and cloud, but the vendor does not publish prices on that page. Ask the vendor for a written quote that lists the included features, support levels, deployment options and contract term, then compare those lines with the features you would otherwise build or buy yourself.
Does DeployOpen publish prices for APISIX cost models?
No. DeployOpen does not publish a price list, and a quote follows from the written scope. The scope names the deployment mode, the number of gateway nodes and etcd clusters, the plugins and identity integrations, Kubernetes use, support hours and upgrade cadence. Those inputs decide the quote, so share your traffic profile, environments and compliance constraints early. Ask for one-time build costs and recurring operating costs as separate lines.
How long does it take to build an APISIX cost model?
The duration depends on the agreed scope, which is written before work starts. A model that covers one deployment mode and a short list of plugins takes less work than one that compares a commercial edition across several environments, support tiers and multi-year periods. Ask for the work breakdown, the assumptions list and the point at which the model is handed over, so you can see what your team reviews and when. Do not plan around a duration until the written scope is agreed.
Can our own team build the APISIX cost model internally?
Yes. The checklist and workbook structure can be used internally, and many teams start there to compare their own costs against a quoted commercial edition. Your team will need current figures for infrastructure, staff time, support hours and upgrade effort, plus an agreed list of plugins and deployment modes to model. Internal work is most useful for the recurring cost lines, where small assumptions compound over the years you model.
Which factors change the APISIX cost comparison the most?
The biggest drivers are deployment mode, plugin and feature needs, Kubernetes use, support hours and upgrade cadence. Deployment mode sets how many components you run: standalone avoids etcd, while traditional and decoupled modes need a highly available etcd cluster. Plugin needs decide whether you build custom plugins or need features that a commercial edition may include. Kubernetes use adds ingress controller work, and support hours and upgrade cadence set recurring effort. Change one assumption at a time and watch which total moves.
How DeployOpen scopes and delivers this work
DeployOpen approaches Apache APISIX cost of ownership and editions by first writing down the cost components for your environment, then comparing self-operated APISIX with a commercial APISIX-based product on the same basis. The work runs inside infrastructure you control, with the figures you need for a decision agreed in writing.
How we scope
- Inventory your current gateway estate, traffic volumes, plugins in use and the teams that would run APISIX.
- Agree in writing which cost lines are in the model, such as infrastructure, etcd operations, staffing, support and licensing.
- Define the vendor options to compare, including the commercial APISIX-based product you are evaluating, against identical assumptions.
How we build
- Build a multi-year cost model in a spreadsheet you own, separating one-time costs from recurring costs.
- Test the feature differences you care about, such as authentication, Admin API controls and plugin coverage, against a running APISIX lab.
- Document each assumption with its source, and flag every figure that still needs a vendor quote or internal confirmation.
How we hand over
- Deliver the cost model, assumption register and feature comparison as editable files with a short walkthrough for your finance and platform leads.
- Record the open questions for each vendor, including licensing terms, support tiers and roadmap commitments, so procurement can send precise requests.
- Provide a decision summary that states what was tested, what was not tested and which results depend on your own environment.
How we support
- Offer a retainer to refresh the cost model when APISIX release lines, vendor pricing or your traffic profile change.
- Review the cost model against new APISIX releases, including the APISIX Ingress Controller, when your planning horizon requires it.
- Keep the model current through a retainer agreed in writing, with scope and frequency set at the start.
