What an APISIX implementation involves
An APISIX implementation puts the gateway into infrastructure you control and connects it to the services that receive client traffic. The work covers a deployment mode and its supporting components, including an etcd cluster in traditional or decoupled mode, or a file-driven configuration in standalone mode. It then covers the design of routes, upstreams and consumers, the authentication plugins that protect them, observability through logs and metrics, and a handover that leaves your team able to change routes and plugins without vendor help.
Most engagements start from one of three triggers. The first is a new API program that needs a single entry point, consistent authentication and per-client limits. The second is a Kubernetes platform that needs an ingress, where the APISIX Ingress Controller is a separate project that you install and map to your existing resources. The third is a move away from another gateway such as NGINX, Kong or a cloud API gateway, which adds an inventory of routes and plugins and a parallel run period. Each trigger changes how much of the design is new work and how much is translation of existing behavior.
Whether to build in-house or with a partner depends mostly on two skill sets: gateway configuration and the platform underneath it. A team that already runs etcd, understands Lua-based plugin configuration and owns its identity provider can plan and build the core deployment itself. A team without those skills, or one that must meet a fixed go-live date across several API domains, usually gains more from a partner that drafts the design and runs the build against a written scope. Confirm the Admin API exposure, etcd ownership and identity provider details with your own platform team before you decide.
What the work includes and what you receive
The rollout falls into a small set of work packages. Each one produces configuration, documentation or operating knowledge that stays with your organization after the engagement ends.
Deployment mode decision
APISIX supports traditional, decoupled and standalone deployment modes, and the choice shapes everything after it. Traditional runs data and control planes together, decoupled separates them over one etcd cluster, and standalone drops etcd in favor of a file or API-driven configuration. The architecture decision records the choice, the reasons, and what you must confirm about your network and change process.
Gateway and etcd installation
This package installs and hardens the gateway nodes and, where the chosen mode requires it, the etcd cluster or file-driven nodes. Work covers network exposure of client ports and the Admin API, TLS, service accounts, and host baselines. Ask whether your team will own the etcd cluster after handover and who patches it.
Route, upstream and consumer model
Routes, upstreams and consumers are designed as a versioned model rather than edited by hand in the Admin API. Configuration lives in source control with review and promotion between environments, so every change to a route or consumer has an author and a history. Confirm how your teams will request changes and who approves them.
Authentication plugin configuration
Authentication is configured per route or service using plugins such as openid-connect with your identity provider, key-auth or jwt-auth for machine clients. The work maps identity claims to consumers and tests both user and client flows. Confirm which identity provider, token lifetimes and client types apply before the build starts.
Observability wiring
Access logs, error logs, metrics and traces are connected to the monitoring and logging systems you already run. The package defines which fields are logged, how sensitive headers are excluded, and which alerts reflect gateway health. Confirm the destination systems and retention rules with your security and operations teams.
Runbooks and operator training
Runbooks cover routine changes, node replacement, etcd recovery, certificate rotation and rollback of a bad configuration. Training sessions walk your operators through these procedures on your environment. Ask for the training format and whether recordings and exercises are included in the fixed scope.
Separately scoped work
Custom plugins, migration from another gateway and Kubernetes ingress through the APISIX Ingress Controller are priced and scheduled as separate work when they are needed. Each one changes the effort, the risk and the test plan, so confirm whether any of them applies before accepting a fixed-scope quote.
What drives cost and duration
This table lists the decisions that most change build effort and recurring work for an APISIX rollout, with ways to keep each one contained.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Deployment mode and etcd topology | Traditional and decoupled modes depend on a clustered etcd that needs its own backup, monitoring and upgrade routine. Standalone mode removes etcd but moves configuration into files or API pipelines that you must version and promote. | Pick the mode against your availability target before design starts. Ask the partner to state whether etcd clustering is in scope and who runs its backups. |
| Number of routes, upstreams and consumers | Each route needs matching, plugin settings, upstream health checks and tests. Consumer counts drive credential issuance, key rotation and access reviews. | Group routes into reusable templates and plugin configurations. Inventory existing endpoints early so the count is known before the quote is finalized. |
| Identity providers and authentication flows | Each provider adds client registration, claim mapping and token validation. Flows such as authorization code with PKCE, client credentials and token introspection each need separate test cases. | Limit the first release to one or two providers. Use the openid-connect plugin consistently and defer LDAP, SAML or multi-auth paths unless an application requires them. |
| Custom plugins | Plugins written in Lua or through the Java, Go or Python runners, or as WebAssembly, need design, tests and upgrade checks against each APISIX release. | Prefer built-in plugins from the more than 100 available. Confirm any custom plugin need in writing before the build starts. |
| Number of environments and approval gates | Each environment needs its own etcd or configuration source, secrets and route set. Change approval steps add review time and evidence collection. | Keep configuration in one repository and promote the same artifact through environments. Agree which approval gates are mandatory before scoping. |
| Observability backends | Logging, metrics and tracing exporters each need configuration, dashboards and retention rules. Connecting to an existing stack is less work than building a new one. | Reuse the current log and metrics platform where it exists. Name the backends in the scope document rather than leaving them open. |
| Kubernetes integration | Running the APISIX Ingress Controller alongside existing ingress adds CRD mapping, RBAC, upgrade coordination and a second control path to test. | Decide early whether APISIX replaces or sits beside current ingress. Ask for the mapping of Kubernetes resources to routes in the quote. |
| Traffic and availability targets | Higher throughput and stricter availability need more gateway nodes, load tests, failover tests and runbooks. Rate limiting across nodes adds shared-counter design. | State peak request rates, latency expectations and failover requirements in writing. Ask the partner to size from measured traffic rather than estimates. |
| Compliance evidence needs | Assessors may ask for access logs, change records, Admin API restriction evidence and key rotation history. Collecting this evidence is design and build work. | Map evidence requirements to specific controls at scoping. DeployOpen prepares evidence but independent auditors issue any assessment result. |
| APISIX edition (Apache-2.0 or commercial) | Apache-2.0 APISIX is free to use but you staff its operation, support and feature gaps. A commercial product such as API7 Enterprise adds vendor licensing and support terms, and its pricing is not published on the vendor page. | Compare total ownership over several years before choosing. Request written license, support and feature terms from the vendor and include them in the same quote as the build. |
Project phases and what each produces
The sequence moves from understanding your traffic to a tested, documented gateway that your team can operate after handover.
Inventory APIs and traffic
We list the upstream services, routes, current authentication methods, plugins or policies in use, traffic patterns and the consumers that call each API. The output is a traffic and route inventory, reviewed with your application owners, that shows which endpoints need to move first and which need special handling.
Decide architecture and deployment mode
We compare the three APISIX deployment modes (traditional, decoupled and standalone) against your hosting, availability and change-control needs, and record the choice with the etcd plan where one applies. The output is an architecture decision record that your security and platform leads sign off before any build starts.
Build the non-production environment
We install APISIX and its dependencies in your non-production environment, following the chosen mode, and store all configuration as code in a repository your team controls. The output is a working build, a configuration repository with a documented deployment procedure, and a list of versions in use.
Design routes, consumers and authentication
We translate the inventory into route definitions, upstream settings, consumer groups and the authentication plugins each API needs, such as openid-connect, key-auth or jwt-auth. The output is a route and consumer specification with an authentication matrix that names the identity provider and the policy for each API.
Configure observability and security
We set up logging, metrics and tracing exports, lock down the Admin API on port 9180 and client access on port 9080 behind your network controls, and apply TLS and etcd access settings. The output is a configuration baseline and a monitoring setup, with the access rules documented for your operations team.
Test and accept the gateway
We run functional, authentication, failover and load tests against the non-production build and log every failed case with its fix. The output is a test report and an acceptance checklist that your owners sign before production change is approved.
Go live and hand over
We move traffic in the agreed sequence with a rollback path ready, then transfer the configuration repository, runbooks and operating procedures to your team. The output is a go-live record, a runbook set and a handover session, and the project closes when your operators have run the procedures themselves.
What teams keep in-house and what they outsource
This table shows, for each part of an APISIX rollout, whether the usual owner is the in-house team, a partner or both, and which skills each part needs.
| Work part | Usual owner | Skills each part needs |
|---|---|---|
| Gateway architecture | Partner, with in-house review | API gateway design, traffic patterns, deployment mode selection, network zoning and failure domain planning |
| etcd or standalone design | Shared | Distributed systems operations, etcd cluster sizing and backup, or file-driven configuration workflows for standalone mode |
| Route-as-code practice | In-house after handover | Git workflows, YAML or JSON configuration, CI validation and familiarity with NGINX concepts such as locations and upstreams |
| Identity integration | Shared | OpenID Connect and OAuth 2.0 flows, identity provider administration, client registration and consumer mapping |
| Plugin selection | Partner, then in-house | Knowledge of the 100-plus built-in plugin catalog, authentication and traffic control trade-offs, and plugin ordering effects |
| Observability | Shared | Log and metrics pipelines, dashboard and alert design, and the telemetry tooling already used by the organization |
| Kubernetes integration | Partner, then in-house | Kubernetes resources, Helm or manifest management, and APISIX Ingress Controller configuration alongside any existing ingress |
| Load and failover testing | Partner | Load test design, failure injection, health check tuning and interpreting results against agreed service levels |
| Ongoing platform ownership | In-house | Release tracking, upgrade testing, etcd upkeep, on-call response and change control for routes and plugins |
What usually goes wrong and how to prevent it
Most APISIX rollout problems are predictable and come from configuration, ownership and operations rather than the gateway software itself. Each card names a risk and the check that prevents it.
Admin API exposed on port 9180
In traditional mode APISIX serves the Admin API on port 9180, separate from client traffic on port 9080. If that port is reachable from application networks, the Internet or shared subnets, anyone who reaches it can change routes and plugins. Confirm in the plan that port 9180 is bound only to the management network and that firewall rules are tested from each zone.
Default keys left in place
A fresh APISIX configuration ships with example Admin API keys that are well known. Keeping them after go-live gives any reachable client full control of the gateway. The plan should include generating unique keys, storing them in your secrets manager, and checking the running configuration to confirm the defaults are gone.
etcd backup never restored
In traditional and decoupled modes, etcd holds all route, consumer and plugin configuration. A backup that has never been restored is an assumption, not a recovery plan. Ask for a documented restore procedure, a scheduled snapshot job, and a rehearsal in a non-production cluster that proves the gateway comes back with the expected configuration.
Routes with no owner or change record
Routes created by hand in the Admin API or dashboard often have no named owner, no description and no review. Over a year this produces shadow routes that nobody can explain. Require every route to carry an owner and ticket reference, and keep the desired state in version control so each change has a reviewable history.
Consumer mapping that ignores token claims
Mapping identity provider users or client IDs to APISIX consumers is where access errors hide. A claim that is renamed, a group that is nested, or a client credential reused across teams can grant access nobody intended. Test each mapping with real tokens from the identity provider, including denied cases, before any route goes live.
Plugin drift during upgrades
APISIX plugins change between releases, and a configuration that loads on one version may fail or behave differently on the next. Drift appears when test and production run different versions or when custom plugins are not rebuilt. Pin versions, keep a plugin compatibility test in the pipeline, and record the release line each environment runs.
Observability added after go-live
Logs, metrics and traces added late leave the first incidents without evidence. The plan should set access log format, metrics export and alert thresholds before traffic moves, so that routing errors, authentication failures and etcd health are visible from day one. Confirm which telemetry sinks your team already operates.
No tested rollback path
A gateway sits in front of every API, so a failed change can stop traffic broadly. Teams often plan a cutover but not a reversal. Require a written rollback for each phase, including how routes return to the previous gateway or prior configuration, and rehearse it in staging before the production window.
Apache-2.0 and commercial editions confused in budgets
Apache APISIX is released under the Apache License 2.0, while API7 Enterprise is a commercial product based on APISIX that the vendor sells with its own terms. Budgets that mix the two understate or overstate cost. Ask the quote to separate software licensing, vendor support, and the staff and infrastructure you carry yourself.
How the work changes by starting point
With no existing gateway, the work is mostly design and build. Nothing has to be inventoried or run in parallel, so the schedule depends on how quickly your teams agree on the API catalog, the authentication model and the deployment mode.
- Scope: deployment mode selection (traditional, decoupled or standalone), etcd cluster design if etcd is used, route and consumer design, and the first authentication plugin set.
- Effort: mostly one-time build work. Route and plugin configuration grows with each API onboarded, so ask how onboarding is priced in a quote.
- Readiness: the gateway can be verified against test APIs before any production traffic exists, which makes acceptance criteria easier to fix early.
- Decisions that move earlier: the identity provider and token model, the observability stack, and who owns route changes after go-live.
- Confirm: the APISIX release line you will standardize on, using the current downloads page.
When you replace NGINX, Kong or a cloud API gateway, the build is only part of the work. Existing routes, plugins and clients must be understood and moved without an outage, which is covered in the separate migration topic.
- Scope: adds route and plugin inventory, mapping of current authentication behavior, parallel running and a rollback path. Detailed steps sit in the APISIX migration from another API gateway topic.
- Effort: driven by the number of routes, the number of custom policies on the old gateway and how many consumers depend on them.
- Readiness: the new gateway is not ready until it reproduces the old gateway's behavior for each traffic class, so acceptance tests must come from production traffic patterns.
- Decisions that move earlier: which team owns cutover, how long the two gateways run side by side, and how traffic is shifted between them.
- Confirm: whether any old plugin has no direct APISIX equivalent and would need custom development.
On Kubernetes, the first question is whether APISIX replaces the existing ingress or runs beside it. The APISIX Ingress Controller is a separate project, and its installation and resource mapping are covered in the Ingress Controller topic.
- Scope: choice between replacing existing ingress and running alongside it, controller installation, and mapping of Kubernetes resources to APISIX routes.
- Effort: depends on how many ingress objects and annotations already exist and whether they map cleanly to APISIX configuration.
- Readiness: the cluster must support the chosen traffic path before application teams move, so ingress class separation and test namespaces matter.
- Decisions that move earlier: whether gateway configuration is managed through GitOps, who may change ingress resources, and how the etcd layer is operated inside the cluster.
- Confirm: the controller version compatibility with your Kubernetes version, using the controller's documentation and the current downloads page.
In a restricted or air-gapped network, every dependency must come from inside your environment. Package sources, container images, plugin dependencies and identity access are all provided internally, which changes the plan before the build begins.
- Scope: internal mirrors for packages and container images, an approach for updating them, and identity access reachable from the isolated network, such as an internal identity provider.
- Effort: typically higher during planning and verification, because each artifact must be transferred, checked and recorded. Ask a quote to show how those transfers are counted.
- Readiness: the gateway cannot be validated against external services, so test identity flows and dependencies must exist inside the network.
- Decisions that move earlier: the artifact transfer process, the approval path for new plugins, and the location of etcd and logging backends.
- Confirm: which APISIX artifacts and plugin dependencies your security policy permits, with your security team and the vendor documentation.
What you need to provide
Before a fixed-scope quote can be written, the client must supply a set of inputs. Each one changes the number of routes, plugins, environments and approval steps the work involves, so gaps here usually become change requests later. Start by naming the hosting targets and network zones where APISIX nodes and the etcd cluster will run, including whether the gateway sits in front of public, partner or internal APIs. Confirm the zones that must reach the Admin API on port 9180, which should be restricted to administrative networks only.
A traffic and API inventory with a named owner for each API is the largest effort driver. For every route, list the upstream service, expected methods and protocols (HTTP, gRPC, WebSocket or TCP/UDP), the current authentication method, rate limits, and the consumers that call it. Owners answer questions about behavior during cutover. Also provide the identity provider details (for example Keycloak, Microsoft Entra ID or Okta), client registrations, and the list of applications to protect, so the openid-connect configuration can be scoped.
Decide who owns the deployment mode and edition choice before estimating begins. Traditional, decoupled and standalone modes differ in etcd operations, scaling and failure handling, and the edition decision (Apache-2.0 APISIX or a commercial product built on it) changes support and licensing terms. Name the TLS certificate sources and renewal process, and the monitoring and logging systems that will receive gateway metrics and access logs, with the access credentials DeployOpen needs to connect them.
Finally, document your change approval rules and name the staff who will operate the gateway after handover. Know whether route changes need a ticket, a peer review or a change board, because that sets how work is batched and tested. Named operators determine how much knowledge transfer, runbook writing and shadowing is included, which directly affects the handover effort in the quote. Ask for these answers in writing, since each unanswered item is typically priced as a risk allowance or a later change.
Common questions before hiring outside help
What drives the cost of an APISIX rollout and what does a fixed-scope quote include?
Scope size drives most of the cost. The main inputs are the number of environments, routes, consumers, authentication flows, custom plugins and observability integrations. A fixed-scope quote is built from a written list of those items, the deliverables for each phase, the environments in scope and the acceptance criteria, so you can see what is included before work starts. Ask the quote to separate one-time work (design, build, migration, documentation, knowledge transfer) from recurring items (infrastructure you run, upgrades, support). It should also state what you provide, such as cloud accounts, identity provider access and named staff for reviews. DeployOpen does not publish a price list, so the figure follows from the written scope.
How long does an APISIX implementation take and what sets the timeline?
The timeline depends on scope and on how quickly access and decisions arrive. No single duration applies to every rollout. The main factors are the number of upstream services to onboard, how many authentication methods and identity providers are involved, whether custom plugins are needed, the deployment mode and etcd design, the number of environments, and whether you are also migrating from another gateway. Delays on your side, such as change approvals, network access requests and identity provider configuration, often move dates more than the build does. Ask for a phase-by-phase schedule in the written scope, with your dependencies named explicitly.
Can our own team implement APISIX without an outside partner?
Yes, a capable team can, if it has the skills to run the gateway after go-live. Plan for Linux and container operations, HTTP and TLS fundamentals, certificate management, and etcd operation for traditional or decoupled mode. Standalone mode needs disciplined configuration management for its YAML or JSON files. Engineers also need working knowledge of OAuth 2.0 and OpenID Connect flows, plus Lua or plugin-runner skills if custom plugins are needed. Test the gap honestly by listing who will own the Admin API, etcd backups, upgrades and on-call response. Partial help, such as a design review or a hardening pass, is often a narrower and cheaper scope than a full build.
Does Apache APISIX require a license fee under Apache-2.0?
The Apache-2.0 license does not charge a fee for using the open-source gateway. APISIX is released under the Apache License 2.0 (Apache-2.0). Costs still come from infrastructure, people, testing, support and upgrade effort. A commercial product built on APISIX changes the picture. API7 Enterprise, sold by API7.ai, is described by its vendor as a full API lifecycle management product based on Apache APISIX. The vendor does not publish prices on its product page, so ask API7.ai for licensing terms, support levels and the features included in each edition before comparing it with a self-run gateway. Confirm current terms in writing.
Which etcd setup or deployment mode should we choose for APISIX?
Choose by failure model, operating skill and the number of gateway sites. Traditional mode runs the data plane and control plane together, which is the simplest model for a single site. Decoupled mode separates the two planes, with both sharing one etcd cluster, and suits groups that need independent scaling. Standalone mode drops etcd and loads configuration from a YAML or JSON file or the Admin API. The file is checked every second and hot-reloaded, which fits GitOps-managed setups, but changes arrive through files or the API. Whichever mode you pick, plan etcd backups, restrict Admin API access on port 9180, and decide whether client traffic on port 9080 is exposed.
Does DeployOpen certify our APISIX setup for compliance?
No. DeployOpen does not issue audit reports, attestations or certifications. It prepares systems, controls and evidence for compliance assessments, such as configuration records, access settings, logging and change history for the gateway. An independent auditor or certification body decides the outcome. Ask the scope to name the framework, the controls mapped to the gateway and the evidence each control needs. Your compliance lead should confirm early which assessment applies to the gateway and who receives the evidence.
How DeployOpen scopes and delivers APISIX work
DeployOpen plans, implements, documents and supports Apache APISIX inside your own infrastructure, from the deployment mode and etcd design through route, consumer and authentication setup. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Written scope names the deployment mode, whether traditional, decoupled or standalone, and the reasons for it.
- We inventory the routes, upstreams, consumers and plugins that the gateway must carry on day one.
- The scope lists the identity provider, observability tools and environments the gateway must connect to.
How we build
- We stand up the gateway and its etcd cluster or standalone configuration in the environments you control.
- Routes, consumers and authentication plugins are configured from reviewed definitions, with changes tracked in version control.
- Traffic tests, failover checks and plugin behavior tests run against the agreed design before any handover.
How we hand over
- Deliverables include configuration records, architecture notes, runbooks and a record of the decisions made during the build.
- Your team receives documented procedures for Admin API access, route changes, certificate rotation and etcd backup.
- Handover sessions cover the operations your staff will run after go-live, with questions captured in the closing record.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
- Retainer scope should be confirmed in writing, including which APISIX and Ingress Controller releases are covered.
- Ask whether post-go-live changes to routes, plugins and identity settings fall inside or outside the retainer.
