Apache APISIX for SaaS and technology companies

Why a SaaS team puts Apache APISIX at its public API edge

A SaaS platform team that issues customer API keys, enforces plan tiers and fronts a growing set of LLM-backed endpoints usually finds that each service handles authentication, rate limits and logging on its own. A self-hosted Apache APISIX edge moves those controls to one layer the team operates. APISIX is released under the Apache License 2.0, is built on NGINX and etcd, and ships more than 100 built-in plugins covering authentication, traffic control, observability and AI gateway functions. Those plugins let the team attach key-auth, jwt-auth or openid-connect to routes, apply traffic limits per consumer, and send logs to one place, rather than rebuilding those checks in every service.

Choosing a deployment mode is the first decision. Traditional mode keeps the data and control planes together, decoupled mode separates them over a shared etcd cluster, and standalone mode drops etcd and loads configuration from a YAML or JSON file, which the team can keep in version control. Standalone mode suits teams that want configuration reviewed like code, while decoupled mode suits teams running several gateway fleets. Confirm which mode fits your release process before you write routes, because moving between modes later changes where configuration lives.

What changes for the team is where policy is written and reviewed. Plan tiers, consumer keys and limits become gateway configuration that engineering and security can review together. What stays in your infrastructure is everything that matters for audit: the gateway, etcd, the Admin API, access logs and the keys themselves, all running in cloud accounts or clusters you control. Ask your partner to confirm which logs leave the gateway, where they are retained, and who can read the Admin API, because those answers will feed your SOC 2 evidence later.

Choosing traditional, decoupled or standalone mode for a SaaS edge

Traditional mode runs the data plane and control plane together on the same nodes, with an etcd cluster holding the configuration. Every gateway node serves client traffic and exposes the Admin API, so the control surface and the traffic surface share hosts. For a SaaS edge this is the simplest model to start with, because routes, consumers and plugin settings are changed through one API and propagate through etcd.

Client traffic: APISIX listens on port 9080 for client requests.
Admin API: The Admin API listens on port 9180, so restrict it to internal networks and management paths.
etcd dependency: Configuration changes depend on etcd health, so plan its quorum and backups as part of the edge.
Multi-region: Each region usually needs its own etcd cluster, which adds replication and latency decisions to the design.
Operational coupling: Upgrading gateway nodes also means managing the control components on the same hosts.

Confirm with your own environment whether your security team accepts an Admin API on every edge node, and how your etcd cluster will behave across regions.

Standalone mode removes etcd entirely. Configuration comes from a YAML or JSON file, such as conf/apisix.yaml or conf/apisix.json, or from the Admin API on each node. For a SaaS team that manages configuration in Git and deploys through a pipeline, this model can match the release process closely, because the file is the source of truth on every node.

No etcd: There is no shared configuration store to operate, back up or keep in quorum.
File check interval: In file-driven mode APISIX checks conf/apisix.yaml or conf/apisix.json every second and hot-reloads changes without a restart.
Per-node consistency: Each node holds its own copy, so your pipeline must roll changes out to every node and verify they match.
Rollout risk: A bad file reaches every node that reads it, so validation and staged rollout matter more than in a shared store.
Dynamic changes: Using the Admin API in standalone mode changes node-local state, which must be reconciled with the file-based source of truth.

Confirm with your own environment whether your deployment tooling can distribute and validate files consistently across every region.

What SaaS customers and auditors require from the API edge

This table maps each requirement that SaaS customers, auditors and regulators bring to the public API edge to the gateway work it creates, including logging, change control and customer offboarding. Read each row as a question to answer in your design before the gateway is configured, since several requirements apply to the business as well as to APISIX.

