Why Apache APISIX fits plant and connected product APIs
Apache APISIX fits well as the API layer in front of connected products and plant data when you keep the OT network as a separate zone that the gateway talks to only through controlled paths. The architectural change is that device telemetry, partner APIs and service-team access stop reaching into the control network directly and instead pass through a gateway you run in your own infrastructure. APISIX is built on NGINX and etcd, supports dynamic routing with hot-loaded configuration, and proxies HTTP, HTTPS, gRPC, WebSocket, MQTT and TCP/UDP traffic. Its documentation describes more than 100 built-in plugins, and it is released under the Apache License 2.0, so the core can be inspected and run without a license fee. For edge placement, standalone mode reads configuration from a YAML or JSON file, which suits a gateway in a plant DMZ without an etcd cluster to maintain.
The features that matter most for this topic are the protocol support and the identity controls. MQTT and TCP stream routes let you place a broker or an industrial gateway behind APISIX, while mTLS-capable routes and the authentication plugins give each device or machine client an identity you can revoke. Confirm with your own engineers which industrial protocols actually cross the boundary, because APISIX proxies transport traffic but does not interpret most fieldbus payloads. Verify also that the plugins you need for client certificate checks and consumer design are available in the APISIX version you select, and check each plugin's documentation before you rely on it.
APISIX does not replace OT security design. Zone and conduit decisions, asset inventory, patch windows and the security levels that ISA/IEC 62443 assigns to each zone still belong to your OT security program, and the gateway is one control within that program. The current release is 3.19.0, released September 28, 2026, and the downloads page does not mark it as long-term support, so ask your vendor or planning team to confirm the support window and upgrade path before you standardize on it. Plan the gateway as a component you test, patch and monitor like any other boundary device.
Which manufacturing and IoT requirements shape the gateway build
This table maps the standards and regulations that apply to manufacturing and connected products onto concrete gateway decisions: placement, authentication, logging and vulnerability handling. Read each row as a question to answer before the APISIX routes are designed, because the same requirement often drives several gateway settings at once.
| Requirement | What it asks for | Impact on the APISIX gateway |
|---|---|---|
| ISA/IEC 62443 zones and conduits (ANSI/ISA-62443-3-2-2020) | Divide the plant into zones, assess risk per zone and define the conduits that cross zone boundaries. | Treat each APISIX node that bridges an OT zone and an IT or partner zone as a conduit. Place it in a defined boundary and document which routes and protocols it carries. |
| Asset owner security program (ANSI/ISA-62443-2-1-2024) | Requires the plant operator to run a security management program covering roles, monitoring and incident handling. | Assign owners for gateway configuration, Admin API access and route changes. Gateway change records should feed the plant's program evidence. |
| System security levels (ISA-62443-3-3-2013) | Sets system requirements and target security levels, covering identification, authentication, use control and data integrity. | Map each exposed route to a target level. Use client certificates or key-based authentication for machine clients and restrict access per consumer rather than by network location alone. |
| Component requirements (ISA/IEC 62443-4-2, for component suppliers) | Sets technical security requirements for IACS components. It addresses product suppliers, not the asset owner deploying them. | If you ship a device or edge product that uses APISIX, these requirements apply to your product. If you only operate APISIX, use the standard to ask suppliers what they have built and tested. |
| OT security guidance (NIST SP 800-82 Rev. 3, September 2023) | Guides OT security for SCADA, DCS, PLCs and building systems, while keeping performance, reliability and safety requirements in view. | Test failover and latency before routing control-adjacent traffic through the gateway. Do not let gateway inspection or rate limits delay time-sensitive plant messages. |
| NIS2 manufacturing scope (Annex II, Directive (EU) 2022/2555) | Lists manufacturing divisions NACE Rev. 2 26 to 30 and medical devices as a critical sector. | Determine whether your entity is in scope. If it is, the gateway's logs, access controls and encryption become part of the evidence set for cybersecurity risk management. |
| NIS2 incident reporting (Article 23(4)) | Significant incidents need an early warning within 24 hours, a notification within 72 hours and a final report within one month. | Gateway logs must reach your SIEM quickly and keep enough detail to reconstruct a timeline. Confirm the log retention and export path before you need them during an incident. |
| CRA Article 14 reporting (applies from 11 September 2026) | Manufacturers must report actively exploited vulnerabilities and severe incidents in products with digital elements. | If your connected product embeds or depends on APISIX, track its security advisories and maintain a process to assess and report exploited issues in your product. |
| CRA product obligations (from 11 December 2027, Regulation (EU) 2024/2847) | Products with digital elements must meet essential requirements across their lifecycle, including security updates. | Plan a supported APISIX version, a tested upgrade path and a method to ship gateway patches to deployed devices or plants. Confirm the release support status with the project before you commit. |
| Machinery Regulation 1.1.9 (from 14 January 2027, Regulation (EU) 2023/1230) | Machinery must be protected so that connecting another device or a remote device does not create a hazardous situation. | Gateway routes that accept remote commands to machinery need strict authentication, authorization and separation from safety functions. Do not expose control functions through a route that a partner can reach directly. |
| CMMC levels for defense suppliers (32 CFR Part 170) | Level 1 uses 15 FAR 52.204-21 requirements, Level 2 uses 110 NIST SP 800-171 Rev. 2 requirements for CUI, and Level 3 adds 24 selected NIST SP 800-172 requirements. | Level 2 work would need access control, audit logging and encryption in transit on the gateway. The Department of War suspended CMMC Phase II requirements on 13 July 2026, so confirm the current contract obligations before scoping. |
Where APISIX sits: plant edge, DMZ or cloud
In this model, APISIX runs in a demilitarized zone between the plant control network and the corporate or cloud network. Devices and plant systems do not reach the internet directly. Traffic from the OT side enters the DMZ through a defined conduit, and APISIX forwards only the routes that have been approved for cloud or partner consumers. Because the gateway sits on the boundary, it is usually the enforcement point for mTLS, authentication, rate limits and logging for everything that leaves the plant.
- Trust boundary: The gateway belongs to neither zone. Define which side administers it, and restrict the Admin API (port 9180 in traditional mode) to a management network.
- What crosses: MQTT for device telemetry, TCP stream routes for industrial protocols that the plant has approved for this conduit, and HTTPS APIs for cloud and partner consumers.
- etcd dependency: In traditional mode, etcd runs alongside the gateway, so an etcd outage or a broken replication path affects the DMZ directly. Plan etcd placement and backups inside the DMZ or in a controlled management zone.
- Change control: Route and plugin changes go through the Admin API, so every change needs an approval record, a rollback path and a log entry. Changes that alter what crosses the conduit usually need plant-side sign-off.
- Failure behavior: Confirm whether devices can keep operating if the DMZ gateway is unavailable, and whether buffering exists on the plant side.
Confirm the placement against your zone and conduit model before any route is published, because the conduit definition determines which protocols and directions are permitted.
At sites with limited or intermittent connectivity, APISIX can run in standalone mode with no etcd cluster. The routes, upstreams and plugins live in a YAML or JSON file, such as conf/apisix.yaml or conf/apisix.json, and APISIX reloads the file when it changes. This removes a stateful dependency from the site, so the gateway keeps routing local traffic when the link to a central control point is down. The cost is that configuration becomes a file managed through your delivery pipeline rather than a live API.
- Trust boundary: The edge node usually sits inside the plant or on a site network. Protect the file, its delivery path and the host, since whoever writes the file controls the routes.
- What crosses: Local MQTT or TCP stream traffic to site systems, and a limited set of HTTPS calls back to the cloud when the link is available.
- etcd dependency: None. Standalone mode does not need etcd, which reduces the number of components to patch and back up at each site.
- Change control: Changes are version-controlled files that are tested and promoted in a pipeline. Every site must receive the same file version, so fleet-wide drift checks become part of operations.
- Failure behavior: A file that fails validation can stop a deployment. Confirm how the rollout handles a bad file and how quickly a site can return to the last known good version.
Confirm with the vendor documentation which features your chosen version supports in standalone mode, and test each plugin you plan to use before relying on it at the edge.
For multi-site fleets, a decoupled deployment separates the data plane, which handles traffic at each site, from the control plane, which manages configuration centrally. The data plane nodes share one etcd cluster with the control plane. This keeps administration in one place while traffic stays close to the devices. It suits organizations that want consistent policy across plants but accept a dependency on the central cluster for configuration changes.
- Trust boundary: The control plane and etcd form a high-value management zone. Restrict access to them, and separate the networks that carry etcd traffic from plant traffic.
- What crosses: Configuration and certificate distribution flow from the control plane to the sites. Device traffic stays local, with only approved summaries or APIs sent to cloud consumers.
- etcd dependency: Sites depend on the shared etcd cluster for configuration updates. Plan its availability, the behavior of data planes during a control plane outage, and the backup schedule.
- Change control: One change can reach many plants, so use staged rollouts, a pilot site, and per-site change windows that the plant operations team approves.
- Failure behavior: Confirm whether each site retains its last loaded configuration during a control plane or etcd outage, and document the recovery steps.
Validate this model against each site's zone and conduit definition, because a shared control plane can create paths between plants that were meant to stay separate.
Which APISIX modules and settings matter on the factory floor
A plant gateway touches devices, industrial protocols, partner APIs and the security team's monitoring at once. The six areas below are the decisions that shape those paths, and each one needs an owner before the first route goes live.
MQTT proxying for telemetry and commands
APISIX lists MQTT among its supported protocols, so it can sit in front of a broker that carries device telemetry and command topics. Split the two directions early: telemetry flows from devices to the cloud, while command topics should accept only messages from named device classes and named operator services. Confirm with your broker vendor how topic authorization works, and test that a compromised device cannot publish to another device's command topic. Keep the broker's own access control as the final check, not the gateway alone.
TCP and UDP stream routes for industrial protocols
Stream routes forward raw TCP and UDP without understanding the payload, which suits industrial protocols that the gateway should pass through rather than interpret. Use stream routes to control which source networks reach which plant endpoints and to log connection metadata. Do not expect the gateway to enforce function codes or write permissions inside a fieldbus protocol. Those controls belong in industrial firewalls or the protocol's own features, and the design should say so in writing.
Device identity with client certificates
Issue each device or gateway a client certificate from a CA that your team controls, and make the gateway verify it on every connection. The CA design decides how the program scales: separate intermediates by product line or site, set certificate lifetimes that match device replacement cycles, and define how a stolen device is revoked. Confirm how revocation checks are handled in your APISIX version, because a certificate that cannot be revoked quickly is a weak identity. Store private keys in hardware where the device supports it.
Consumer and key design for partner APIs
Partners and integrators reaching the gateway need consumers with clear ownership, one per partner or application. The documented options include key-auth, jwt-auth and the openid-connect plugin, which supports client credentials and token introspection flows with identity providers such as Keycloak and Okta. Choose by who holds the credential and how it rotates. Partner keys should be scoped to the routes they need, and the rotation procedure should be tested before a partner depends on it.
Rate and request size limits per device class
Telemetry devices, controllers and partner systems produce very different traffic, so one global limit will either throttle production or leave a noisy device unchecked. Define limits per device class, covering request rate, payload size and connection count, and measure normal peaks during commissioning before fixing the numbers. A misconfigured or looping device should hit its own limit without affecting other lines. Agree the thresholds with operations, since a limit that stops a production signal is a plant incident.
Admin API access and logs to the SIEM
In traditional deployment mode, client traffic uses port 9080 and the Admin API uses port 9180. Restrict port 9180 to management networks only, and never expose it to device or partner segments. Route gateway access logs and error logs to the client's SIEM so that plant and IT security teams see the same events, and confirm retention with the SIEM owner. Test that a change to a route leaves an audit record that the security team can find.
How mTLS device identity works behind an APISIX route
The core pattern is that each device, or the edge gateway that speaks for a group of devices, holds its own client certificate issued by a certificate authority you control. APISIX terminates the TLS session, validates the client certificate chain against the CA you trust, and then decides what that identity may do. The identity check happens once at the TLS layer, and the route policy that follows is a separate decision. In practice, teams map the certificate subject or a fingerprint to an APISIX consumer, or use the client certificate fields as the basis for a route-level rule. Confirm in your chosen APISIX version which client-certificate variables are exposed to plugins and how the mtls options on the SSL object are configured, because the exact fields and the handling of intermediate chains have changed across releases and should be tested against your own certificates.
Certificate lifecycle is where device fleets usually fail. Devices that cannot be re-provisioned easily, such as field-installed controllers or units behind a partner's network, need a renewal path that works without a site visit, and a planned expiry date that is tracked centrally. Decide who issues and signs device certificates, how revocation is published and checked, and what happens to a device whose certificate is compromised. APISIX can reject revoked or unknown identities only if your revocation design reaches the gateway in time, so define how CRL or OCSP data, or a short-lived certificate model, is delivered to the data plane. Treat renewal, revocation and CA rotation as operated processes with owners and rehearsed runbooks, not as one-time setup tasks.
Authenticating a device answers who is connecting. Authorizing its actions answers what that identity may send, to which route, at what rate and with which payload. A valid certificate for a temperature sensor should not grant access to a route that accepts firmware commands. Keep these as two layers: mTLS establishes identity, and APISIX route policy, consumer restrictions and upstream selection limit the actions. Plan the mapping from device class to route before the build starts, and verify with negative tests that a valid but out-of-role device is refused. Ask your integrator to show how each certificate class maps to consumers and routes, and how that mapping is recorded in configuration as code.
Rollout from one line to the full plant network
The sequence moves APISIX from a documented risk assessment to a proven pilot on one production line, then to the remaining sites, with a client sign-off at each gate. Each stage produces evidence the plant, security and OT teams can review before the gateway touches more of the network.
Assess zones and conduits against ISA/IEC 62443
DeployOpen works with your OT engineers, IT security and plant managers to map zones and conduits across the sites in scope, including PLCs, SCADA hosts, historians, MES, cloud connectors and partner APIs. The team applies the risk assessment method from ANSI/ISA-62443-3-2-2020 and records target security levels from ANSI/ISA-62443-3-3-2013 for each zone. The step closes when the client signs off the zone model, the data flows that cross each conduit and the list of conduits APISIX will sit on.
Build a non-production lab with representative devices
A lab is built in infrastructure you control with representative device simulators or spare hardware, the MQTT broker, the TCP stream targets for the industrial protocols in use, and a copy of the planned APISIX topology. Routes, mTLS device identities, stream rules and failure cases are tested here first. The step closes when the lab test report shows each planned flow working, and each denied flow blocked, and the client accepts the results as the basis for the pilot.
Pilot on one production line with rollback
APISIX is placed on one line in parallel with the existing path, so the current connectivity keeps working while the gateway carries a defined subset of traffic. Plant engineers, DeployOpen and your operations team agree on a rollback procedure and the conditions that trigger it before cut-over. The step closes when the pilot runs through an agreed observation period, rollback has been rehearsed, and the client approves moving the pilot to permanent operation.
Harden Admin API and etcd access
Before expansion, the Admin API on port 9180 in traditional mode is restricted to named administrators and management networks, etcd is isolated from client traffic and secured with TLS and authentication, and configuration changes are limited to a controlled deployment path. Access tests confirm that unauthorized hosts cannot reach the administration interfaces or the configuration store. The step closes when the hardening checklist is signed off and the test results are filed with the change records.
Expand in stages across the sites
Remaining lines and sites are added one stage at a time, each using the pilot pattern: lab validation of the new device types, parallel running, then cut-over. Configuration is kept in version control so that each site receives the same reviewed routes and policies, with site-specific values held separately. The step closes when each site passes its own acceptance check and the client confirms the stage before the next one begins.
Hand over runbooks and certificate rotation
DeployOpen documents the operating procedures for your team: adding a device or route, responding to a failed stream or MQTT connection, rotating device and gateway certificates, and reviewing access logs. Your staff run at least one rotation and one rollback exercise with DeployOpen observing, so the procedures are tested by the people who will own them. The step closes when your engineers complete the exercises and the client accepts the runbooks as the operating reference.
Agree the upgrade plan with the client
The handover ends with a written upgrade plan covering APISIX releases, the Ingress Controller if Kubernetes is used, etcd, the operating system and the lab used for pre-production testing. The plan states who approves a change, how a release is checked against the plant's test cases and how an upgrade is rolled back on a line. Confirm current release status and support terms directly with the APISIX project before setting the cadence. The step closes when the client approves the plan and it is linked from the runbooks.
What plant and IoT teams ask before bringing in a partner
What drives the cost of an APISIX project for plants and connected products?
The cost is driven by how much surface the gateway must cover, not by the gateway software, which is open source under the Apache License 2.0. The main drivers are the number of sites, the number and type of industrial and device protocols, the device identity model (for example, whether each device gets its own client certificate and how that certificate is issued and rotated), the number of cloud and partner APIs to integrate, and whether you already have an OT security assessment. Each of these adds design, testing and change-control work. Ask for a quote that prices sites, protocols, identity model and integrations as separate line items, and that states which of them are one-time build work and which are recurring support or upgrade work. Licensing costs for APISIX itself do not apply, but any commercial add-on you choose, such as API7 Enterprise, is priced by its vendor, so confirm that separately.
How long does a pilot take, and what sets its length?
A pilot's length depends on the scope agreed in writing before work starts, so no fixed duration applies to every plant. The pilot usually covers one site, a small set of devices, one protocol path and one cloud or partner API. Its length is set by how quickly the network segments, certificate authority and change windows can be made available, how many protocols must be tested, and how many approval steps your OT and IT teams require before anything touches a production network. Ask the partner to show the milestones, the dependencies they need you to clear, and the acceptance criteria for ending the pilot. A pilot that runs in a test cell with simulated devices will finish sooner than one that must prove behavior on a live line.
What must our team supply before a partner can start?
Plan to provide the following before design begins:
- Current network diagrams for IT, OT and any demilitarized zone between them, including where APISIX would sit
- A device inventory listing protocols, firmware versions, owners and the devices that cannot be changed
- A certificate authority or a decision on which one will issue device and gateway certificates, with rules for issuance, renewal and revocation
- Change windows for plant networks and a named approver for each one
- OT engineers who can explain how each controller and gateway behaves, since they know the process constraints that IT staff often miss
Ask the partner to confirm this list in writing so gaps appear early, when they are cheap to close.
Can our internal team run an APISIX project for plants on its own?
Your team can run it alone if it already has engineers who operate APIs, Linux, containers and certificate infrastructure, and if it has OT engineers who can sign off on how traffic reaches controllers. The harder parts are usually not the gateway configuration. They are the network segmentation decisions, the device identity model and the verification that a proxy does not disturb time-sensitive or safety-related traffic. The Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027 and includes an essential requirement that machinery be protected so that connecting another device or remote device does not lead to a hazardous situation, so a design review should involve people who understand that requirement. A partner can work alongside your team or deliver the build as a fixed-scope engagement, and the written scope should state which party owns each decision and each runbook.
Can APISIX parse PLC or OPC protocols directly?
APISIX forwards traffic. Its stream and TCP/UDP proxying can carry industrial protocol traffic between a client and a backend, but forwarding is not the same as understanding the protocol. Whether a given PLC or OPC protocol is suitable for proxying through APISIX must be confirmed for each protocol, each vendor implementation and each firmware version. Confirm with the controller vendor whether the protocol tolerates an intermediary, what session and timeout behavior it expects, and whether any health checks or retries could alter control traffic. Do not assume that a protocol which works through a generic TCP proxy in a lab will behave the same on a production line. Treat protocol suitability as a test item in the pilot, with results recorded for each device family.
Does deploying APISIX satisfy NIS2 or the Cyber Resilience Act by itself?
No. A gateway contributes evidence and controls to a wider compliance program, but it does not make an organization compliant on its own. NIS2 Annex II lists manufacturing as a critical sector, and in-scope entities must report significant incidents within defined deadlines under Article 23(4) of Directive (EU) 2022/2555. The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to products with digital elements from 11 December 2027, while manufacturers' Article 14 reporting obligations have applied since 11 September 2026. A gateway can help with encryption in transit, access control, logging and boundary protection, which supply evidence for those obligations. Your risk assessment, incident response process, product security lifecycle and vulnerability handling still have to exist and be documented. Ask any partner which evidence the gateway produces and which evidence remains your responsibility.
What should a quote for this work include?
A useful quote is a written scope with named deliverables, not a single price. Ask for the following sections:
- Sites, networks and zones in scope, with the placement of APISIX in each
- Protocols and device families covered, and the test results expected for each
- The device identity model, certificate issuance and rotation process, and the authority that issues certificates
- Integrations with cloud and partner APIs, and the authentication method for each
- Acceptance criteria, change-control steps and rollback plan
- Documentation, runbooks and knowledge transfer
- Which items are one-time build work and which are recurring support, upgrades or testing
DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask for each assumption to be stated so you can compare quotes on the same basis.
Compliance evidence a gateway can supply for OT and product security
A gateway sits on several regulatory boundaries at once: between OT zones, between devices and the cloud, and between your products and the people who maintain them. The cards below show which evidence APISIX can produce for each obligation and what your compliance team must still confirm. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do.
Zone and conduit evidence
IEC 62443 organizes plants into zones and the conduits between them, and asset owners must show how traffic crosses each boundary. APISIX route definitions, upstream lists and stream routes can document which device groups reach which backends, and the configuration can be kept in version control as a reviewable record. Check that the gateway sits in the conduit you intend, that management interfaces are not reachable from the OT side, and that the zone model in your risk assessment matches the routes actually deployed.
Device and partner access logs
NIST SP 800-82 Rev. 3 expects OT operators to monitor access and detect anomalies without disrupting process performance. APISIX access logs can record the consumer identity, client certificate subject, route, upstream and response for every device and partner request, which gives your monitoring tools a consistent source. Confirm the log fields you need, where logs are shipped, how long they are retained, and that payloads containing device telemetry or credentials are excluded before storage.
NIS2 reporting timelines
Manufacturers in NIS2 scope must report significant incidents with an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. The gateway cannot make those decisions for you, but its logs and alert outputs can establish when an event began and what it touched. Agree in advance which gateway events feed your incident process, who receives them, and how log timestamps are synchronized so the timeline holds up when reported to your national authority.
CRA vulnerability handling
If your connected product includes APISIX, the gateway is a third-party component you must track under the Cyber Resilience Act. Manufacturers must report actively exploited vulnerabilities and severe incidents under Article 14, and that duty applies from 11 September 2026, ahead of the general application date. Maintain a bill of materials that records the APISIX version, plugin set and Lua or runner dependencies, subscribe to project security notices, and plan patch releases before shipping. Confirm with counsel which obligations apply to your product category and role.
Machinery protection for connected equipment
The Machinery Regulation requires that connecting another device or a remote device does not lead to a hazardous situation. For machines managed through a gateway, this means the gateway must not become a path for unsafe commands, and remote access must be limited to authorized, authenticated sessions. Document which routes can change machine state, require mTLS and per-device authorization on those routes, and separate read-only telemetry from control paths. Confirm the applicable essential requirements with your notified body or conformity assessment process.
What to ask a partner before signing an APISIX scope
Before you sign, ask the partner to show how they map zones and conduits for your plant. The useful answer names the segments, the APISIX nodes that sit on each conduit, and which routes cross from the OT side to the cloud or partner side. Ask who owns each boundary, which firewall rules enforce it, and whether the gateway can reach controller networks at all. A partner who draws one flat network diagram for the gateway has not yet worked through the boundary that matters most. Ask for the zone model as a written artifact before design starts, aligned with the zone and conduit thinking in the ISA/IEC 62443 series.
Next, ask how stream routes will be tested against real device traffic rather than synthetic requests. Ask for a capture of representative MQTT sessions, the broker and topic layout, and the behavior the partner will verify under reconnect storms, duplicate client IDs and half-open TCP connections. For TCP stream routes carrying industrial protocols, ask which operations are allowed through the gateway and which are blocked, and how that policy is tested. Ask how certificate issuance and revocation for device identities will work: who signs device certificates, how a stolen device is revoked, how quickly revocation reaches every gateway node, and what happens to devices when the certificate authority is unreachable. Confirm the answers against your own device fleet, since no supplied fact describes your devices.
Finally, ask how the gateway stays out of control loops. The partner should state that no closed-loop control path passes through APISIX, that timeouts and retries on device-facing routes are set so that a gateway fault cannot stall a controller, and that any safety-relevant behavior stays in the control system. Ask how upgrades are tested against the APISIX 3.19.0 release line and later, since the downloads page does not mark any release as long-term support, so your plan must cover the upgrade cadence you will actually run. Ask for the written deliverables of a fixed-scope engagement: zone and conduit diagram, route and plugin inventory, device identity runbook, test results from device traffic, and a rollback procedure. Each should have an owner and an acceptance step before work begins.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the OT-adjacent gateway layer described on this page. Engagements start from a written scope, so the plant, device and partner boundaries are agreed before any configuration begins.
How we scope
- We map which device, plant and partner APIs will pass through the gateway, and which networks they cross.
- We agree in writing which MQTT, TCP stream and HTTP routes, and which device identity method, are in the build.
- Most engagements are fixed-scope, with deliverables and timelines confirmed before work starts.
How we build
- We deploy APISIX in your cloud accounts, data centers or restricted networks, using the deployment mode your architecture needs.
- We configure stream routes, mTLS device identity and zone separation, then test each route against the protocol behavior it must carry.
- We validate the design against your OT security and risk assessment, and record the results as they are produced.
How we hand over
- You receive configuration as code, runbooks, network diagrams and a record of tests performed.
- Your operations team is trained on certificate rotation, route changes, plugin updates and log review.
- Documentation covers what DeployOpen built, what your team owns, and the open items that remain after handover.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Support can cover APISIX release reviews, plugin and certificate lifecycle work, and changes to device fleets.
- Compliance work is prepared as evidence for your own auditors, since DeployOpen does not issue audit reports or certifications.
