Why teams run TCP and UDP stream proxying with Apache APISIX
A team runs TCP and UDP stream proxying with Apache APISIX when it needs one controlled entry point for databases, message brokers or legacy protocols that HTTP routing cannot carry. APISIX can proxy these layer 4 connections alongside its usual HTTP routes, so the same gateway team can manage access, TLS and upstream selection for traffic that is not web traffic. The first decision is whether this is a real need: if the protocol is HTTP-based, a standard route is usually the better fit, and stream mode adds a second configuration surface to operate.
Stream proxying is off by default. You turn it on by setting apisix.proxy_mode to stream or to http&stream in the configuration, which lets the gateway serve HTTP and stream traffic together. Stream routes then match incoming connections on server_addr, server_port, remote_addr and SNI, so you can separate listeners by port, by source network or by server name. Plan these matching rules before you write any routes, because overlapping matches on one port are the most common source of misrouted connections. Confirm the exact configuration keys and any version-specific behavior against the APISIX stream proxy documentation and your target release.
Apache APISIX is a top-level Apache Software Foundation project released under the Apache License 2.0, which matters if your legal or procurement team reviews open-source terms before adoption. The project's repository lists TCP and UDP proxying among its supported protocols, alongside HTTP, gRPC, WebSocket and MQTT. Your team should confirm which protocol features, such as TLS termination or payload-aware plugins, apply to your specific use case and release, and should test the exact database, broker or legacy client you need to front before committing to the design.
How to enable stream mode in APISIX
This sequence turns on APISIX stream proxying in the data plane, confirms that the stream listeners are active, and checks that client traffic and existing HTTP routes behave as they did before the change. Stream mode is off by default, so each step ends with a check you can record before any stream route goes live.
Record the current proxy mode and listeners
Before changing anything, the platform owner captures the current configuration file, the ports APISIX listens on, and the HTTP routes that must keep working. Stream proxying is off by default, so the baseline shows the HTTP-only state you will compare against later. Store this snapshot in version control or your change record. The step is done when you can name every client-facing port and every HTTP route that the change must leave untouched.
Set the proxy mode in configuration
An engineer with write access to the APISIX configuration sets apisix.proxy_mode to stream for layer 4 only, or to http&stream when HTTP routes and stream routes must run on the same gateway. The value belongs in the configuration file for the data plane, which is typically managed through your configuration-as-code pipeline. Confirm with the vendor documentation for your deployment mode how this key is delivered to the data plane. The step is done when the change is reviewed and committed, with no other settings modified in the same change.
Apply the change to the data plane
The operator restarts or reloads the APISIX data plane according to your deployment mode and the instructions in the deployment documentation, because proxy mode is read when the gateway starts its listeners. Restart one node first when you run several, and keep the rest in service behind your load balancer. Check the process logs for startup errors related to stream listeners or port binding. The step is done when the node reports a successful start and its logs show no listener errors.
Confirm the stream listeners are active
The operator checks that the expected stream ports are bound on the data plane host, for example with the operating system's socket listing tool, and that the stream subsystem appears in the gateway's startup or status output. Compare the list against the ports you planned for databases, brokers or legacy services. The step is done when every planned port is listening on the expected interface and no unplanned port has appeared.
Test client traffic on the configured ports
A network engineer sends a test connection from a client network segment to each configured stream port, using a non-production route or a test upstream that returns a known response. Test from the same network zones your real clients use, because firewall rules are often the cause of failures that look like gateway faults. The step is done when the test connection reaches the upstream and the gateway access log records it. If the connection fails, check the security group or firewall rules before changing APISIX.
Verify HTTP routes after http&stream
When you chose http&stream, the team reruns the HTTP checks recorded in the baseline, covering status codes, authentication behavior, response headers and latency for a sample of routes. Compare results against the snapshot to confirm that enabling stream mode did not change HTTP behavior. Repeat the checks on each node as it is restarted. The step is done when every baseline HTTP route returns the same results as before the change, and any difference is logged and investigated before the next node is updated.
Record the verified state for operations
The platform owner saves the post-change configuration, the listener list, the test results and the HTTP comparison in the change record and the runbook for the gateway. Confirm with your team how stream listeners are monitored and alerted, since a stream port that stops listening may not show up in HTTP dashboards. The step is done when the record is complete and approved, and the team knows which checks to repeat after every future restart or upgrade.
Stream route options and when each fits
This table compares the stream route matching fields and TLS modes APISIX offers at layer 4, with the workload each one suits and the trade-off it brings. Read each row as a decision: match on the fields your listener can actually expose, then pick the TLS mode that matches who must see the payload.
| Option | Suits this workload | Trade-off to plan for |
|---|---|---|
| Match on server_port | A dedicated listener port for one database or broker, such as a single PostgreSQL or Kafka listener | Simple to reason about, but each backend needs its own port exposed at the gateway, which widens the firewall rule set |
| Match on server_addr | A gateway with several virtual or external addresses that serve different backends on the same port number | Depends on how addresses are assigned at the edge, so confirm the addressing with your network team before relying on it |
| Match on remote_addr | Restricting a route to known client networks, such as a partner range or an internal management subnet | Client addresses seen by the gateway may be load balancer or NAT addresses unless the PROXY protocol is in use, so verify what arrives |
| Match on SNI | Several TLS services sharing one port, each selected by the hostname the client sends in the handshake | Only works for TLS traffic that carries SNI, so plain TCP protocols cannot use it |
| TLS termination at the gateway | Clients connect with TLS and the backend speaks plain TCP, for example a legacy protocol that cannot handle encryption | The gateway holds the certificates and sees plaintext, so key handling and the internal hop between gateway and backend need controls |
| mTLS at the gateway | Clients or partner systems must present a certificate before a stream route is reached | Certificate issuance, rotation and revocation become operational work for both sides, and the trust store must be kept current |
| TLS to the upstream | The gateway accepts plain TCP from trusted clients but the backend requires encrypted connections | Adds a second TLS session per connection, and backend certificate validation must be configured and tested |
| TLS passthrough by SNI | An encrypted service where the backend must terminate TLS itself, such as an end-to-end encrypted broker listener | The gateway cannot inspect or modify the payload, so payload-level policy, logging and plugins are unavailable for that route |
Choosing a pattern for databases, brokers and legacy protocols
Relational database connections are usually TCP, often wrapped in TLS, and they are long-lived and sensitive. Most teams place APISIX in front of a database only when they need a controlled entry point, such as a shared jump path, IP allow-listing or connection auditing. In that case the stream route usually matches on server_port and remote_addr, because the database protocol does not carry a hostname that APISIX can read before the handshake. If the database client negotiates TLS, the choice is between terminating TLS at the gateway and passing the encrypted session through to the database.
- Passthrough for end-to-end TLS: The gateway routes by
server_portor, where the client sends it, SNI, and never sees query content. Certificate verification stays between the client and the database. - Termination for inspection of the session: APISIX presents its own certificate and opens a new TLS session upstream. This suits access control at the edge but means the gateway holds keys for that path.
- Matching on source address: Use
remote_addrto restrict which networks may reach the database port, and treat this as a boundary control rather than an identity control. - No payload-aware plugins: Expect no per-query rules, rate limits by SQL statement or query logging at layer 4.
Confirm with your database vendor whether its client requires SNI and whether it supports the TLS mode you intend to use before you pick a pattern.
Message brokers such as Kafka or MQTT brokers are multi-connection protocols. Clients connect to a bootstrap address and then reconnect to individual brokers, so the gateway can route the first connection while the protocol itself decides where later connections go. This makes broker traffic harder to front with a single stream route than a database. Teams usually decide early whether the gateway is a convenience for a few clients or a true broker entry point, because the answer changes the matching fields and the number of listeners.
- Per-broker or per-port listeners: Give each broker its own port or address so that redirects from the broker resolve correctly.
- Client ID or payload inspection: Plugins such as
mqtt-proxyread protocol content, so the gateway then sees client identifiers and session data. - PROXY protocol for source identity: Enable the PROXY protocol on the stream listener and confirm the broker is configured to read it, so that the broker sees the original client address.
- TLS choice per listener: Terminate for device or client authentication at the edge, or pass through when the broker must verify client certificates itself.
- Reconnect behavior: Test session resumption and failover against the gateway, because a stream proxy can change which node a reconnecting client reaches.
Check how your broker advertises its addresses to clients before deciding how many listeners and routes you need.
Legacy and custom TCP or UDP protocols are the least predictable group. They may have no documented TLS, may use fixed binary framing, or may rely on UDP where loss and ordering behave differently. APISIX can forward these streams, but the team must confirm the protocol has a stable port, a known source identity model and an acceptable failure behavior. For UDP and for protocols that encode an address in the payload, the gateway can match on port and source only, which often limits the design to one upstream per listener.
- Fixed port and framing: Stream routes match on
server_port, so each legacy service needs a dedicated listener that clients can reach. - Plain traffic on a trusted segment: When the protocol cannot be encrypted, keep the listener on a restricted network and document the risk.
- Payload plugins only where supported: The stream plugins named in the topic facts,
mqtt-proxy,xrpcandredis, cover specific protocols. A custom protocol usually needs a custom plugin, so price and schedule that work separately. - Client source preservation: Use the PROXY protocol where the upstream can parse it, or the upstream will see the gateway address for every client.
- Capacity and timeouts: Confirm idle timeout and connection limits with the application owner, since long-lived sessions behave differently from request and response traffic.
Before you commit, ask the protocol owner for a packet capture or a reference client so the team can test the exact framing through the gateway.
When to send the PROXY protocol to upstreams
Enable the PROXY protocol when an upstream needs the original client address and cannot get it from the connection itself. At layer 4, APISIX opens its own connection to the upstream, so the upstream normally sees the gateway's address as the source. Database access rules, broker authorization lists, audit logs and per-client rate limits built on the source IP all break silently when that happens. APISIX can accept the PROXY protocol on TCP ports and send it to upstreams, so the upstream can recover the real client address from a header before any payload is read. Confirm this is needed for each service before you change anything, because the header is only useful to software that understands it.
The setting can be applied globally or per port, and the choice changes the blast radius. A global setting affects every TCP stream listener, so a single upstream that does not parse the header will start failing every connection on every port. A per-port setting limits the change to the listeners whose upstreams you have tested. For a mixed estate of databases, brokers and legacy services, per-port configuration is usually the safer rollout, with the global setting reserved for a fleet where every upstream has been verified. Check the exact configuration keys for your APISIX version in the stream proxy documentation before you write them into configuration as code.
Before rollout, the upstream must be configured to parse the PROXY protocol, and the header version it expects must match what APISIX sends. Many servers need an explicit listener option to accept the header, and some reject ordinary connections once it is enabled, so the change should be tested on a staging listener first. Also decide which network paths can reach the upstream without the gateway, because a client that bypasses APISIX and sends its own header could spoof a source address. Restrict the upstream listener to the gateway's addresses, then confirm with a test connection that the logged source address matches the real client.
Which plugins work at layer 4
Stream routes carry raw TCP and UDP bytes, so most of the HTTP plugin catalog has nothing to act on. The plugins that do run at layer 4 either read a protocol payload or handle the connection itself, and each one depends on what the gateway is allowed to see.
mqtt-proxy for MQTT payloads
The mqtt-proxy plugin reads MQTT packets on a stream route so the gateway can route a client by its MQTT identity rather than only by IP address and port. That means the gateway parses the CONNECT packet, so it must see unencrypted MQTT traffic or terminate TLS first. Confirm which MQTT versions and routing keys your APISIX release supports before you design device session handling around it.
xrpc for custom binary protocols
The xrpc plugin lets stream routes understand the framing of an application protocol that APISIX does not handle natively, so requests can be matched and forwarded by parsed fields. Writing and maintaining that framing logic is your responsibility and sits outside the standard plugin set. Ask for the framing specification and a test corpus before committing a legacy protocol to this path.
redis for command-aware routing
The redis plugin inspects Redis commands on a stream route, which allows routing or policy decisions based on the command and key rather than the connection alone. Inspection requires the gateway to parse the Redis protocol, so clients must reach APISIX without TLS termination happening elsewhere in the path. Test your client library's pipelining and pub/sub behavior through the gateway, since those patterns change how requests are framed.
HTTP plugins do not apply
Authentication, request transformation, rate limiting by header and similar HTTP plugins need HTTP requests to act on, so they have no effect on raw TCP or UDP flows. Access control at layer 4 relies on the stream route match (server address, port, remote address and SNI) and on the network controls around APISIX. Plan authentication for these services in the backend or with network policy, and do not assume an HTTP plugin will protect a database port.
Confirm the plugin list first
Plugin support for stream routes changes between APISIX releases, and the set of payload-inspecting plugins should be checked against the version you intend to run. Build a short checklist per service that records the plugin, the release, the protocol version it handles and the test that proved it works. Treat any plugin not on that list as unavailable until your own tests show otherwise.
TLS termination, mTLS and passthrough trade-offs
The first decision is where TLS ends, because that choice sets what the gateway can see. When APISIX terminates TLS on a stream route, it holds the server certificate and private key, sees the decrypted bytes, and can apply its own logging and policy to them. Re-encrypting to the upstream adds a second TLS session on the backend leg, so the gateway becomes the trust boundary for both connections and must validate the upstream certificate. Requiring mTLS from clients adds a third control: the gateway validates a client certificate against a CA you choose. That identifies callers at the edge, but only if you decide which CA issues client certificates, how revoked certificates are handled, and whether the upstream receives any identity from the client certificate at all. Confirm each of these in writing before the route design is final.
TLS passthrough removes most of that visibility. The gateway reads the server name from the ClientHello, routes on SNI, and forwards the encrypted stream unchanged. It cannot write payload contents to its logs, cannot run payload-inspecting plugins such as mqtt-proxy, xrpc or redis against the traffic, and cannot key rate limits on anything inside the protocol, such as a command, topic or user. What it can still use are connection attributes like the client address, the listening port and the SNI value. Ask the team that owns the protected service which of its controls depend on payload inspection, and accept in the design that those controls move to the backend. The stream proxy documentation describes the matching options, which you should check against your protocol before choosing passthrough.
Certificate handling is the operational cost of each choice. Terminating and re-encrypting routes require the gateway to store private keys, so confirm where APISIX keeps certificate objects in your deployment mode, how those keys are protected at rest, and who can read or change them through the Admin API. Ask the vendor or your own tests whether a rotated certificate applies to new connections without a restart and what happens to connections already open. Passthrough routes keep the private key on the backend, which shrinks the gateway's key exposure but removes its ability to warn you about expiry. Plan certificate expiry monitoring for every listener, including passthrough ports, and agree on a rotation runbook that covers the client CA bundle as well as server certificates.
Security and operational risks of exposing raw ports
Stream routes put databases, brokers and legacy protocols behind a gateway that may not read the payload. The cards below name the controls your team owns for those ports, from the Admin API and etcd to the failover and connection limits you test before go-live.
Database and broker port exposure
A stream route makes a database or broker port reachable wherever the gateway listens, so the listener address and server_addr matching decide who can connect. Confirm that the listener sits on the intended network interface only, that upstream nodes accept connections only from APISIX addresses, and that authentication remains enforced by the database or broker itself, since a layer 4 proxy does not check credentials for you. Treat each exposed port as a new trust boundary.
Admin API and etcd protection
In traditional and decoupled modes, the Admin API on port 9180 can change every route, including stream routes that open new raw ports. Restrict that port to management networks, rotate the admin key, and keep etcd reachable only from gateway and control plane nodes with client certificates. A change to a stream route is a change to your network exposure, so review it with the same care as a firewall rule.
Network segmentation around the gateway
Place the gateway in a zone that can reach the upstream database or broker subnet and nothing else. Define which source networks may reach each stream listener, and make the firewall rules match the route definitions in version control. Ask your network team to confirm that return traffic and health checks follow the same narrow paths, and that no flat network lets clients reach upstreams around the gateway.
UDP session behavior
UDP has no connection setup or teardown, so the gateway tracks sessions by timeout rather than by a closed connection. Test how long idle sessions persist, how many a client can open, and whether replies return to the correct client after an upstream change. Check the timeout and session settings against the protocol you proxy (DNS, syslog, or a game or telemetry feed), and agree on a value with the application owner before production traffic arrives.
Logging gaps for passthrough traffic
With TLS passthrough or a payload-opaque protocol, the gateway sees only addresses, ports and, for SNI routes, the server name. It cannot log queries, topics or request paths. Decide which fields your audit trail needs, such as client address, route name, timestamps and byte counts, and confirm that the access log configuration captures them. Record in your runbook what the gateway cannot show, so investigators know where the missing detail lives.
Failover and connection limit tests
A stream route with several upstream nodes only protects you if failover has been tested under load. Simulate a node failure during active connections, confirm how established sessions are handled, and measure how the gateway behaves when the connection count reaches the limit your database or broker allows. Repeat these tests after every APISIX upgrade, because proxy behavior is part of what you certify, and keep the results as operational evidence.
Implementation sequence for a stream route
This sequence takes a database, broker or legacy TCP service from inventory to a production stream route on APISIX, with a check at each step so the team knows the route behaves before live traffic moves. The order matters because the proxy mode, termination choice and client tests each depend on the step before them.
Inventory ports, protocols and clients
List every TCP or UDP port the service uses, the protocol on each port, the client libraries and drivers that connect, and whether any client already sends or expects the PROXY protocol. Record which clients use TLS, which certificates they trust and whether they check the server name. Confirm with the application owners and the network team, since missing a secondary port or a hard-coded address is the most common cause of a failed cutover. Done when each port has a named owner, a protocol and a client list signed off by that owner.
Decide termination or passthrough
Choose whether APISIX terminates TLS on the stream route, using its own certificate and optionally mTLS, or forwards encrypted bytes unchanged by matching on SNI. Termination lets the gateway apply TLS policy and reach the certificate chain, but the upstream connection then needs its own TLS decision. Passthrough keeps end-to-end encryption and leaves the payload invisible to the gateway, so payload-aware plugins cannot run. Write the decision per port and confirm it with the security owner. Done when each port has a documented choice and the certificate owner is named.
Enable stream mode on the gateway
Set the proxy mode in the APISIX configuration to stream, or to http and stream together if HTTP routes share the same nodes. Stream proxying is off by default, so this change is required before any stream route will load. Apply the change in a non-production environment first and restart or reload the gateway according to your deployment mode. Done when the gateway starts cleanly, the stream listener is bound on the expected ports and existing HTTP routes still respond.
Create stream routes with matching fields
Define one stream route per service or per distinct match, using the fields the design needs: server port, server address, remote address or SNI. Set the upstream nodes, load balancing and TLS options in the same route. Keep each route narrow so an unexpected client cannot reach another backend, and note which match wins when routes overlap. Done when a single test client connecting to the gateway port reaches the intended upstream and a client on a different port or address does not.
Configure PROXY protocol where the upstream needs it
If the backend logs or authorizes by client address and expects the PROXY protocol header, enable it for the listening port or globally, and confirm the backend is configured to read it. Sending the header to a service that does not parse it breaks every connection, so the backend and gateway settings must change together. Ask the backend owner to confirm the exact parsing behavior before enabling it. Done when the backend log shows the original client address on a test connection and the service still accepts normal traffic.
Test with the actual client library
Run the real driver, client or SDK that production uses against the gateway address, not a generic tool alone. Exercise connection setup, authentication, a sustained query or message exchange, a reconnect after the gateway restarts and a failed upstream. Include TLS handshakes with the same certificate chain clients will see. Done when the application completes its normal workload through the gateway with no protocol errors, and the gateway access and error logs show the expected routes matching.
Roll out with a fallback path
Move a small share of clients or one environment first, while keeping the original direct address available so clients can be pointed back quickly. Watch connection errors, latency and upstream health during the window, and agree in advance which signal triggers a rollback. Keep the previous client configuration in version control until the rollout is accepted. Done when the rollback procedure has been rehearsed once, the owners have signed off the observation window and the direct path is retired only after that sign-off.
Limits to confirm in your environment
Stream proxying in APISIX touches protocol support, matching, certificates and release-specific behavior at once. The items below are the points we expect teams to verify against the current APISIX documentation and their own load and failure tests before they rely on a design.
Plugin support per protocol
Not every APISIX plugin runs on stream routes. Plugins that inspect HTTP requests, such as authentication or header rewriting, do not apply to raw TCP or UDP payloads. Check each plugin you plan to use against the stream proxy documentation, and confirm which payload-inspecting stream plugins exist in your release before you design around them, including mqtt-proxy, xrpc and redis.
UDP behavior under load
UDP has no connection state, so session tracking, idle timeouts and how the gateway handles bursts depend on the workload. Test with your real packet sizes, rates and client counts, and measure dropped datagrams, latency and memory. Do not assume that a design which works for low-volume DNS-style traffic will hold for telemetry or media streams.
Supported matching combinations
Stream routes match on server address, server port, remote address and SNI, but the combinations you need may not all be supported together or behave as expected on one port. Build a matching table for every route, including overlaps, and test each rule, especially where SNI passthrough and TLS termination share a listener.
Certificate handling and rotation
TLS termination, mTLS, TLS to upstreams and passthrough each place certificates in a different part of the path. Confirm how certificates are stored, loaded, reloaded and rotated in your deployment mode, and who owns expiry monitoring for the gateway certificates and the upstream trust chains. Verify client certificate validation behavior with your own CA.
PROXY protocol at the upstream
Sending PROXY protocol headers only helps if the upstream parses them. Confirm whether the upstream expects the header on every connection, and whether it is set globally or per port in your configuration. Test client address logging and access controls on the backend, because a mismatch can silently log the gateway address instead of the client.
Version-specific changes
Stream behavior, plugin availability and configuration keys can change between APISIX releases. Read the release notes for the version you intend to run, and check the current downloads page for the latest release before you pin a version. Repeat your protocol tests on every upgrade, since a release change can affect a route that previously worked.
Questions teams ask before running stream proxying
What drives the cost of a TCP and UDP stream proxy project?
The cost follows the scope you write down: how many protocols and ports you expose, how TLS is handled, whether PROXY protocol is needed, and how deep the testing goes. Each protocol adds its own routing, backend health checks and failure cases, so a single PostgreSQL listener is a much smaller job than a set of database, broker and legacy listeners on one gateway. TLS termination, mTLS and passthrough each change the certificate work and what the gateway can inspect. Testing depth matters too: a load and failover test against your real backends takes more effort than a functional check. Ask the quote to list each protocol, each port, the TLS model per route, the PROXY protocol decision and the test cases, since these are the items that move the price.
How long does stream proxying take to set up?
Duration depends on the same factors as cost, plus the speed at which your teams respond. The work is usually gated by access and decisions rather than by APISIX configuration itself: firewall changes, certificate issuance, confirmation of backend addresses, and agreement on health checks and timeouts. Each protocol that needs a separate test pass extends the schedule, and so does any change to how clients reach the gateway, such as DNS or load balancer updates. Ask for a timeline that separates the client-side tasks from the build tasks and shows which ones block others, so you can see where a delay would land.
What does our team need to provide for the project?
Four groups of input are needed before build work starts:
- Network access: firewall rules from client networks to the APISIX nodes and from the nodes to each backend port, plus the load balancer or DNS changes that send traffic to the gateway.
- Certificates: server certificates and keys for any termination route, the CA chain for mTLS, and the trust bundle for TLS to upstreams. Confirm who issues and rotates them.
- Upstream owners: a named contact for each database, broker or legacy system who can confirm addresses, ports, protocol versions and maintenance windows.
- Test environments: a non-production copy of each backend and a client that reproduces real traffic, so routes can be verified before cutover.
Missing any of these usually shows up as a delay in the first week, not as a technical problem.
Can our internal team build stream proxying without a partner?
Yes, a team with Linux, networking and TLS experience can enable stream mode and build stream routes from the APISIX documentation. The harder parts are usually outside the configuration: deciding how many protocols share one gateway, choosing where TLS ends, testing failover for long-lived database and broker connections, and writing the runbook for on-call staff. If your team has no one who has run a layer 4 proxy in production, an outside review of the design and test plan often costs less than an outage found after go-live. Confirm with your own engineers which of these skills they hold before deciding.
Which plugins work for TCP and UDP traffic?
Stream routes support a smaller set of plugins than HTTP routes, because layer 4 traffic has no HTTP headers or paths to act on. The stream proxy documentation names mqtt-proxy, xrpc and redis as payload-inspecting stream plugins, and these only work for their specific protocols. Many HTTP plugins, such as those for header rewriting, JWT validation or request body handling, do not apply to a raw TCP stream. Check each plugin you plan to use against the current stream proxy documentation before you design authentication or rate limits for a database or broker port, since the answer determines where those controls must live.
How is the scope of a fixed-price stream proxy engagement agreed?
Most DeployOpen engagements are fixed-scope, and the scope, deliverables and timeline are agreed in writing before work starts. For a stream proxy project, the written scope normally lists the protocols and ports, the TLS model for each route, whether PROXY protocol is included, the environments covered, the test cases and the handover materials. Changes after signing, such as adding a new broker or moving a route to passthrough, are handled as a written change to that scope. Ask for the written scope to name every assumption about client access and certificates, so that a missing input is visible as a documented dependency rather than a hidden cost.
What does ongoing support for stream routes involve?
After go-live, stream routes need monitoring of connection counts and backend health, certificate renewal, APISIX version upgrades and periodic failover tests. These tasks recur for as long as the proxy runs, so they belong in the cost model alongside the one-time build. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope of any retainer is agreed in writing. Ask whether a support quote covers upgrade testing against each stream backend, since a change in the gateway can affect long-lived connections that only a realistic test will expose.
How DeployOpen scopes and delivers stream proxying with APISIX
DeployOpen plans, implements, hardens and documents self-hosted Apache APISIX inside your own infrastructure, whether that is your cloud accounts, data centers or an isolated network. For a layer 4 project, the written scope usually names each stream listener, the upstream services behind it (databases, brokers or legacy systems), the port and SNI matching rules, where TLS is terminated or passed through, whether the PROXY protocol is needed, and which payload-inspecting plugins, if any, are in use. Most engagements are fixed-scope, so these items, the deliverables and the timeline are agreed in writing before build work starts. Ask for the scope to list the apisix.proxy_mode setting, the stream route inventory and the verification steps as named deliverables, so that acceptance is measurable.
Delivery covers the work that stream proxying tends to leave unfinished: enabling stream mode on the right data plane, building and testing stream routes against each upstream, setting up certificates and mTLS where required, and confirming that health checks, logging and access controls behave as the security team expects. The hardening pass covers the Admin API exposure, the etcd or standalone configuration source and the network rules around each listener. Documentation covers the route definitions as code, the runbook for adding a new port, and the rollback steps. Confirm with us which parts of this are included in your fixed scope and which are optional add-ons.
Once the system is live, ongoing support, upgrades and continuous testing are available as retainers. A retainer is useful for stream proxying because new listeners, certificate renewals and APISIX version changes tend to arrive after the project closes. Ask for the retainer terms in writing, including what is covered for upgrades, who responds to incidents on stream listeners and how changes to listeners are tested before they reach production. DeployOpen does not publish a price list; a quote follows from the written scope, and we do not issue audit reports or certifications, so any compliance evidence from this work is prepared for your independent assessor.