Requirement	What it asks for	Build impact at the APISIX gateway
SOC 2 security common criteria (CC1 to CC9)	Controls over the system covering the control environment, logical access, system operations, change management and risk mitigation. These apply to every SOC 2 examination.	Route and plugin changes go through version control and review. Admin API access is restricted and logged. Consumer and key lifecycle is documented.
SOC 2 Type 1 versus Type 2 evidence	Type 1 covers the system description and control design as of a date. Type 2 adds an opinion on operating effectiveness over a period.	Keep gateway configuration history and change records for the whole observation period, not only at a point in time. Ask your auditor which samples they will pull.
Logging and monitoring for access decisions	Evidence that authentication, authorization and configuration changes are recorded and reviewed.	Define which access logs APISIX emits, where they are shipped and how long they are kept. Confirm that secrets and personal data are excluded from log fields.
GDPR Article 28(3) processor instructions	Where the product processes personal data for customers, processing must follow documented instructions and meet the Article 32 security measures.	Only the data the documented instructions allow should pass through or be logged by the gateway. Keep request and response logging scope aligned with the processor contract.
EU Data Act switching rights	Data processing service providers must let customers switch to another provider or to on-premises infrastructure, with notice and transitional periods set in Articles 23, 25 and 50.	Customer routes, consumer definitions and rate-limit policies should be exportable as configuration. Plan offboarding exports from the gateway and test them against the notice and transition periods in your contracts.
Data Act switching charges (from 12 January 2027)	From 12 January 2027, providers of data processing services may not impose switching charges. Before then, reduced charges may not exceed costs directly linked to switching (Data Act, Article 29).	Gateway configuration export and customer-specific key rotation should be cheap to run and documented. Confirm with counsel how the switching terms in your contracts interact with this date.
NIS2 for cloud and managed service providers	Cloud, data center, managed and managed security service providers fall under the high criticality sectors of Directive (EU) 2022/2555, with measures specified by Implementing Regulation (EU) 2024/2690.	Confirm whether your product falls under these categories. If it does, document gateway patching, access control, incident handling and backup of the APISIX configuration store as part of your security measures.

Which APISIX plugins and routes a SaaS edge needs

A SaaS public API edge combines customer credentials, customer sign-in, plan-based limits, usage records, AI routes and the control plane that governs them. Each component below is a separate configuration decision, and each one changes what your billing, support and audit teams can later prove.

Customer API keys and tokens

Use the key-auth plugin for long-lived customer API keys and the jwt-auth plugin for short-lived tokens issued by your own backend. Each customer or application maps to a consumer, so every request carries an identity your metering can attribute. Decide how keys are issued, rotated and revoked, and whether one consumer may hold several keys for separate environments. Confirm the consumer and credential fields in your plugin version before building the key lifecycle.

Customer OAuth with OpenID Connect

The openid-connect plugin lets customers sign in through an identity provider such as Keycloak, Auth0, Microsoft Entra ID, Google or Okta. For browser and mobile clients, plan the authorization code flow with PKCE. For server-to-server integrations, plan client credentials. Decide which claims map to tenant and plan, and how token introspection results are cached. Confirm which flows and options your APISIX version supports for each provider.

Per-plan rate limits with consumer groups

Rate limiting enforces the limits in each commercial plan. Consumer groups let you attach a plan's limit to every consumer on that tier, so upgrades change one group rather than every route. Choose the counting window, the response when a limit is hit, and whether limits are shared across gateway nodes. Test the behavior with multiple nodes running, because a counter kept per node will allow more traffic than the plan intends. Confirm how your version stores counters and whether it supports a shared backend.

Usage logs that feed metering

Billing depends on request records that are complete, consistent and attributable to a consumer. Use the logging and observability plugins to write one record per request with consumer, route, status and timing, then ship it to the system that aggregates usage. Decide which fields are excluded to keep customer payloads and secrets out of logs, and how dropped or retried log batches are reconciled against invoices. Discuss the design with finance before you pick a record format.

AI gateway routes for LLM endpoints

If your product calls or exposes language models, separate those routes from ordinary API routes so they can carry their own timeouts, body size limits and logging rules. The AI gateway plugins can route to upstream model providers and record token usage per consumer. Decide which prompts and responses are logged, how provider credentials are stored, and what happens when a provider fails. Confirm the AI plugin names, provider list and token-counting behavior in the version you deploy.

Admin API and etcd access controls

The Admin API changes routes, consumers and plugins, so it must never share a network path with customer traffic. Restrict it to administrators and automation, require strong credentials, and rotate its admin key. In traditional and decoupled modes, etcd holds the entire configuration, so limit its access, encrypt its traffic and back it up. Document who can change a consumer, since that change is also a record auditors will ask about. Confirm the default ports and admin key settings in your deployment mode before exposing any listener.

How a SaaS API edge rollout moves from pilot to production

The sequence turns an existing API surface into an APISIX edge in controlled phases, with each phase closed by a written scope, a rollback point and evidence the team can show to auditors and customers.

