How APISIX keeps API keys and certificates out of its configuration
When API keys, upstream credentials or TLS private keys are pasted directly into route, consumer or upstream definitions, those values are copied into etcd, into every configuration backup and often into Git repositories that hold gateway configuration as code. The control that changes this is a reference: APISIX can resolve a secret from an external store at runtime instead of holding the value in its own configuration. The backends this topic covers are HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager and environment variables. The exact reference syntax, the options each backend accepts and the APISIX release that introduced support for each backend must be confirmed in the APISIX documentation for the version you plan to deploy, and this page does not assume a specific syntax.
Before the build starts, inventory every field that carries a credential across routes, consumers, upstreams, plugin settings and the gateway's own configuration file, and decide which store owns each value and who may rotate it. Confirm with your platform team whether the gateway's runtime identity can authenticate to Vault or to the cloud provider without a static token, since that choice determines whether the gateway holds a long-lived secret to reach its secret store. Plan for the failure mode as well: confirm how the release you deploy behaves when a reference does not resolve, whether the route fails closed, the plugin errors, or the last known value stays in use, and test a deliberately broken reference in staging before relying on it. Review the APISIX deployment modes documentation for how each mode loads configuration, because a reference that resolves in a traditional deployment may behave differently in standalone mode.
What you need before connecting APISIX to a secret manager
Before any APISIX route can resolve a secret reference, the team needs a clear picture of how the gateway is deployed, which backend will hold the values, and how the gateway nodes reach that backend over trusted TLS. The five items below are the checks that decide whether the integration works on the first attempt and stays working after the next change.
Running APISIX estate and deployment mode
Identify which of the three deployment modes the estate uses: traditional, decoupled or standalone. In traditional and decoupled modes, configuration lives in etcd, so confirm the etcd cluster is healthy and who operates it. In standalone mode, configuration comes from conf/apisix.yaml or conf/apisix.json, which means the file itself must be protected and version controlled. The mode determines where secret references are written and how a change is rolled out.
Backend version and support confirmation
The downloads page lists APISIX 3.19.0 as the latest release, dated September 28, 2026. That does not confirm which secret backend integration is available in your target version. Check the APISIX secret provider documentation for the exact release that supports each backend (Vault, AWS Secrets Manager, GCP Secret Manager or environment variables) before choosing one, and record the version you pin in production.
Backend account, policy and ownership
Decide who owns the secret backend account the gateway uses to read values. Ideally a platform or security team owns the Vault policy, AWS IAM role or GCP service account, while the API team owns the route that consumes the secret. Grant read-only access scoped to the paths or secret names APISIX needs, and document who approves changes. Without this split, a single broad token ends up shared across environments.
Network paths from gateway nodes
Map the network route from every APISIX node, including each data plane in decoupled mode, to the Vault endpoint or cloud secret API. Confirm firewall rules, proxies, DNS resolution and any private endpoints for the cloud service. Gateway nodes in restricted zones often lack outbound internet access, so the backend must be reachable from exactly those nodes that need it, and the team should test that reachability from the production network, not from a workstation.
TLS trust for the backend endpoint
Confirm which certificate authority signs the backend endpoint and make sure every gateway node trusts it. Private CAs used by internal Vault clusters are a common gap, since the gateway fails to resolve references when verification fails. Decide where the CA bundle lives, how it is rotated, and whether certificate expiry is monitored. Do not disable verification to get a connection working during testing.
Failure behavior and rollback plan
Agree in advance what happens when a secret reference does not resolve: whether affected routes return errors, whether the last known value is kept, and how a failed rollout is reverted. Test this in a non-production environment by pointing a reference at a missing secret. Record the owner who is paged, because an unresolved reference often surfaces first as a runtime error on live traffic.
Choosing a secret backend for your estate
HashiCorp Vault suits estates that already run it or need a self-hosted secret store with audit controls inside a network you own, including air-gapped networks where cloud secret services cannot be reached. APISIX nodes fetch secrets from Vault over the network, so the data plane must reach the Vault cluster and trust its TLS certificate. Teams that already operate Vault can extend existing practice, but a new deployment adds high availability, unsealing and backup work to your platform team's scope.
- Hosting: Vault can run in your data center, your cloud accounts or a managed offering. Confirm with the vendor which edition and hosting model meet your data residency rules.
- Gateway identity: Choose an auth method such as AppRole or a Kubernetes service account login, then give the gateway a policy that reads only the paths its routes need.
- Network reach: Every APISIX node in every zone must reach the Vault address. Confirm this during design, because a single unreachable zone can fail route loads there.
- Unseal and storage: Plan how the cluster unseals after a restart and where the unseal material is held. Your storage backend and its backups also become part of the recovery plan.
- Main operational cost: Running Vault itself, including upgrades, audit device capacity and on-call coverage, usually falls to your team, and it recurs for the life of the platform.
Check how Vault unseals after a node restart and who holds the unseal material before you point any gateway at it.
AWS Secrets Manager suits estates that run workloads in AWS and want managed storage with access controlled by IAM. APISIX on EC2, EKS or other AWS compute reads secrets through the AWS API, so the gateway needs a network path to regional AWS endpoints. A gateway in another cloud or in an air-gapped network needs a planned exception to that path, and you should confirm the exception with AWS before committing to the design.
- Account boundary: Secrets live in the AWS account and Region you choose. A gateway in a different account needs a cross-account role or a resource policy on the secret.
- Gateway identity: Attach an IAM role to the instance or pod, such as an IAM role for service accounts on EKS. Long-lived access keys should be avoided wherever the platform allows a role instead.
- Rotation: Secrets Manager can rotate some credentials through rotation functions. Confirm with AWS which rotation patterns your database or key type requires, and how the gateway picks up a new version.
- Access scope: Write the IAM policy against the specific secret ARNs your routes reference, then test a deliberate denial to confirm the scope holds.
- Main operational cost: Charges depend on how many secrets you store and how often the gateway calls the API, so caching and refresh intervals affect the bill. Ask AWS for current billing terms for your Region.
Check the IAM policy attached to the gateway role and confirm it covers only the secrets that APISIX routes actually reference.
GCP Secret Manager suits estates that run in Google Cloud and want managed secret storage governed by IAM and project boundaries. APISIX on Compute Engine, GKE or another platform reads secret versions through the Google Cloud API, so the gateway must reach Google endpoints from every zone where it runs. Confirm regional availability and data residency for your project before you choose it for regulated data.
- Project boundary: Secrets belong to a Google Cloud project. Decide whether the gateway and its secrets share a project, and document any cross-project grants.
- Gateway identity: Use an attached service account on Compute Engine, or Workload Identity on GKE, so the gateway holds no downloaded key file. Key files are harder to rotate and to track.
- Versioning: Secret versions let you add a new value and retire the old one. Confirm with Google how the gateway should resolve the latest version and whether pinning a version suits your change process.
- Hybrid estates: Gateways outside Google Cloud need a separate identity path, such as workload identity federation. Confirm the federation setup and the network route before design.
- Main operational cost: Recurring charges come from stored secret versions and access operations, so polling frequency matters. Ask Google for current pricing and quotas for your project and Region.
Check which service account the gateway runs as and confirm that its IAM role grants access to the specific secrets its routes use.
Environment variables suit small estates, development and test environments, and bootstrap values such as a provider address. The orchestrator or service manager injects them into the APISIX process, so the gateway has no separate secret store to call. This is the simplest option to operate, but it gives you the weakest controls over rotation and audit, which matters most for regulated production.
- Delivery: Values are injected by systemd, Docker, a Kubernetes Secret or CI variables. Confirm whether your orchestrator encrypts Kubernetes Secrets at rest and who can read them.
- Gateway identity: No separate identity is involved. Access is controlled by who can read the host, the pod specification or the deployment pipeline.
- Exposure: Values can appear in process listings, crash dumps, container inspection output and some diagnostic logs. Confirm log redaction in your pipeline and that the Admin API does not return these values in responses.
- Rotation: Changing a value usually means updating the source and restarting or reloading the gateway. Plan this into your change window and test it in staging.
- Main operational cost: Tooling cost is low, but rotation records, access reviews and audit evidence are manual and recur with every change.
Check who can read the environment of the gateway process and whether your rotation process requires a restart before you rely on this option in production.
Configuring secret references in APISIX, step by step
This sequence takes a team from an empty secret backend to a non-production APISIX route that reads an upstream credential from a referenced secret rather than from its own configuration. Each step ends with a check that shows the reference resolves and the value stays out of the gateway's stored configuration.
Create the test secret in the backend
The platform or security team creates a dedicated test secret in the backend you already run, such as HashiCorp Vault, AWS Secrets Manager or GCP Secret Manager, using a placeholder value that is not used by any production system. Store it under a path or name that identifies the gateway and the environment, so the access policy can be scoped tightly. The step is complete when someone with administrative rights can read the secret from the backend's own CLI or console, and the value matches what the team recorded in its change ticket.
Create a least-privilege read policy
The security engineer writes a read-only policy or IAM role that grants access only to the test secret's path or ARN, with no list, write or delete rights beyond what the backend requires for reads. Avoid attaching a shared administrative token to the gateway. Confirm the exact policy syntax in the documentation for your backend and for the APISIX secret backend you choose. The step is complete when a test identity with only this policy can read the test secret and receives a denial when it attempts to read any other path.
Authenticate the gateway identity to the backend
The platform team gives the APISIX runtime a workload identity bound to the read policy. Depending on your environment, this may be a Vault auth method, an instance or pod role, or a workload identity federation. Keep the credential used to authenticate out of APISIX configuration files and out of version control. The step is complete when the gateway host or pod can obtain a short-lived token or assume the role and read the test secret from the same network path that production traffic uses.
Configure the APISIX secret backend connection
The platform engineer adds the secret backend connection to the APISIX configuration, pointing it at the backend endpoint, the authentication method and the namespace or prefix for the test secret. Check the APISIX documentation for the exact configuration keys for your chosen backend and version, because they differ between backends and releases. Apply the change in a non-production environment first. The step is complete when APISIX starts or reloads without errors in its error log and the backend connection status reports healthy.
Reference the test secret from one route
The API owner creates or updates a single non-production route with an upstream that requires a credential, such as an API key header, and sets that field to a secret reference rather than the literal value. Use the reference syntax documented for the backend and the APISIX version you run. Limit the route to a test upstream that returns a clear result when the credential is correct. The step is complete when the route is saved and the Admin API returns the stored route with the reference string in place of the credential.
Confirm the reference resolves at request time
The QA engineer sends a request through the test route and checks that the test upstream accepts the credential and returns the expected response. Then the engineer changes the test secret's value in the backend, waits for the cache or refresh interval to pass, and repeats the request to confirm the new value is used. The step is complete when the request succeeds only with the resolved credential, and the stored configuration read shows the reference, not the value.
Test the failure mode before promotion
The team deliberately points the route at a missing or misspelled secret reference in the test environment, or revokes the gateway's read access, and records what APISIX does. Confirm whether the request fails closed, returns a server error, or forwards the request without the credential, and whether the error log names the reference without printing the value. Decide the alerting and runbook steps before this configuration goes near production. The step is complete when the team has written down the observed behavior and the alert that fires on it.
Which secrets belong in which APISIX object
This table maps each secret type to the APISIX object that holds its reference, who owns the value, who rotates it, and what to confirm in the plugin documentation before wiring it up. Read each row as a placement rule: the secret value lives in the external store, and APISIX holds only the reference. Confirm the exact reference syntax for your APISIX version before you rely on any row.
| Secret type | APISIX object that holds the reference | Value owner and rotation owner | Confirm in the docs |
|---|---|---|---|
| Consumer API keys | Consumer object using the key-auth plugin | Owner: API product team. Rotation: the team that issues keys to the consuming client, on a schedule set in policy. | Confirm how key-auth reads a secret reference and whether consumer keys can be resolved from the secret store in your version. |
| Consumer credentials for JWT or HMAC | Consumer object using jwt-auth or hmac-auth | Owner: identity or partner integration team. Rotation: the same team that issues the signing secret or key pair. | Confirm which consumer fields accept references and whether the signing secret is stored as plain text in etcd. |
| Upstream authentication material | Upstream object or plugin configuration that sends credentials to a backend | Owner: team that operates the backend service. Rotation: backend team, with the gateway reference updated in the same change window. | Confirm which upstream and plugin fields resolve references and how a rotated value is picked up without a reload. |
| OpenID Connect client secret | Route configuration using the openid-connect plugin | Owner: identity team that registers the client at the identity provider. Rotation: identity team, coordinated with the gateway owner. | Confirm the client secret field in the openid-connect plugin page and the reference format it accepts. |
| TLS private keys | SSL object that holds certificate and key for listeners | Owner: PKI or platform security team. Rotation: certificate lifecycle owner, often automated from the issuing CA. | Confirm whether the SSL object accepts a secret reference for the private key and how a reload is triggered after rotation. |
| Plugin logger or external auth tokens | Plugin configuration for loggers, forward-auth or other external services | Owner: team that runs the receiving service (SIEM, log platform or auth service). Rotation: that same team, with the gateway reference updated after issue. | Confirm the token field for each logger or auth plugin and whether it resolves references or only literal values. |
| Admin API keys | Gateway configuration, not a route or consumer object | Owner: gateway platform team. Rotation: platform team, with access limited to automation that needs it. | Confirm where Admin API keys are read from in your deployment mode and whether they can come from the external store. |
What happens when a reference does not resolve
A reference that does not resolve can leave a route, plugin or certificate unusable, and the moment of resolution decides how far the damage spreads. Resolution can happen when APISIX loads configuration at startup, when a resource is written through the Admin API, or when a request needs the value. Each point behaves differently, so confirm in the APISIX secrets documentation for your version which of these applies to each secret backend. In file-driven standalone mode, where APISIX checks its deployment mode configuration for changes every second, ask whether a reload that fails to resolve keeps the previous configuration active or replaces it. That answer determines whether a bad edit is a warning or an outage.
A backend outage at Vault, AWS Secrets Manager or GCP Secret Manager creates a second risk. Depending on when resolution runs, it can block configuration changes that need fresh values, or it can cause request failures on live traffic. The gateway team and the backend owner must decide between failing closed, where requests are rejected until the value resolves, and serving a cached value. Choose cached serving only if the documentation confirms that APISIX caches the resolved value and states how long it is kept. If it does not, plan on the assumption that an outage is felt immediately and design the monitoring, alerting and sequencing of secret changes around that.
Test the failure path in staging before production. Revoke or rename a test secret, reload configuration, and record exactly what the Admin API returns, which routes stop serving, and what the data plane does with requests. Repeat the test with the backend unreachable, not only with a missing key. The outcome should be written into a runbook agreed by the gateway team and the backend owner. It should name who rotates each secret, who is paged when resolution fails, how to roll back to the last known good configuration, and how the gateway is checked after recovery. Without that shared runbook, each team will assume the other one owns the first response.
Hardening the secret path around the gateway
A secret reference is only as safe as the systems that can read it, change it and see its value. The six controls below cover the read path to the backend, the separation between environments, the Admin API and etcd or standalone file that hold the references, and the audit and rotation practices that keep values out of tickets, Git and logs.
Scope read policies per gateway environment
Give each APISIX environment its own backend token or role, with a read policy that names only the paths that gateway needs. A production gateway should not be able to read staging keys, and a shared policy across environments makes that boundary impossible to audit. Ask your team to list which paths each gateway identity can read, and test that a request for another environment's path is denied.
Separate non-production secret backends
Use a separate Vault namespace, AWS account or GCP project for non-production, so test credentials never sit next to live ones. Keep non-production gateways pointed only at their own backend, and confirm that copied configuration does not carry production secret paths into a test environment. (Illustrative: a staging config copied from production still referencing live paths.)
Restrict Admin API access on port 9180
In traditional mode the Admin API listens on port 9180, and anyone who can call it can change which secret a route or consumer references. Limit network access to that port to automation and operator hosts, require a strong Admin API key, and treat changes to references with the same review as route changes. Confirm the current Admin API key handling for your version before you finalize this.
Limit who edits secret references
A reference such as an environment variable or secret path is stored in etcd in traditional mode, or in the standalone file in file-driven mode. Restrict write access to those stores and to the configuration pipeline, and require review for edits that change a reference rather than a value. Confirm with your team whether values written to etcd are encrypted at rest for your version, since that control is covered in the security hardening topic.
Audit reads and changes at the backend
Enable audit logging on Vault, AWS Secrets Manager or GCP Secret Manager so each read by a gateway identity is recorded with its path and time. Alert on reads from unexpected identities, on repeated failed reads, and on policy or secret changes. Ask who receives these alerts and how long the logs are kept, because those answers depend on your backend and retention policy.
Rotate without copying values
Rotate a secret at the backend and let the gateway pick up the new value, so the reference in APISIX never changes. Do not paste values into tickets, chat, Git commits, Admin API request logs or access logs, and check that your log formats and the debug output of your team's tooling do not print them. Plan a rotation test in a non-production environment first, and record the rotation date and owner, not the value.
Common secret reference failures and how to fix them
This table lists the failures most often seen when APISIX resolves a secret reference to Vault or a cloud secret manager, with the likely cause and a check the operator can run. Read each row as a triage step: confirm the symptom, test the cause, then apply the fix before changing route or plugin configuration.
| Failure | Likely cause | Fix to check |
|---|---|---|
| Backend unreachable from gateway nodes | Network path, DNS or security group rules block the gateway nodes from the secret backend address | Run a connectivity test from each gateway node, not only from your workstation, to the backend endpoint and confirm the port is open in network policy |
| Expired or revoked gateway token | The Vault token or cloud credential used by APISIX has passed its lifetime or was revoked during rotation | Check the token's time-to-live and renewal settings, then confirm the gateway still authenticates with a test read before the next scheduled rotation |
| Wrong path or key name in the reference | The secret reference uses a mount, path, or key name that differs from what was stored, including case and trailing slashes | Read the secret with the backend's own CLI using the exact path from the reference, and compare key names character by character |
| Policy missing read access | The Vault policy or cloud IAM role bound to the gateway identity does not grant read on the specific secret path | Test the gateway identity's permissions against that one secret path, and grant read on that path only rather than broad wildcard access |
| Certificate trust failure to the backend endpoint | The backend presents a certificate signed by an internal CA that the gateway host does not trust | Confirm the CA bundle the gateway uses for the backend connection contains the issuing chain, and verify the chain with a TLS client from the gateway node |
| Changed secret version not picked up after rotation | APISIX keeps the value it resolved earlier, so the new version is not used until the cache refreshes or the gateway reloads | Confirm the cache or reload behavior for your APISIX version in the deployment documentation, and test rotation in staging with a request before and after the change |
| Standalone file references a value the environment does not provide | The YAML or JSON file uses an environment variable name that is not set on the host, container or pod | Compare every referenced variable name with the runtime environment on each node, and fail the deployment check if any referenced variable is empty |
How rotation works without restarting the gateway
Rotation has two parts, and only the first happens in the secret manager. The value changes in Vault, AWS Secrets Manager or GCP Secret Manager, and then APISIX must pick up or re-resolve that value before consumers see it. Treat these as separate changes with separate checks. In file-driven standalone mode, APISIX checks conf/apisix.yaml or conf/apisix.json every second and hot-reloads, so a change to the file is applied quickly without a restart. That timing describes configuration files, not necessarily the values behind a secret reference. Confirm with the vendor whether a resolved secret is fetched on a timer, on each configuration reload, or only when the configuration containing the reference changes. Your rotation runbook depends on that answer.
Plan for an overlap window in which both the old and new credential are valid. Upstream services and API consumers do not switch at the same instant as the gateway, so the backend must accept the old value until every caller has moved to the new one. For a key issued to a consumer, create the new key before retiring the old one. For a credential APISIX uses to call an upstream, confirm that the upstream accepts both values during the change. Rehearse the sequence in staging first: write a new version of the secret, confirm that APISIX resolves it through the reference you configured, send test traffic through the affected route, then revoke the old value and confirm that requests still succeed. Record how long the gateway took to reflect the change, since that duration sets the minimum overlap you need.
Decide in advance what happens when a rotated value does not resolve. Confirm whether APISIX keeps serving the last value it resolved, fails the affected route, or fails every request that depends on the reference. Each answer changes your alerting and your rollback plan. Add a check that the gateway resolves the new value after each rotation, and monitor authentication failures on the affected routes so a revoked credential does not become a silent outage. Keep the previous secret version available until that check passes. Verify the behavior in your own environment, because it may differ by secret backend and deployment mode.
Questions teams ask before connecting APISIX to a secret manager
Can our own team connect APISIX to a secret manager without a partner?
Yes, if the team already runs APISIX and owns the secret backend, because the core task is configuration: setting up the secret provider, writing references in route, consumer and plugin fields, and testing failure behavior. The skills needed are APISIX Admin API or configuration-as-code experience, working knowledge of the backend you choose (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager or environment variables), and enough IAM or policy experience to grant the gateway read access with least privilege. Teams without that mix often find the access model and rotation testing take longer than the APISIX change itself. A partner typically adds value in reviewing the design and testing failures, and the written scope should state which of those tasks is included.
What drives the effort of a secret manager integration?
The main drivers are the number of routes and consumers that hold credentials, the number of secret types (API keys, client secrets, TLS certificates, upstream passwords), and how mature your existing secret backend is. A backend with clear paths, owners and access policies is much quicker to integrate than one where secrets are shared across services. Multi-environment setups add work because each environment needs its own backend namespace, access policy and test path. Air-gapped networks add work for certificate distribution, offline backend access and change control. Ask for the effort breakdown by these drivers in the written scope rather than a single figure.
What do we need to provide before the work starts?
Expect to provide network and access paths from the APISIX data plane to the secret backend, a test or staging backend for validation, and a change window for each environment where gateway configuration will be reloaded. You also need a named owner for each secret type who can approve access, confirm rotation schedules and answer questions about which upstream depends on which credential. Read-only service identities or roles for the gateway, created by your security team, are required before configuration begins. Confirm these items with your platform and security leads during scoping, since they determine whether the schedule holds.
How long does the integration take?
The duration depends on the scope, so the timeline is set in the written scope agreed before work starts rather than estimated here. The scope should list the backends in use, the number of routes and consumers to migrate to references, the environments covered, the failure tests to run and the handover tasks. Engagements are fixed-scope, so the agreed timeline reflects that list. If your change control requires approvals per environment, include those approval periods in the timeline you request.
Do APISIX secret references replace the audit trail in our secret manager?
No. APISIX resolves a reference at runtime by reading the value from the backend, so the secret manager still records the read under the gateway's identity, and that record remains your primary audit trail for secret access. APISIX configuration stores the reference, not the secret value, which keeps credentials out of route definitions and version control. Confirm with your backend documentation how each read is logged, how long logs are retained and whether they reach your SIEM. Gateway access logs can add context about which route used a credential, but they should not be treated as a substitute for backend audit logs.
What recurring work remains after go-live?
Recurring work includes upgrading the secret backend and the APISIX release on its own schedule, reviewing the gateway's read permissions when routes change, and running rotation tests so that a rotated secret is picked up without an outage. Each secret type also needs an owner who confirms rotation, and someone must review failure alerts when a reference stops resolving. Plan a periodic check that environment variables and backend paths still match the configuration. Ask any partner whether these tasks are covered by a support retainer or left to your team, and state the frequency in the agreement.
What happens when a secret reference does not resolve?
The request that depends on the missing value fails, so the team must decide in advance whether the affected route should return an error or fall back to a safe state. Test each failure mode before go-live: backend unreachable, secret path missing, permission denied and an environment variable not set at startup. Configure alerts on these errors and confirm that the gateway logs contain enough detail to diagnose the fault without printing the secret itself. Confirm the exact resolution behavior for your APISIX version in the official documentation, since behavior can differ between configuration modes.
How DeployOpen scopes and delivers secret management for APISIX
DeployOpen plans and builds the secret references that keep API keys, credentials and certificates out of APISIX configuration, in infrastructure you control. Each engagement is fixed-scope, with the secret sources, failure behavior and handover agreed in writing before work starts.
How we scope
- Inventory every credential, API key and certificate that APISIX routes and plugins currently hold in configuration
- Agree which secret source each item uses: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager or environment variables
- Write down the expected behavior when a reference does not resolve, including whether routes fail closed or serve stale values
How we build
- Replace hardcoded values with secret references in plugin and upstream configuration, one route group at a time
- Set up access policies so each APISIX node reads only the secret paths it needs, under least privilege
- Test resolution failures in a non-production environment, including a missing secret, an expired token and an unreachable secret manager
How we hand over
- Document each secret reference, its owner, rotation steps and the alert raised when resolution fails
- Provide a runbook for rotating credentials without restarting the gateway, confirmed against your APISIX version
- Walk your platform and security teams through the configuration, verification results and open items before sign-off
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review secret references again when new routes, plugins or APISIX releases change how configuration is loaded
- Confirm with your secret manager vendor and your own environment any feature or access model not covered in the written scope
