Why the etcd cluster behind Apache APISIX needs its own operating plan
etcd holds the configuration that Apache APISIX gateways read, so whoever chooses traditional or decoupled mode also takes on running etcd. In traditional mode, the data plane and control plane run together and share one etcd cluster as their configuration store. In decoupled mode, separate data plane and control plane nodes still share one etcd cluster. Standalone mode is the exception: it has no etcd, and configuration comes from a YAML or JSON file or from the Admin API. Before you choose, decide which team owns the etcd cluster, who gets paged when it degrades, and how its backups and upgrades are scheduled, because those duties do not disappear with the gateway project.
The dependency matters most in the first decision. Traditional and decoupled modes both need an etcd release that APISIX supports, and the installation guide advises binding etcd port 2379 to localhost or removing the host mapping when host access is not needed. Confirm the supported etcd release for the APISIX version you plan to run, since that combination is set by the project, not by your platform team's default image. Also confirm which team controls the Admin API port 9180 in traditional mode, because changes made there are written into etcd and reach every gateway that reads it.
A dedicated etcd plan is needed in any environment where traditional or decoupled mode is selected, and it is needed before the first production route is published. It should cover placement and sizing, mTLS between APISIX and etcd, what gateways do during an etcd outage, and tested restores. Teams that choose standalone mode can skip most of this plan, but they take on a different set of controls for configuration delivery and change review. Ask the implementation partner, or your own platform team, to state the chosen mode in writing so the etcd scope is settled before infrastructure is ordered.
Which etcd layout fits each APISIX deployment mode
This table compares the three APISIX deployment modes by when each fits, who operates etcd and the main trade-off. Read each row as a decision: if your team cannot run a shared etcd cluster safely, standalone mode removes that duty, while traditional and decoupled modes keep configuration in etcd. Confirm etcd version and sizing requirements against the installation guide for your APISIX release before choosing.
| Deployment mode | When it fits | Who operates etcd | Main trade-off |
|---|---|---|---|
| Traditional (data and control plane together) | Single-site gateways where one team owns both the Admin API and client traffic and the number of gateway nodes is modest | The platform team runs etcd alongside the gateway nodes, with the same change window | Admin API and client ports share the same nodes, so exposure and load must be controlled on one tier |
| Decoupled (separate data and control plane, shared etcd) | Multiple data plane locations or zones that must receive configuration from one control plane | A dedicated team or platform group runs the shared etcd cluster that both planes depend on | etcd becomes a shared dependency, so its health, certificates and backups affect every connected data plane |
| Standalone (file or API configuration, no etcd) | Environments that must avoid running etcd, or where configuration is delivered from a file in Git or through the API | No etcd cluster to operate, but the team must manage the configuration file or API delivery path | Configuration changes are delivered by file or API rather than a shared store, so delivery pipelines and reload checks carry the consistency burden |
| Need for mTLS to etcd | Any etcd-backed mode where etcd traffic crosses hosts or networks you do not fully control | The same team that runs etcd manages its server and client certificates | Certificate rotation must be planned for etcd as well as the Admin API and upstream connections |
| Host exposure of etcd port 2379 | Only when local tooling on the same host needs direct access to etcd | The operator who binds or removes the host mapping | The installation guide advises binding 2379 to localhost or removing the host mapping when host access is not needed |
| Confirming version requirements | Before any etcd-backed installation or upgrade | The engineer planning the release | etcd version support differs by APISIX release, so verify the supported etcd release in the installation guide for your target version |
How APISIX reads configuration from etcd
In the etcd-backed modes, the Admin API writes route, upstream, consumer and plugin configuration into etcd, and each APISIX data plane instance reads that configuration from etcd and applies it in memory. A change made through the Admin API does not require a restart of the gateway. Before 3.6.0, the data plane could also receive configuration through a gRPC connection to etcd, controlled by the etcd.use_grpc option, and through a conf server that sat between the two. APISIX 3.6.0 removed the gRPC path, the etcd.use_grpc option and the conf server, so every data plane now talks to etcd directly over the etcd client protocol. Confirm the exact behavior of your target release in the APISIX changelog before you plan the rollout.
This change affects three areas you should review before any upgrade. First, network paths: each data plane node needs direct reachability to the etcd client port, so firewall rules, security groups and any proxy or load balancer in front of etcd must allow those connections from every gateway subnet, including remote or edge sites in a decoupled deployment. Second, certificates: because data planes connect to etcd directly, the etcd TLS and mTLS settings under deployment.etcd.tls must be valid on every gateway node, and certificate rotation must update all of them, not only the control plane. Third, upgrade planning: a gateway on a release older than 3.6.0 cannot be treated as a simple binary swap if it relies on the removed options, so inventory your config.yaml files for use_grpc and any conf server references first.
Confirm with your own environment which etcd release your chosen APISIX version supports and whether your current configuration files contain any removed settings. A practical check is to run a non-production gateway against a test etcd cluster, change a route through the Admin API, and confirm the change reaches the data plane without a restart, while watching network connections from the gateway to the etcd client port. Record the result as part of your upgrade runbook so the same check can be repeated for each version in your upgrade path.
Sizing and placement decisions for the etcd cluster
Six decisions shape how the etcd cluster behind APISIX behaves under failure: how many members, how they are spread, how far apart they sit, how fast their disks write, and what else shares them. Each one trades availability against latency and operating effort. Confirm every numeric threshold against the etcd release your APISIX version supports and against benchmarks run in your own environment.
Member count and quorum
etcd accepts writes only when a majority of members agree, so the cluster tolerates the loss of a minority of members. Adding members raises fault tolerance but also adds replication work for every write. Ask your platform team how many simultaneous member losses you must survive, then size the cluster to that requirement rather than to habit. Confirm the recommended member count in the etcd documentation for your release.
Odd-numbered membership
An even number of members adds cost without adding tolerance for a network split, because a split can leave neither side with a majority. Odd membership gives each failure scenario a clear winner. Check that the member count you choose is odd and that any member you add during a migration or scale-out keeps the count odd once the change completes.
Failure domains across zones or racks
Members placed on one host, rack or availability zone fail together when that domain fails. Spread members so that losing the largest single domain still leaves a majority. Map each member to its failure domain on paper before provisioning, and confirm that your hypervisor, storage and network layers do not silently co-locate members on shared hardware.
Latency between members
Each write waits for a majority round trip between members, so inter-member latency sets the floor for write latency across the whole gateway estate. Cross-region placement increases both latency and the risk of split decisions. Measure round-trip time between candidate sites under realistic load, and compare the result with the tuning guidance in the etcd documentation for your release before accepting a placement.
Disk speed for the write-ahead log
etcd persists every committed change to its write-ahead log and calls fsync on it, so slow or shared disks delay writes and can trigger leader elections. Use dedicated, low-latency storage for the etcd data directory and avoid network-backed volumes shared with noisy neighbors. Benchmark fsync latency on the actual volume with the etcd tooling your release provides, and treat the result as the acceptance test for the host.
Shared or dedicated etcd
Running etcd on the same hosts as other workloads makes its disk and CPU timing depend on those workloads, and an overloaded host can delay heartbeats enough to cause instability. A dedicated etcd cluster is simpler to size and recover, but it adds hosts to patch and back up. Ask who owns the cluster, whether APISIX deployments in several clusters share it, and how the choice fits your decoupled or traditional deployment mode.
How to stand up etcd for APISIX step by step
This sequence takes an empty set of servers to a healthy etcd cluster that APISIX can read from and write to through its Admin API, with each step closed by a check you can run yourself.
Confirm the supported etcd release
Before any server is provisioned, the platform owner checks the APISIX installation guide for the etcd release that matches the APISIX version you plan to run. Record the exact etcd version in the build record and pin it in your configuration management so every member runs the same release. Done when the chosen version, and the APISIX version it pairs with, are written down and approved. Confirm the matching release with your APISIX vendor or partner before you buy hardware, because APISIX 3.6.0 removed gRPC between APISIX and etcd, which changes what your gateways expect from the store.
Provision members across failure domains
The infrastructure team creates an odd number of etcd members, typically three or five, and places each one in a separate failure domain such as a rack, host group or availability zone that your environment actually provides. Odd counts matter because a majority is needed to keep writing. Use fixed addresses and time synchronization on every member, and keep the etcd disks dedicated and low-latency. Done when an inventory lists each member, its address, its failure domain and its disk, and a reviewer has confirmed that no single failure domain holds a majority.
Restrict client port 2379 exposure
On each member, the operator binds the etcd client port 2379 to localhost or removes the host port mapping when no host process needs direct access. APISIX reaches etcd over the network, so the operator then opens 2379 only from the gateway network segment, and confirms the restriction with a port scan from an unapproved host. The installation guide advises this limit when host access is not needed. Done when a scan from outside the approved gateway segment shows port 2379 closed, and the gateway segment can still connect.
Enable mTLS on the etcd connection
The platform owner issues certificates for the etcd peers and for the APISIX client, then configures TLS on the etcd members. The matching client settings go into the APISIX configuration under the deployment etcd TLS block, so APISIX presents its own client certificate and verifies the etcd server certificate. Keep certificate expiry dates in your monitoring. Done when an etcd client command that presents no certificate is rejected, and a command using the APISIX client certificate succeeds.
Configure etcd settings in APISIX
The platform owner edits the APISIX configuration file to set the deployment etcd host list, using the endpoint addresses of every member, the TLS block from the previous step, and the key prefix that separates this environment from others. Keep the Admin API key out of the file and supply it through the process environment or your secrets manager, as your deployment method allows. Done when a configuration review confirms that every member address appears, no secret is stored in plain text in the file, and the APISIX process starts without configuration errors in the logs.
Verify cluster health and quorum
The operator runs the etcd member list and endpoint health commands against every member, then stops one non-leader member in a test window and confirms the remaining members still elect a leader and accept a write. Restart the stopped member and confirm it rejoins and catches up. Done when all members report healthy, the leader election succeeds after the test stop, and the restarted member shows the same revision as the others. Record these outputs as the baseline for later operations.
Confirm APISIX reads and writes through Admin API
The operator creates a test route through the APISIX Admin API on the Admin port, requests that route through the data plane, then deletes it. The write confirms APISIX can store configuration in etcd, and the request confirms the gateway reads it back. Check the etcd side too, by listing the keys under the environment prefix before and after the test. Done when the route returns the expected response from the data plane, the key appears and disappears in etcd, and the test is logged in the build record. Any test route is illustrative and should be removed before the environment is handed over.
Securing etcd connections with mTLS and network controls
etcd holds the entire APISIX configuration, so its connections deserve the tightest controls in the gateway stack. APISIX documents mTLS on four surfaces: the Admin API (configured with https_admin and admin_api_mtls), connections to etcd (configured under deployment.etcd.tls), client connections to the gateway (set per SSL object through client.ca and client.depth, HTTPS only), and connections from the gateway to upstreams (tls.client_cert and tls.client_key). This section concerns the etcd surface, but the four are separate settings. Enabling one does not secure the others, so your review should list each one explicitly and record who owns it.
Certificate issuance for etcd should come from an internal certificate authority that your security team controls, with separate identities for the etcd peers, the etcd clients used by APISIX and any operator tooling. Decide who issues, renews and revokes each certificate, and where the private keys are stored. Rotation ownership is the control most often left undefined: name one team for the etcd peer certificates and another for the APISIX client certificates, and confirm that a rotation can be rehearsed without a gateway outage. Ask the APISIX version you plan to run for the exact deployment.etcd.tls fields, and confirm them in a non-production cluster before you rely on them.
On the network side, treat the etcd client port and the peer port as private. Only the APISIX nodes and the etcd members should reach them, and the peer port should never be reachable from the client network. The APISIX installation guide advises binding the etcd client port 2379 to localhost or removing the host mapping when host access is not needed, so apply that rule in containers and virtual machines alike. Keep the Admin API, which listens on port 9180 in traditional mode, off public and general corporate networks as well, and restrict it to the administrators or automation that manage routes. Review the mTLS documentation next, then test each rule with a connection attempt from a host that should be blocked.
What happens to gateways when etcd is unavailable
An etcd cluster with three or more members keeps serving while one member is down, as long as the remaining members still form a majority. In this case the Admin API keeps accepting reads and writes because the cluster can still commit changes, and gateways keep reading configuration through the endpoints that remain reachable. The main risk is not an outage in this state but a second failure that removes the majority before the first member is restored.
- Writes continue: Route, upstream and consumer changes commit normally, so operators can keep working through the Admin API during the failure.
- Endpoint lists matter: Confirm that APISIX and any tooling that calls the Admin API list every etcd endpoint, so requests move to a healthy member.
- A second failure changes everything: In a three-member cluster, losing one more member removes quorum and moves the situation into the next tab.
- Repair before the next change window: Replace or recover the failed member before taking another node down for patching or upgrades.
In a non-production cluster, stop one member and confirm that Admin API calls and gateway traffic show no sustained errors for your APISIX version and endpoint configuration.
When fewer members than a majority are available, etcd stops committing writes. The Admin API then cannot persist any route, upstream, plugin or consumer change, and reads may fail or return data that is not current, depending on the request and the surviving members. Gateways are expected to keep serving the configuration they last loaded, but the operator loses the ability to correct a bad change, revoke a credential or roll back a release through the normal path.
- Writes are rejected: Creating, changing or deleting configuration fails until a majority returns, so an emergency fix cannot be pushed this way.
- Do not force changes by hand: Editing data directories, restarting gateways with altered files or bypassing etcd can leave the gateways and the cluster disagreeing about the last good state.
- Test whether served traffic persists: Confirm that existing routes keep answering while quorum is missing, and confirm what a restarted gateway does when it cannot reach etcd.
- Recover from a known good state: Restore quorum by bringing back members with intact data, and use a verified snapshot only when the members cannot recover.
In a non-production cluster, remove quorum on purpose, attempt a route change and a gateway restart, and record each result so the runbook reflects your version's actual behavior.
A full outage means every etcd member is unavailable. The Admin API has no source of truth to write to, so configuration changes stop completely. The gateways that are still running depend on what they already hold in memory, and this is the scenario where a routine restart can turn a contained incident into a service outage. The deployment mode determines how much of the control path is affected, so review the deployment modes documentation for your topology before testing.
- Admin changes stop: No route, plugin or credential change can be saved, so incident responses that need a configuration change must wait or use a documented fallback.
- Restarts carry the most risk: A gateway that restarts while etcd is down may not be able to load its configuration, so limit restarts and drain nodes deliberately.
- Check what the Admin API still answers: Confirm which read operations work on each gateway node during the outage, since behavior differs by mode and version.
- Restore from verified backups: Keep tested etcd snapshots and document the restore order, the member identities and the steps to confirm that gateways reload the restored data.
In a non-production environment, stop the whole etcd cluster, restart one gateway node, and confirm whether it serves traffic and whether the Admin API responds before you write this into your incident procedure.
A network partition is the least visible failure. The etcd cluster is healthy and the Admin API can still write, but some gateways cannot reach etcd, either because of a firewall rule, a routing change or a failed load balancer path. Those gateways stop receiving updates while the rest of the fleet moves forward, so the environment slowly splits into two configurations. The operator often sees a successful change and only later discovers that part of the fleet never applied it.
- Silent drift: Route updates reach only the connected gateways, so requests can be served by different rules depending on which node receives them.
- Revoked credentials may remain active: A consumer deleted or disabled in etcd can keep working on a partitioned gateway, which matters for security and audit evidence.
- Watch for connection failures: Alert on gateway logs that show failed etcd connections, and compare the configuration each node reports after every change.
- Test the blocking rule on purpose: Block the etcd client port from one gateway subnet in a lab, then confirm which changes reach that subnet and how the gateways report the fault.
In a non-production environment, partition one gateway group from etcd, make a route change and a consumer deletion, and verify on each side whether the change took effect.
Backing up etcd and restoring APISIX configuration
For APISIX in etcd-backed modes, etcd holds the routes, consumers, plugin settings and TLS objects that the gateway serves, so its backup is the main recovery point. The cards below cover what to snapshot, where to keep it, how to protect it, how to prove it restores, and how a Git copy of the configuration shortens recovery.
Snapshot the etcd cluster on a schedule
Take regular etcd snapshots from a healthy member, because a snapshot is the only point-in-time copy of the keys APISIX reads. Choose the interval from how much configuration change you can afford to lose, since changes made after the last snapshot are gone after a restore. Confirm the snapshot command, flags and any required certificates with the etcd release you run, because tooling differs between versions. Record the snapshot time and the etcd version next to each file so the restore team knows which release to use.
Store copies off the etcd cluster
Keep snapshots in storage that survives loss of the etcd nodes, the hosting account and the site, such as a separate account or a second data center you control. A snapshot stored on the same disks as the cluster protects against nothing worth the name. Define who can read, write and delete backups, and set retention so old copies age out on a documented rule. Ask your storage team to confirm immutability or object lock options if your policy requires them.
Encrypt backups that contain keys
Snapshots hold more than routes. Consumer credentials, upstream client keys and SSL private keys stored through the Admin API can appear in the data, so treat each file as a secret. Encrypt snapshots at rest with keys held outside the etcd cluster, and limit decryption rights to the restore role. Confirm with your security team how APISIX-stored secrets are protected in your version, and whether a secrets manager should hold those values instead of etcd.
Test restores into a separate cluster
A backup that has never been restored is an assumption. Run a restore into a separate, non-production etcd cluster on a schedule, then point a test APISIX data plane at it and confirm that routes, consumers and certificates behave as they did in production. Time the steps and write down each manual action, so the runbook matches what the team will actually do under pressure. Repeat the test after each etcd or APISIX upgrade.
Keep APISIX configuration in Git
Store the route, service, consumer, plugin and upstream definitions in a version-controlled repository, so you have a second copy that is readable and reviewable. A Git copy lets you rebuild a gateway on a fresh cluster and shows what changed and who changed it. It does not replace etcd snapshots, because Git will not hold runtime state or values changed directly through the Admin API. Decide which team owns the repository and whether manual Admin API edits are allowed at all.
Plan for drift between backup and live state
Any restore brings back the state at the snapshot time, so changes made afterward must be found and reapplied. Compare the restored configuration against the Git copy and the change log, then list anything that differs before routing traffic. Confirm with your change owners how to handle certificates renewed after the snapshot, since an old certificate in a restored cluster can cause outages. Include this reconciliation step in the restore runbook.
Upgrading etcd alongside APISIX without an outage
Upgrade etcd and APISIX as two separate, sequenced changes, each checked against the version matrix before work starts. The APISIX installation guide asks for a supported etcd release in etcd-backed modes, so the first step is to confirm in the current APISIX documentation which etcd releases your target APISIX version supports, then record both target versions in the change ticket. Do not assume that the etcd version you run today is still supported after an APISIX upgrade. Confirm the matrix with the APISIX project, then plan the order of the two changes so that neither component runs on an unsupported combination for longer than the window requires.
Take a snapshot of etcd before touching any member, and verify that the snapshot can be restored in a test environment. Then upgrade members one at a time, leaving the cluster with a healthy quorum throughout. After each member restarts, check member health and confirm that all members agree on the leader and that the revision is advancing before moving to the next node. Stop the rollout if any member fails to rejoin. Pin the exact etcd and APISIX image or package versions, and the snapshot file name and checksum, in the change record so that a rollback targets a known state.
Review the etcd connection settings in the APISIX configuration as part of every APISIX upgrade. The APISIX 3.6.0 release removed gRPC between APISIX and etcd, the etcd.use_grpc option, and the conf server, so data planes read configuration from etcd directly. Any configuration copied from an older release that sets those options or assumes the conf server needs to be reviewed before the upgrade, not discovered during it. Read the APISIX changelog for every release between your current and target versions, and run the upgrade in a staging environment with the same etcd topology before production.
Security and operational controls for the etcd layer
The etcd cluster holds every route, consumer and plugin setting that APISIX reads, so it carries the same sensitivity as the gateway itself. The controls below cover network exposure, member trust, key material, change history, health visibility and who may touch the store. Confirm which of these your etcd release and APISIX version support before you commit to a design.
Restrict the client port
Limit client access on port 2379 to the APISIX gateway nodes and the admin networks that run configuration tooling. The installation guide advises binding 2379 to localhost or removing the host mapping when host access is not needed, which is the first control to check in a container or VM deployment. Confirm the firewall rules on every node and in any Kubernetes network policy that reaches the etcd Service.
Authenticate peer members
Protect traffic between etcd members on the peer port with mutual TLS so that only certificates issued for the cluster can join or replicate data. Ask your etcd release for its peer authentication options and how certificate rotation is done without a full cluster restart. A rogue member that joins the cluster can read and rewrite gateway configuration, so treat peer trust as a hard requirement.
Protect keys and backups
Store the etcd client certificates that APISIX uses in deployment.etcd.tls in a secrets manager, not in plain files baked into images. Snapshots contain the Admin API key and any secret values written as plugin configuration, so encrypt backup archives and restrict who can restore them. Confirm how your etcd release handles encryption at rest and whether snapshot files can be encrypted before they leave the cluster.
Audit configuration writes
Record every write to the APISIX configuration path, including who made it and from which pipeline or account. Writes arrive through the Admin API on port 9180 and directly through etcd, so logs from both paths are needed to explain a change. Ask whether your etcd release exposes audit logging for key writes and whether you can forward those events to your SIEM with retention that matches your policy.
Monitor member health
Alert on member health, leader elections and failed or slow proposals, because a leader change can briefly stall configuration writes even when the gateway keeps serving traffic. Track disk latency and database size on each member, since both affect commit times. Decide which alerts page the platform team and which open tickets, and test each alert by stopping one member in a non-production cluster.
Separate etcd and operator access
Give routine operators access to the APISIX Admin API through named roles, and keep direct access to etcd for a small break-glass group. Direct writes bypass APISIX validation and any review step in your change process, so they should be rare and logged. Review who holds etcd credentials each quarter and remove access when a person changes role.
Questions teams ask before running etcd for APISIX
What does the etcd work cost and what drives the price up?
Cost depends on the written scope, not on a list price, and DeployOpen does not publish one. The main components are design work (cluster size, placement, failure domains), setting up the cluster, configuring mTLS between APISIX and etcd, wiring up backups, testing restores, and planning etcd and APISIX upgrades. Costs rise with the number of environments, the number of gateway clusters that share one etcd, strict certificate requirements, and whether etcd runs in an air-gapped network. Setup is largely one-time. Backup verification, upgrades and monitoring recur, and the choice between running them yourself or under a retainer decides how much recurs. Ask for the cost of each component separately, and ask which items are one-time and which are monthly or per-upgrade.
How long does an etcd build take, and what changes the timeline?
Duration depends on the environment more than on etcd itself. The biggest variables are whether the target is a cloud account, a data center or an isolated network, how many clusters and environments need an etcd, how quickly certificates can be issued by your PKI team, and how long your change approval process takes. Restore testing usually takes longer than the initial install because it needs a realistic data set and a window agreed with the business. Ask the vendor for a written timeline with milestones tied to your own dependencies, and confirm which of those dependencies sit outside the project.
What does our team need to provide for an etcd deployment?
Plan for four areas of input before work starts:
- Network: agreed subnets, firewall rules that keep the etcd client port (2379) private, and routes between APISIX nodes and etcd members.
- Certificates: a CA or PKI process that can issue server and client certificates for etcd peers and APISIX.
- Storage: low-latency disks for each member, with capacity for snapshots and backups.
- On-call: a named owner who receives etcd alerts and can approve a restore or a rolling upgrade.
Confirm who in your organization holds each of these before the engagement begins.
Can our own team run etcd for APISIX using the installation guide?
Yes, a capable platform team can install and run etcd for APISIX using the official installation guide, provided it has Linux operations skills and time to test failure scenarios. The guide asks for a supported etcd release in etcd-backed modes and advises binding port 2379 to localhost or removing the host mapping when host access is not needed. What teams most often skip is the hard part: testing member loss, restoring from a snapshot, and rehearsing an upgrade. Decide early whether your team will own those tests. A partner can also run a readiness review of an existing etcd setup without taking over operations.
When does standalone mode remove the need for etcd?
Standalone mode removes etcd when configuration can be delivered from a file or through the API, and when you can accept that the gateway does not share one live configuration store. APISIX documents three modes: traditional, decoupled and standalone, with standalone running without etcd and reading configuration from a YAML or JSON file or the API. In file-driven standalone mode, APISIX checks conf/apisix.yaml or conf/apisix.json for changes every second and hot-reloads them. Standalone suits GitOps-managed gateways with a small number of nodes. Traditional or decoupled mode remains the better fit when you need live Admin API changes that persist across nodes. Review the mode choice against your change process before committing.
What should we ask for in a quote for etcd operations?
Ask for a written scope that lists each item and the party responsible for it. The quote should cover cluster design, installation, mTLS for etcd peers and client connections, backup scheduling and retention, a tested restore, upgrade procedure and rehearsal, monitoring and alert thresholds, and handover documentation. Request separate line items for one-time work and recurring support, and ask what is excluded, such as certificate authority setup or application changes. Confirm the acceptance criteria, for example which failure scenarios are tested and who signs off. Also ask how changes to scope are priced.
Which etcd and APISIX versions should we plan around?
Plan around the versions your APISIX release supports and confirm them against current project documentation before you fix a design. APISIX 3.6.0 removed gRPC between APISIX and etcd, removed the etcd.use_grpc option and removed the conf server, so data planes read configuration from etcd directly. Check the APISIX changelog for each release you plan to run, and confirm the etcd release your chosen APISIX version expects. Ask the vendor to name the versions in writing as part of the scope.
How DeployOpen scopes, builds and supports APISIX etcd operations
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the etcd cluster that Apache APISIX depends on in traditional and decoupled modes. Each engagement starts from a written scope that fixes deliverables and timelines before work begins.
How we scope
- Confirm which APISIX deployment mode you run and whether etcd is in scope at all.
- Record etcd placement, sizing inputs, network paths and which gateways depend on each cluster.
- Agree in writing which mTLS links, backup targets and upgrade windows the engagement covers.
How we build
- Deploy etcd in your environment with client and peer TLS configured and client port 2379 kept off public interfaces.
- Test failover by stopping etcd members and confirming how each gateway behaves during the outage.
- Run a restore test from backups into a separate environment and record the measured recovery steps.
How we hand over
- Provide runbooks for member replacement, certificate rotation, backup restore and version upgrades.
- Document the configuration, monitoring thresholds and alerts that your operators will use day to day.
- Walk your platform and security teams through the handover and the open items that remain with you.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
- Review etcd version changes against APISIX release notes before scheduling any upgrade in your environment.
- Ask for a quote based on the written scope, since DeployOpen does not publish a price list.
