Apache APISIX for government and public sector: why it fits agency API programs
Agencies that expose citizen-facing and inter-agency APIs need the gateway in front of those services to stay under their own control, and sometimes on networks that have no route to the internet. Apache APISIX fits that requirement because it is a self-hosted gateway that runs in the agency's own cloud accounts, data centers or restricted networks, and it is released under the Apache License 2.0 (SPDX: Apache-2.0). That licensing gives procurement a clear open-source position to evaluate, with no license fee attached to the gateway software itself. Confirm with your procurement and legal teams how the Apache-2.0 terms fit your acquisition rules, and whether any commercial support or lifecycle product you add carries separate terms.
Choosing APISIX also changes who owns what. The agency's team, or the partner it hires, becomes responsible for the routes, the authentication plugins, the custom plugins, the access and error logs, and the timing of upgrades. APISIX is built on NGINX and etcd and supports three deployment modes: traditional, decoupled and standalone. Each mode places the configuration store and the control interfaces in different locations, so the choice affects where administrative access is exposed and how the gateway is recovered after a failure. Decide the mode early, record who may change configuration, and confirm that the chosen mode matches your network segmentation rules.
Because the software is open source, the agency can inspect what it runs, pin versions and keep copies of the packages it needs for a disconnected environment. Those benefits only hold if the team has a plan for the work that a vendor would otherwise handle, including security patching, version tracking and evidence for assessors. Ask early which APISIX release line your agency will standardize on, since the project's downloads page does not mark any release as long-term support, and plan an upgrade cadence before go-live rather than after the first audit.
Which public sector requirements shape the APISIX build
This table maps each public sector requirement to its source and to what it means for the gateway's design, hosting and logging. Read the applies-to column first, because several obligations fall on the agency while the cloud provider carries only part of the evidence. The main takeaway is that APISIX configuration, network placement and log handling usually decide whether these requirements are met.
| Requirement | What it asks for | Gateway design, hosting and logging impact | Applies to |
|---|---|---|---|
| NIST SP 800-53 Rev. 5 and SP 800-53B baselines | Federal control catalog. SP 800-53B baselines select 149 (low), 287 (moderate) and 370 (high) controls and enhancements. | Map gateway controls to the baseline your system category selects. Document access control, audit, configuration management and boundary protection for APISIX itself. | Federal agencies and contractors operating federal systems |
| FedRAMP scope under OMB M-24-15 | Cloud products that handle federal information on behalf of an agency, when offered as a shared service. Single-agency systems on cloud infrastructure are generally out of scope. | If a hosted APISIX service carries federal data for several agencies, the provider may need FedRAMP authorization. A self-hosted gateway in the agency's own cloud account is a different scope question. Confirm with the agency's authorizing official. | Cloud service providers and agencies choosing a hosting model |
| FBI CJIS Security Policy v6.1 | Criminal justice information must use FIPS 140-3 validated modules or AES with at least 256-bit keys in transit and at rest outside physically secure locations. Vulnerability scanning at least monthly. | Confirm TLS and encryption configuration uses validated cryptographic modules. Plan monthly scanning of APISIX hosts, images and plugin dependencies. Keep CJI out of gateway access logs and error output. | Agencies handling CJI, and their hosting and integration providers |
| 32 CFR 2002.14(h)(2) for CUI | Agencies set NIST SP 800-171 requirements for CUI on non-federal systems, unless the CUI category prescribes other safeguards. | Gateways that carry CUI on non-federal infrastructure need controls that match the agency's SP 800-171 requirements. Confirm which safeguards apply per data category before choosing routes and logging scope. | Agencies and the non-federal organizations that receive CUI |
| 32 CFR 170.17(c)(5) for CMMC Level 2 | A defense contractor may store or process CUI in a cloud service only if it is FedRAMP Authorized at Moderate or higher, or meets equivalent requirements. Non-cloud providers are assessed within the contractor's scope. | A self-managed APISIX on the contractor's own servers is assessed within the contractor's boundary. A managed gateway service hosting CUI traffic falls under the cloud rule. Confirm the classification before selecting a hosting option. | Defense contractors and their gateway providers |
| ADA Title II web and mobile accessibility | State and local government web content and apps, including contracted content, must meet WCAG 2.1 Level A and AA. Compliance dates are 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. | The gateway does not make content accessible, but it can block or alter responses in ways that break assistive technology, such as stripped headers or altered error pages. Test gateway-fronted content and the agency's own remediation records. | State and local governments, including content delivered through contractors |
| NIS2 scope for public administration | Central government entities are covered regardless of size. Member States may extend the scope to local administration. National security, public security, defense and law enforcement are excluded. | Public administration is a high-criticality sector, so gateway resilience, access control and cryptography need documented justification. Confirm with national authorities whether a given body is in scope and which exclusions apply. | EU public bodies in scope, and their technology providers |
| X-Road interoperability for data exchange | X-Road is MIT-licensed open-source software for secure exchange between organizations. Security Server requires PostgreSQL and runs on Ubuntu 22.04 or 24.04 LTS or RHEL 8 or 9. | APISIX handles citizen-facing and internal API traffic, while X-Road typically governs inter-agency message exchange. Decide which flows pass through each layer, and confirm the X-Road release (7.8.3 is current) and its ports with the operator before integration design. | Agencies exchanging data with other public bodies |
Which APISIX plugins and settings matter for agency APIs
Agency APIs usually combine workforce sign-in, machine access for partner systems, encrypted inter-agency links and tight control of the gateway itself. The cards below cover the APISIX plugins and settings that address each of these, and the decisions and checks an agency should settle before go-live.
OpenID Connect with agency identity providers
The openid-connect plugin lets APISIX check user sign-in against an identity provider such as Keycloak or Microsoft Entra ID, using authorization code and PKCE flows for browser users and token introspection for APIs. Confirm which provider is the system of record for staff and citizens, which claims map to route permissions, and how token lifetimes and session revocation are set. Test the redirect and logout paths with your own identity provider before relying on them.
LDAP and SAML for workforce access
Many agencies still hold staff accounts in a directory, so APISIX documents ldap-auth for direct directory checks and saml for federated sign-in. Decide whether the gateway should talk to the directory itself or whether a central identity provider brokers that trust, since the second option keeps directory credentials out of the gateway. Ask who owns the directory bind account, how it is rotated, and which groups grant access to which routes.
Key and JWT authentication for partner systems
Other public bodies and approved vendors often call APIs as machines rather than people. The key-auth and jwt-auth plugins attach a consumer identity to each partner, so access can be granted, limited and revoked per partner. Agree how keys or signing keys are issued, how long they live, and who approves a new consumer. Store issued secrets in a managed secrets system, not in route configuration files that many staff can read.
mTLS and client certificates for inter-agency links
For data exchange between agencies, mutual TLS proves that both ends hold certificates issued under an agreed trust chain. APISIX supports client certificate checks on routes, so the gateway can refuse calls from systems outside the agreed certificate authority. Confirm which certificate authority the agencies trust, how revocation is checked, and who renews certificates before they expire, because an expired certificate stops inter-agency traffic outright.
Traffic and rate controls per consumer
Rate limiting and request size controls protect shared public services from overload and from a single misbehaving caller. APISIX applies these per route or per consumer, so a large partner can have a different budget from a small one. Agree the limits with the service owners, decide whether a limit is counted per consumer or per client address, and test how the gateway responds when a limit store is unavailable, since that choice decides whether the service fails open or closed.
Admin API and etcd settings
In traditional deployment mode APISIX serves client traffic on port 9080 and its Admin API on port 9180, and it keeps configuration in etcd. The Admin API can change every route and credential, so restrict it to a management network, enable its access key, and never expose port 9180 to public or partner networks. Confirm how etcd is secured with TLS and authentication, how it is backed up, and who may change routes. WAF inspection is not a built-in APISIX feature in the same sense, so agencies should confirm in their own design which web application firewall sits in front of or behind the gateway and how its logs reach the agency's monitoring.
How hosting environment changes the APISIX design
An agency that runs its own data center or a sovereign cloud region usually controls the network, the identity provider and the storage, so traditional mode is often the simplest starting point. In traditional mode, data and control planes run together, client traffic arrives on port 9080 and the Admin API listens on port 9180. Decoupled mode suits agencies that want separate gateway nodes in several zones or segments, with each data plane sharing one etcd cluster through the control plane.
- Deployment mode: Traditional for a single site, decoupled when gateway nodes must sit in different network zones while configuration stays central.
- Updates: Images and packages come through the agency's own internal mirror or registry, scanned and approved before they reach production.
- Plugins: Custom Lua or plugin runner code is built inside the agency's pipeline and stored in its source control.
- Etcd placement: Keep the etcd cluster inside the same controlled boundary as the Admin API and restrict who can reach it.
- Logs and keys: Send logs to agency-controlled storage and hold TLS keys in an approved secrets system.
Confirm with the vendor and your environment which APISIX and etcd versions your accreditation covers, and whether your hosting provider's controls extend to the gateway nodes.
On an air-gapped network, no node can reach public package repositories or the internet, so every container image, operating system package, plugin and vulnerability feed must be brought in through a controlled transfer process. Standalone mode fits this boundary well because it needs no etcd cluster, and configuration lives in a YAML or JSON file, such as conf/apisix.yaml or conf/apisix.json, that APISIX checks every second and hot-reloads without a restart. That file can be produced, reviewed and signed in a higher-trust zone, then transferred inside the boundary.
- Deployment mode: Standalone, with routes and consumers held in a version-controlled file that is reviewed before transfer.
- Updates: Packaging the gateway, its dependencies and any plugin runner into an offline bundle is a planning topic. Confirm with the vendor whether an offline bundle is available and what it contains.
- Software integrity: Verify checksums or signatures of every package crossing the boundary, the control behind supply chain requirements for vendor software.
- Plugins: Test custom plugins against the same APISIX version in a staging enclave before importing them.
- Vulnerability data: Plan how advisories reach the enclave and how scanning works without live feeds.
Ask the vendor whether any feature you need depends on an outbound connection, such as external identity lookups, license checks or telemetry, and plan a local replacement for each one.
A shared-service gateway serves several agencies or departments from one platform, so tenancy and separation become the main design questions. Traditional or decoupled mode is common here because a central team operates the control plane while business owners manage their own routes. The gateway must keep one agency's routes, consumers, keys and logs away from another's, and the Admin API must be limited to named administrators.
- Deployment mode: Decoupled, with a central control plane and data planes per segment or agency group.
- Tenancy: Use route and consumer naming, separate credentials and role-based administrative access to keep agencies apart. Confirm the exact isolation options in the version you select.
- Updates: The platform team applies upgrades on a schedule agreed with each tenant, and changes move through a shared test environment first.
- Plugin packages: Shared plugins are reviewed centrally, and agency-specific plugins follow a documented approval path.
- Audit trails: Keep administrative change records separate from traffic logs so each agency can receive its own evidence.
Confirm with your platform team how etcd is partitioned or secured between tenants, and what the Admin API access model provides for each agency.
How an agency rollout of APISIX is sequenced
The sequence turns an unmapped set of citizen and inter-agency APIs into a gateway that runs in agency-controlled infrastructure, with authentication, inspection and evidence in place before any traffic moves. Each phase has a written output that the next phase depends on.
Scope the API inventory and classify data
Agency architects, the API owners and the security office list every API, consumer, upstream service and data category, including which flows carry personal, case or controlled unclassified information. DeployOpen maps the flows against the applicable baselines and agency policy, so the classification drives hosting, encryption and logging choices later. The step is done when each route has an owner, a data class, a named consumer type and an agreed scope in writing.
Choose hosting and deployment mode
The team decides where the gateway runs (agency data center, a sovereign cloud region or an air-gapped enclave) and which APISIX deployment mode fits the network. Traditional mode keeps control and data planes together, decoupled mode separates them around a shared etcd cluster, and standalone mode loads configuration from a file or API without etcd. The output is an architecture record that names the image sourcing method, the offline package process and the owner of each component. Confirm the hosting constraints with the agency's accreditation authority before building.
Build identity and authentication
Platform engineers connect APISIX to the agency identity provider and define how each caller type authenticates, such as OpenID Connect for staff and applications, mutual TLS or HMAC for machine clients, and API keys only where policy allows. Consumer objects, scopes and token validation rules are written and reviewed with the identity team. The step closes when a test user and a test machine client each obtain access to a staging route and are denied on a route they should not reach.
Configure routes and plugins in staging
Engineers define routes, upstreams, TLS certificates, WAF inspection, request size and rate limits, and logging plugins as version-controlled configuration in a staging environment that mirrors production. Agency security staff test the policies with known-bad requests and confirm that the Admin API and etcd are reachable only from management networks. The output is a signed-off configuration baseline and a test report that the change board can audit.
Run in parallel and cut over with rollback
Existing gateway and new APISIX instances serve the same APIs side by side, with traffic shifted in controlled steps for selected consumers and inter-agency partners. Operators keep the previous path ready so that a route can return to the old gateway without a rebuild. Cutover is complete when the partner agencies confirm successful exchanges, error rates match the baseline and the rollback steps have been rehearsed and recorded.
Operate the gateway and collect evidence
The agency's operations team takes over patching of APISIX, OpenResty and etcd, certificate renewal, backup and restore tests, and log retention. Configuration changes continue through the same review path as the baseline, and security testing runs against the live routes on a recurring schedule. DeployOpen can prepare the control descriptions and evidence set, but independent auditors and certification bodies issue any assessment outcome. The step is in good order when each control has a named owner and a current evidence record.
What agencies ask before hiring a partner for APISIX
What drives the cost of an APISIX implementation for a government agency?
The cost follows from the written scope, not from the software, because Apache APISIX is free to download under the Apache License 2.0. The main drivers are the number of routes and upstream services to migrate, how many authentication methods must be configured, whether custom plugins are needed, the hosting model (sovereign data center, cloud account the agency controls, or air-gapped network), and the depth of testing and documentation the accreditation file requires. Ask any partner to itemize these components, separate one-time build work from recurring support and upgrades, and state which items the agency's own staff will carry. DeployOpen does not publish a price list, and a quote follows from the written scope.
How long does an APISIX rollout take in a public sector environment?
Duration depends on the number of APIs, the identity and approval steps the agency must complete, and how many environments need security review before go-live. No fixed timeline applies across agencies, so ask for a phased plan with named milestones: platform build in a non-production environment, route and policy migration, parallel running, and cutover with rollback. Security review, change approval and any accessibility or records requirements often set the pace more than the gateway build itself. Most engagements are fixed-scope, so the agreed schedule should appear in writing before work begins.
What must the agency provide before a partner starts the work?
The agency should prepare three inputs before work starts. First, identity: a configured identity provider and the client registrations, scopes and claims the gateway will validate, for example through the openid-connect plugin, which works with providers such as Keycloak, Microsoft Entra ID and Okta. Second, network: approved IP ranges, DNS names, firewall rules between the gateway, etcd and upstream services, and the path for certificates and logs. Third, staff: named owners for the API catalog, a security approver, and operators who will receive handover. Confirm each item against the agency's own change process before the schedule is fixed.
Can our own team run APISIX after the partner hands over the platform?
Yes, if the team has Linux, networking and Kubernetes or VM operations skills and the handover includes runbooks. APISIX runs in traditional, decoupled and standalone modes, and each mode has different operational tasks. Traditional and decoupled modes depend on an etcd cluster, which needs its own backup, monitoring and upgrade procedure. Standalone mode reads a YAML or JSON file and hot-reloads changes, which suits configuration as code but needs disciplined version control. Ask the partner to document the chosen mode, the upgrade path for each component and the restore test, and to train the agency's operators on those steps.
How do licensing and procurement work for Apache APISIX and a vendor edition such as API7 Enterprise?
Apache APISIX is a top-level Apache Software Foundation project released under the Apache License 2.0, so the open-source core can be downloaded and used without a license fee, and procurement teams can review the license text directly. A vendor edition is a separate purchase. API7 Enterprise is described by its vendor as a lifecycle management product based on Apache APISIX, and the vendor does not publish prices on its page. Procurement should separate the open-source platform, any vendor subscription, and partner services, and each should have its own written scope. Confirm with the vendor which support terms, certifications and deployment options apply to the agency's environment.
How does X-Road fit alongside APISIX for data exchange between agencies?
APISIX and X-Road solve different problems and can sit side by side. APISIX manages client-facing and partner-facing HTTP APIs: routing, authentication, rate limits and WAF inspection. X-Road is an open-source data exchange layer, published under the MIT license, for secure exchange between organizations, with its Security Server handling message exchange over TCP 5500 and OCSP over TCP 5577. Where an agency already runs X-Road, its services may be published through X-Road rather than replaced, and APISIX can front the citizen-facing endpoints. Confirm the integration pattern with the X-Road operator, because the current supported release is 7.8.3 and X-Road 8 is scheduled for production in December 2026.
Which compliance frameworks shape an APISIX design for government?
The control baseline depends on the system, its data and its authorizing body. NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B selects low, moderate and high baselines of 149, 287 and 370 controls and enhancements respectively. Systems that handle criminal justice information may fall under the FBI CJIS Security Policy, where version 6.1 took effect on 26 June 2026 and requires FIPS 140-3 validated modules or AES with 256-bit keys for CJI outside physically secure locations. Cloud services used for federal information may need FedRAMP authorization. DeployOpen prepares systems and evidence for assessments, but independent auditors and certification bodies issue the findings.
What is the fastest way to get an accurate quote for this work?
Prepare a short inventory before asking for a quote: the list of APIs and consumers, the authentication method for each, the hosting location and network zones, the data classifications involved, and any applicable frameworks such as NIST SP 800-53 baselines or CJIS requirements. Add the number of environments, whether custom plugins or X-Road integration are needed, and who will operate the platform after handover. A partner can price a fixed scope from this inventory. Ask the quote to list assumptions and exclusions in writing, so that changes in scope can be priced against the same baseline.
Compliance evidence the gateway can help produce
A gateway sits on the boundary where public and inter-agency requests enter, so several control families pass through it. The cards below name the controls most often asked about and what the APISIX configuration, logs and build records can contribute as evidence. DeployOpen prepares systems, controls and evidence for assessments, but does not issue audit reports, attestations or certifications; independent assessors and authorizing bodies make those determinations.
Access control and authentication
Gateway routes are where agency policy on who may call which API is enforced in practice. Map each route to an authentication plugin, such as openid-connect for staff and citizen identities or key-auth and jwt-auth for machine clients, and record which consumers may reach it. Ask the assessor which control identifiers in the NIST SP 800-53 catalog they will test against, such as the access control and identification and authentication families, and confirm that route-level configuration is exported and version-controlled so the evidence reflects the running state.
Encryption in transit and key length
CJIS Security Policy version 6.1 requires FIPS 140-3 validated modules or AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations. Gateway TLS termination, upstream TLS and certificate storage all fall within that scope. Confirm with your assessor which cryptographic module the gateway's TLS stack uses in your build, whether the OpenSSL or BoringSSL variant is FIPS validated, and which cipher suites are enabled. Record the key lengths in use for each listener and upstream.
Logging and monitoring
Access logs from the gateway are primary evidence for who called which API and when. Define which fields are written, where they are shipped, how long they are retained, and who can read them. Keep personal data and request payloads out of logs unless there is a documented need. Confirm with the agency's records and audit owners what retention period applies to each dataset, because the gateway configuration does not set that policy for you.
Vulnerability scanning cadence
CJIS Security Policy version 6.1 calls for vulnerability scanning at least monthly, covered under the RA-5 control. Scans should include the APISIX release in use, the etcd cluster, the operating system and any plugin runners. Agree in writing which team runs the scans, where the results are kept, and how findings on the gateway are tracked to closure. Scanning evidence is more useful to an assessor when it shows a fixed schedule and dated remediation records.
Accessibility of public web content
Under the ADA Title II rule, state and local government web content and mobile apps, including those delivered through contracts or licenses, must meet WCAG 2.1 Level A and AA. The gateway does not render pages, but it does shape what reaches citizens, including error responses and redirect behavior. Ask the agency which of its services are fronted by the gateway, and confirm with the content owners whether accessibility testing covers the responses those services return.
Supply-chain verification of carried packages
In air-gapped or restricted networks, every APISIX package, plugin dependency and container image is carried across a boundary by hand. Under NERC CIP-013-2, supply chain procurement must address verification of software integrity and authenticity, and the same discipline applies to public bodies that operate isolated networks. Keep checksums or signatures for each artifact, record who approved the transfer, and retain the build inputs. Confirm with your security team which verification method your environment requires before the first transfer.
When X-Road belongs beside APISIX for data exchange
An API gateway and X-Road solve different problems, so agencies often need both. APISIX sits at the edge of a service you own and publishes its routes to clients, applying authentication, WAF inspection and rate limits to each request. X-Road is built for exchange between organizations: each party runs a Security Server, and the exchange is governed by the trust relationships and configuration that the participating bodies agree to. Before you decide where each one belongs, map which flows are citizen-facing and which are inter-agency. Citizen and application traffic usually fits APISIX. Records exchanged between public bodies under a formal data-sharing agreement are the better candidate for X-Road, which is open-source software published under the MIT license and developed by the Nordic Institute for Interoperability Solutions.
Plan around the current release line before you commit. The current X-Road release is 7.8.3, with supported versions 7.8.3, 7.7.4 and 7.6.5. NIIS states that 7.8.0 is the last new-feature release of X-Road 7 and intends to keep maintaining it with bug fixes and security patches beyond 2026, but it has not decided how long that period will be. Ask the NIIS and your own procurement team to confirm the end-of-maintenance date in writing. X-Road 8, code-named Spaceship, is at 8.0.0 Beta 2 and is scheduled for production in December 2026, so a beta should not carry production exchanges. Confirm the production date and migration path from 7 before you design the integration.
The Security Server has concrete prerequisites to check early. It runs on Ubuntu Server 22.04 or 24.04 LTS on x86-64, or on Red Hat Enterprise Linux 8 or 9, with at least 3 GB RAM (4 GB with monitoring add-ons) and 3 GB free disk. It requires PostgreSQL, either local or remote, including managed services such as AWS RDS and Azure Database for PostgreSQL. Ask who owns the database and its backups. If your signing keys must sit in a hardware security module, X-Road supports PKCS#11 drivers through the xroad-addon-hwtokens package for RSA and EC keys, so confirm that your HSM vendor's driver and key types match before procurement. Verify the Security Server's network rules as well, including TCP 5500 and 5577 from external networks and TCP 4000 for the admin UI, and keep the APISIX gateway and the Security Server on separate, deliberately routed paths.
How DeployOpen scopes and supports APISIX for public bodies
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For public bodies, that means APISIX is scoped against the agency's own hosting, authentication and data exchange requirements before any configuration begins.
How we scope
- Written scope listing which citizen, inter-agency and partner APIs move onto APISIX, agreed before work starts
- Hosting model confirmed upfront: sovereign cloud, government data center or air-gapped network
- Inventory of authentication methods, WAF inspection points and external bodies that exchange data through the gateway
How we build
- Deployment in the agency's infrastructure using traditional, decoupled or standalone mode, chosen against the network design
- Routes, identity integration through the openid-connect plugin, and custom plugins written where the agency's rules require them
- Testing of authentication flows, TLS configuration, rate limits and WAF behavior before any traffic is switched over
How we hand over
- Configuration kept as code with documented Admin API access, etcd layout and certificate handling for the agency's team
- Runbooks for route changes, plugin updates, backups and restoring the gateway after a failure
- Evidence pack describing controls and logs in a form the agency's assessors or auditors can review
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Review of each APISIX release and planned upgrade against the agency's change control process
- Clear confirmation with the agency's vendors and assessors of any component version or certification question before it is relied on