Inventory routes, keys and plan rules
Your team and the implementation partner list every public route, its upstream service, the authentication method each customer uses today, the API keys in circulation, and the rate limits and plan entitlements tied to each tier. The output is a written scope document that names which routes move first, which stay on the current gateway, and who owns each customer-facing contract. The step is done when the owners of each route have signed off on the inventory and the open questions about keys and plan rules are closed.
Stand up a non-production APISIX edge
The partner deploys APISIX in a non-production environment you control, using the deployment mode your platform team selects after reviewing the deployment modes documentation. Traditional mode, decoupled mode with a shared etcd cluster, and standalone mode with file-driven configuration each change how configuration is stored, reviewed and rolled back, so the choice is recorded in the scope. The step closes when admin access is restricted, configuration changes are versioned, and a test route returns traffic from a sample upstream.
Migrate one low-risk public API in parallel
Choose one read-heavy public API with a small set of customers and a well-understood upstream. Define the routes, authentication plugin and rate limit in APISIX, then send a copy of agreed traffic through both gateways and compare status codes, latency and response bodies. Traffic moves to APISIX only after the comparison is accepted in writing. The rollback point is the current gateway route, which stays live until the cutover is approved.
Move plan limits and key rotation
Translate plan-based rate limits and key handling into APISIX consumers, plugins and rotation procedures. Customers with existing keys keep working through a defined overlap period, and new keys are issued through a documented process. Your team confirms that each plan limit returns the expected response when exceeded, and that revoking a key blocks access at the gateway. Usage metering is checked against your billing source so that limits and invoices do not disagree.
Add AI routes behind controlled policies
For LLM-powered products, add AI gateway routes only after the core API path is stable. Define which model providers are approved, how requests are logged, what prompt and content guards apply, and how token usage is capped per customer. Test failover between providers with synthetic requests before any customer traffic uses them. The step is complete when the route definitions, guard settings and log destinations are documented and a test run shows each control triggering as designed.
Cut over traffic and retire the old path
Shift production traffic route by route, starting with the pilot API, using the routing and weight controls your chosen mode supports. Monitor error rates, latency, rejected requests and key-related support tickets during each window, and hold the previous gateway route ready until the owners confirm stability. Retire old routes only after the agreed review period, and record the change in version control so the final state matches the documented inventory.
Set up SOC 2 evidence collection
Define which evidence your SOC 2 examination will rely on for the gateway, such as access reviews for admin and consumer management, change records for route and plugin updates, log retention and alerting for authentication failures. Automate exports where possible and agree with your auditor which controls and periods they will test. DeployOpen prepares the systems, controls and evidence, but the examination and report come from an independent CPA firm, so the evidence list is confirmed with that firm before the first observation period starts.

Connecting per-plan limits to usage billing without mixing concerns

The gateway should enforce per-plan limits and record request data, while a separate billing system meters usage, applies pricing and produces invoices. Keeping these jobs apart means a rate limit change never requires a pricing change, and an invoice dispute never requires a gateway change. In practice, APISIX sets the limit for each consumer based on plan, rejects traffic above it, and emits request events. The billing platform consumes those events and decides what the customer owes. The design decision to make first is which system is the source of truth for plan entitlements, since both the gateway and the billing platform need to agree on them.

Lago is one open-source option for the billing side. Its platform is licensed under AGPLv3, while its agent SDKs and MCP server are MIT licensed in separate repositories, so the license of each component you deploy needs review by your legal team, especially if you modify the platform and offer it to users. Its Docker Compose deployment runs a front end, an API, an API worker, a clock worker, PostgreSQL for application data, Redis as the job queue and Gotenberg for PDF generation. ClickHouse is optional for high-volume events and disabled by default. Lago also needs a separate payment processor, such as Stripe, Adyen or GoCardless, so card and payment scope must be confirmed with that provider and your PCI DSS assessor before design starts. Lago's self-hosting guidance recommends pinning the last tagged version rather than the latest image tag, and that practice should be part of your change control.

How the APISIX edge supports SOC 2 evidence

A SOC 2 examination tests whether controls operate as described, and the public API edge is where many of those controls meet customer traffic. The cards below map the gateway decisions that auditors usually ask about, from access to keys and the Admin API to configuration changes and log retention.

CC6 access to keys and admin

CC6 covers logical access. For the gateway, that means who can change routes, consumers and plugins through the Admin API on port 9180 in traditional mode, and who can issue or revoke customer API keys. Document named administrator roles, restrict the Admin API to a management network, and test that revoked keys stop working. Ask your team to show how a departing engineer's access is removed in both the identity provider and the gateway.

CC7 system operations and logging

CC7 asks how you detect and respond to anomalies in system operations. The gateway's access logs, error logs and plugin-generated events should flow to a central store that your team reviews, with alerts on authentication failures, rate-limit spikes and Admin API calls. Confirm the log fields you need, decide how customer identifiers are masked, and set retention with your auditor before the observation window starts.

