How to Deploy Computer Vision Behind a Data Diode

A data diode lets a computer vision system send inspection results out of a protected network while preventing traffic from returning through the same connection. A factory can share defect counts, production metrics, and equipment status with external systems while keeping camera feeds, model execution, and production controls inside its own environment.

Deploying computer vision behind a data diode requires every part of the application to work with that one-way boundary. Models need to load from local files. Licensing needs a plan for disconnected operation. Monitoring must report health outward, and messaging cannot depend on acknowledgements from the other side. A fully air-gapped deployment has no external network connection; a data diode provides a controlled one-way link.

Roboflow Inference gives teams a way to run vision models and Workflows on hardware inside the protected network. With Enterprise Offline Mode, the required model files and Workflow definitions can be prepared locally for offline execution.

In this guide, you’ll learn how to deploy computer vision behind a data diode with Roboflow: run inference locally, export predictions through a one-way transport, connect MQTT systems on either side, and plan licensing and monitoring around the network boundary.

What Is a Data Diode, and How Does It Impact Computer Vision?

A one-way boundary becomes disruptive when software expects the other side to answer. Data can still leave the protected zone, but any protocol that depends on a reply has to be handled differently.

TCP makes the limitation especially clear. Before application data can be exchanged, a TCP session must first complete a three-step connection setup. The initiating host sends a request, the receiving host responds, and the initiator confirms the exchange. Across a strictly one-way boundary, that sequence cannot be completed, so the TCP session is never established.

The same dependency appears higher in the stack:

• License checks may wait for a server response before confirming an entitlement.
• Software updates request data that has to come back over the connection.
• Health checks often rely on a reply to confirm that another service is reachable.
• Telemetry and monitoring may depend on delivery confirmation or other return traffic.

In a normal deployment, these dependencies are easy to miss because they run quietly in the background. A production vision stack depends on the same kinds of exchanges: license validation handles authorization for the self-hosted deployment, model loading uses the weights and files required at runtime, health and metrics endpoints report whether the service is running, and model monitoring tracks what the system is producing. Behind a diode, each of those functions has to stay inside the protected zone or be designed so it does not depend on a reply from outside. 

UDP is easier to adapt because it can send datagrams without first establishing a session with the receiver. It also does not provide TCP-style delivery acknowledgements, so the sender does not wait for confirmation that each packet arrived. Roboflow Inference already supports this style of output through its UDP prediction sink, which broadcasts results to a port with no connection to maintain. If stronger delivery guarantees are needed, they have to be handled separately through techniques such as sequence numbers, buffering, redundancy, or forward error correction.

Before looking at how results leave the protected zone, it helps to be clear about what runs inside it and what Roboflow Inference needs in order to operate there.

Run Roboflow Inference Inside the Protected Network

Inside the protected zone, Roboflow Inference runs on hardware you control. Models and Workflow logic execute locally, and production images are processed on the machine rather than sent to the cloud. In a one-way deployment, what matters is whether the system still needs anything from outside the zone once it is running, because the diode removes that access entirely.

This is what Enterprise Offline Mode is built for. While the server still has a connection, you run the model and Workflow once so their weights and definitions download into a local model cache, a Docker volume the Inference Server reads from on every later request. After that, the server resolves everything it needs from that cache instead of reaching out, and with OFFLINE_MODE=True set, it loads models from the cache without contacting the Roboflow API during normal operation. The weights, the Workflow logic, and the runtime all resolve inside the zone, which is what lets the server sit behind a one-way boundary at all.

Once that is in place, the model can keep running inside the zone. The next problem is getting its results across the one-way boundary, which is where the transport architecture comes in.

Send Computer Vision Results Across a Data Diode with MQTT

Once the model starts producing predictions, the next challenge is getting those results out of the zone, and the main decision is which transport suits a one-way network. MQTT works well here: instead of calling every system that needs a result, a publisher sends messages to named topics, and each system subscribes to the topics it needs. A Roboflow Workflow can send its output to a local broker using the MQTT Writer sink, giving Inference a standard way to hand results to the transport layer inside the protected zone. For a complete example, Roboflow's MQTT integration walkthrough shows how to wire it up end to end.

The important detail is that MQTT itself does not cross a true data diode. MQTT requires a bidirectional transport, typically TCP, so a publisher inside the protected zone cannot open a normal MQTT connection to a broker on the far side of the boundary.

Instead, terminate MQTT on both sides. Inference publishes to a broker inside the protected zone. A forwarding process subscribes to the approved topics, serializes the messages, and sends them across the diode using a one-way transport. On the receiving side, another process republishes those messages to a second MQTT broker, where dashboards, historians, or control logic can subscribe normally.

Key point: MQTT sessions stay on each side of the diode. The diode carries only the serialized one-way message stream between the two brokers, never an MQTT connection itself.

Inside the zone, that first hop is an ordinary MQTT publish. Inference hands each detection to the local broker exactly as it would in any connected deployment:

# Inside the protected zone: publish to the local MQTT broker
client.publish(
    topic="line1/defects",
    payload=prediction_json,
    qos=0,
    retain=False,
)

Quality of service still applies to the MQTT connections themselves. QoS 1 confirms each message with a single PUBACK, and QoS 2 uses a four-step handshake of PUBLISH, PUBREC, PUBREL, and PUBCOMP, as defined in the MQTT specification. Those mechanisms can work normally between Inference and the local broker, and again between the receiving broker and its subscribers. Across the diode, there is no MQTT QoS at all, because that hop is a separate one-way transport rather than part of an MQTT session. 