CC8 configuration as code

CC8 covers change management. When routes, consumers and plugin settings live in a Git repository and deploy through reviewed pipelines, each gateway change has an author, a reviewer, a ticket and a deployment record. Standalone mode with a file such as apisix.yaml makes this practical, because the file is the single source of truth. Ask whether emergency changes made through the Admin API are captured and reconciled back into Git.

Availability and processing integrity scope

Availability and processing integrity are optional categories, included only when they are in your report's scope. If you include availability, the gateway's high availability design, capacity limits and failover tests become evidence. If you include processing integrity, rate limits, request validation and transformation rules must be shown to behave as designed. Decide the scope with your auditor early, because it determines which gateway tests you must run and keep.

Confidentiality of stored secrets

Confidentiality matters when the gateway holds upstream credentials, signing keys and customer API secrets. Check where those values are stored, whether they are encrypted at rest, and which systems can read them. Keep secrets out of plain configuration files committed to Git, and rotate them on a documented schedule. Confirm with your platform team how the chosen secrets backend is configured and who holds its recovery keys.

Type 1 and Type 2 windows

A Type 1 report describes control design as of one date, so the gateway must be configured and documented before that date. A Type 2 report adds an opinion on operating effectiveness over a period, so the controls must run continuously and leave records throughout it. Plan the gateway's access reviews, change samples and log extracts as recurring tasks. Your auditor decides the sample and period, and SOC 2 report use is generally restricted to customers and stakeholders named in the report.

What SaaS teams ask before hiring an APISIX implementation partner

What drives the cost and effort of an APISIX implementation?

The main drivers are the number of routes and upstream services, the identity provider you need to connect, how many customer authentication methods you support, whether AI routes and LLM provider failover are in scope, and how much billing or usage data must flow through the gateway. Each route group with its own authentication, rate limit or plan rule adds design and test work, and each identity provider adds configuration and verification against its own flows. Cost is usually one-time for design, build and migration, and recurring for support, upgrades and testing. Ask any partner for a quote that lists routes by category, identity providers, plugins that need custom code, environments, and what is handed over at the end. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote follows from that scope.

What does our team need to provide before an APISIX project starts?

The project needs named architecture owners who can decide routing, tenancy and plan rules, plus access to your identity provider so the OpenID Connect configuration can be tested against real clients. You should also supply a current route inventory, the authentication method each customer group uses, the rate limits and quotas per plan, and sample traffic or logs that show real request patterns. Access to the cloud account or cluster where APISIX will run, and a decision on who operates it afterwards, are also needed early. Confirm with your partner which of these artifacts they need in writing before kickoff, since missing inventory is one of the most common sources of rework.

Can our own engineers implement APISIX without an outside partner?

Yes, a capable platform team can deploy APISIX, and the project is open source under the Apache License 2.0, so there is no license fee to pay for the gateway itself. The work that usually takes the most time is not installation but designing consumer and key models, validating OAuth and OpenID Connect flows, building per-plan limits, and producing evidence for audits. Consider whether your team has spare capacity for that design work, can own the configuration in version control, and can run upgrades on a schedule. A partner is most useful when the internal team needs a fixed-scope build with a handover, or an outside check of the design before it goes live.

How do the EU Data Act switching rules affect vendor lock-in for our API gateway?

The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025 and requires data processing service providers to let customers switch to another provider or to on-premises infrastructure. Providers can impose no switching charges from 12 January 2027, and until then reduced charges may not exceed costs directly linked to switching. The Act governs the provider's obligations, not your gateway design, so it does not by itself make a gateway portable. Self-hosting APISIX keeps your routes, plugin configuration and keys in your own environment, and you can export the configuration as files or through the Admin API. Ask your partner to keep route definitions in version control and to document where each piece of state lives. Confirm your own contract terms with your legal team, since whether the Act applies to a given arrangement depends on the service involved.

Does DeployOpen issue SOC 2 reports for our SaaS product?

No. DeployOpen does not issue audit reports, attestations or certifications. An independent CPA firm performs a SOC 2 examination and issues the report, and the Trust Services Criteria used in that examination include the common criteria CC1 to CC9 that apply to every SOC 2. DeployOpen can prepare the gateway's controls and evidence for that assessment, such as documented access rules for the Admin API, logging of gateway access, TLS configuration, change records for route and plugin updates, and backup procedures. Ask your auditor which evidence they expect and whether they want a Type 1 or Type 2 report, since a Type 2 report covers operating effectiveness over a period.

How do support retainers work after an APISIX go-live?

Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope implementation. A retainer normally covers the operational work that follows go-live, such as applying APISIX releases, reviewing plugin and configuration changes, responding to incidents and keeping documentation current. The scope, response expectations and what is excluded are agreed in writing, so ask for them as part of the proposal. Check which APISIX releases your partner will track, since the APISIX downloads page does not mark any release as long-term support, which means upgrade planning needs its own decision. Ask how upgrades are tested in a non-production environment before they reach customer traffic.

Can APISIX handle AI routes for our LLM-powered product?

APISIX documents AI gateway functions among its built-in plugin categories, and the community lists more than 100 built-in plugins overall. Typical AI work includes routing requests across model providers, failover, token and budget controls, prompt and content checks, and metrics for LLM traffic. Confirm the exact plugins and their behavior against the APISIX documentation for the version you plan to run, because capabilities differ between releases. Include AI routes in the scope early, since they change rate limit design and cost tracking. Model serving and LLM application development are outside what this page covers.

Which identity providers can APISIX connect to for customer sign-in?

APISIX's openid-connect plugin works with identity providers such as Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports authorization code, client credentials, token introspection and PKCE flows. The documentation also covers key-auth, jwt-auth, basic-auth, ldap-auth, SAML, forward-auth and multi-auth. Choose the mechanism per customer type, for example API keys for server-to-server integrations and OAuth for user-facing apps. Verify each flow against your chosen provider's configuration, and confirm claim mapping and token lifetimes with your identity team before production.

What to ask a partner before signing a SaaS API edge scope

Start by asking how the partner will prove that per-plan limits work before go-live. A credible answer names the plugins that enforce the limits, such as limit-count or limit-req, the consumer or route keys they are bound to, and the load and negative tests that show a free-plan customer is throttled while an enterprise customer is not. Ask who owns the plan-to-limit mapping, where it is stored, and how a plan change reaches the gateway. Also ask how usage metering is reconciled with billing, since a gateway counter and an invoice line can disagree. Confirm each answer against the plugin reference in the Apache APISIX documentation rather than accepting a general description of rate limiting.

Next, ask how the partner handles key rotation and customer offboarding, because these are the events auditors ask about first. Request the procedure for issuing, rotating and revoking consumer credentials, the time it takes to disable a key across all gateway nodes, and how the Admin API is restricted so that only named operators can change consumers. Ask what happens to logs and stored credentials when a customer leaves, and who confirms that deletion. Ask the partner to show where each step is recorded, since these records support the access and change management evidence that a SOC 2 examination reviews under the security common criteria.

Ask how configuration is documented as code so that an auditor can see what the gateway enforced on a given date. A good partner will keep routes, consumers, plugin settings and TLS references in version control, deploy them through a reviewed pipeline, and export the running configuration for comparison. Ask whether they use the traditional or standalone deployment mode and how that choice affects evidence, which you should confirm with the APISIX deployment modes documentation. Finally, ask what they will hand over at the end: configuration repository, runbooks, test results, the pinned APISIX and plugin versions, and a written record of each plugin choice tied to the project documentation. Agree these items in the written scope before work starts.

How DeployOpen scopes and supports APISIX for SaaS platforms

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Apache APISIX on a SaaS product, we start from a written scope covering customer-facing routes, key and OAuth design, plan-based limits and the evidence your SOC 2 examination will ask for.

How we scope

Inventory the public APIs, customer tiers, plans and existing gateway behavior that APISIX must reproduce.
Agree in writing how API keys, OAuth clients and identity provider flows will map to APISIX consumers and routes.
Define which rate limit, usage metering and logging behavior sits in the gateway and which stays in the billing system.

How we build

Choose the deployment mode, traditional, decoupled or standalone, based on your Kubernetes, etcd and network constraints.
Configure authentication plugins, per-plan traffic controls and any AI gateway routes as code, with changes reviewed before rollout.
Test routes, limits and failure behavior in a non-production environment, then document each control with its evidence source.

How we hand over

Deliver configuration repositories, runbooks, architecture notes and a control-to-evidence map for your auditors and engineers.
Walk your platform and security teams through Admin API access, certificate handling, log retention and rollback steps.
Record open items and the versions in use so your team can plan upgrades on its own schedule.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial fixed-scope work.
Plan APISIX version upgrades against the project's release notes, and confirm long-term support status with the vendor before choosing a release line.
Ask for a quote built from the written scope, listing one-time build effort separately from recurring support and testing.