That makes the payload especially important. The receiving side cannot ask the protected zone for missing context, so each message should carry everything needed to interpret the result on its own:

{
  "ts": "2026-10-01T14:32:07Z",
  "source": "line1-cam3",
  "detections": [
    {
      "class": "surface_defect",
      "confidence": 0.94,
      "bbox": [412, 288, 503, 361]
    }
  ]
}

A timestamp lets the receiver order and age results, while a source identifier ties each detection to its origin. MQTT handles messaging on either side of the boundary; the diode carries only the serialized one-way stream between them.

Plan Offline Licensing and Model Updates

Once inference and model loading are running locally, licensing becomes the next dependency to check. A system can operate behind a diode with all images kept on site and still run into trouble if the license has to contact the vendor on a schedule. That question often surfaces late, when someone asks what happens when the current lease expires.

With Roboflow, this comes down to one mechanism: a lease on the cached weights. Offline Mode caches model weights locally for up to 30 days, and each prediction returns an expiration value. When fewer than seven days remain, the Inference Server starts trying to renew the lease once per hour until it reaches the Roboflow API or a Secure Gateway, and a successful renewal resets the counter to 30 days.

Setting OFFLINE_MODE=True does not remove that lease. It controls how models load from the local cache and turns off per-model API authentication while disconnected, but it does not create the air gap and does not extend the 30-day window. A fully air-gapped site still has to renew the lease before it expires.

That is the part a one-way design has to plan for. Renewal needs two-way traffic with the Roboflow API, and a Secure Gateway, which proxies that traffic, sits outside the diode rather than on it, because it needs two-way access to the Roboflow API, which the diode does not allow.

So renewal cannot run as background production traffic through the one-way boundary. It has to be a planned, out-of-band event: a scheduled maintenance window on a separate managed link, where the server is reconnected just long enough to renew, then returned to its sealed state. Deciding how and when that happens, before the review, is what keeps licensing from quietly becoming the thing that forces the boundary open. 

Monitor Computer Vision Behind a Data Diode

A one-way boundary changes how the system is monitored. With a diode in place, outside systems can no longer check the server directly. A health endpoint, dashboard, or alerting service cannot reach back into the protected zone. Instead, the server has to send its health information outward, just like it sends its inference results.

Roboflow Inference already exposes the signals you need. Its local telemetry includes a /metrics endpoint, and the server API provides a /healthz liveness check. A process running inside the zone can read those values and publish a small status message over the same one-way path used for detections.

That changes the monitoring model. Instead of reaching in to check whether the system is healthy, the receiving side watches for a regular heartbeat and raises an alert when it stops arriving:

The heartbeat itself can be small. A timestamp, an inference count, the time of the last successful prediction, and a basic health flag are enough to tell the far side what it needs to know:

{
  "ts": "2026-10-01T14:35:00Z",
  "status": "ok",
  "inferences": 1032,
  "last_success": "2026-10-01T14:34:58Z"
}

Because nothing can confirm receipt, the logic lives on the receiving side. It knows the expected interval, so a heartbeat that does not arrive within that window, or a last_success timestamp that keeps falling behind, is treated as a fault. In a sealed deployment, silence becomes the signal that monitoring needs to act on. 

What to Validate Before Approval

Before the deployment goes into the protected zone, each part of the design should be checked against the one-way constraint. Five questions cover the main architecture decisions.

• Can inference start and keep running with no outbound dependency? The model, its weights, and Workflow logic should all resolve from inside the zone, with nothing fetched across the boundary at runtime. The simplest proof is the container serving predictions with external network access disabled.
• Can results leave without any return traffic? Output has to cross on a one-way transport, with no acknowledgement or confirmation expected back. Traffic capture or interface monitoring around the diode should show outbound data only.
• Are MQTT sessions terminated on each side of the diode? No broker connection should span the boundary. Only the serialized message stream crosses between two brokers that remain on their own side, bridged by a forwarder.
• Can the deployment stay licensed within the lease window? Cached weights run for up to 30 days, so renewal has to be scheduled as a planned, out-of-band maintenance event on a separate managed link, not as traffic through the diode. The plan has to exist before the lease expires.
• Can operators confirm health from outbound signals alone? Liveness has to be visible from the receiving side through a heartbeat the system publishes, with an alert on its absence, not a probe that reaches back into the zone.

If those five conditions are covered, the deployment is aligned with the one-way boundary. Any gap becomes a concrete design issue to resolve before approval rather than something discovered during the review.

Conclusion

Deploying computer vision behind a data diode lets you turn camera feeds into useful production data while preserving a one-way network boundary. Images, models, and inspection logic never leave the site, and the only thing that crosses is the data you approve.

With Roboflow Inference, you can run vision models and Workflows on hardware you control. Enterprise Offline Mode supports local execution using cached models and Workflow definitions, with license renewal and model updates planned around your network requirements. That gives your team a foundation for connecting vision AI to production while keeping sensitive images on site.

Talk to Roboflow about configuring Enterprise Offline Mode and bringing computer vision into your protected environment.

Further reading:

• The Purdue Model: Levels, Who Uses It, and AI Deployment
• Air-Gapped Computer Vision Deployment: How to Run Offline
• Securing a Self-Hosted Server