Picture this: a field technician arrives at a remote manufacturing plant to commission a new data collector. Everything looks fine from the outside; the device is online, the containers are running. However, one of the PLCs is incorrectly configured and is reading an incorrect register range, and someone needs to connect to it from the control software on their laptop. The device is behind the plant’s industrial firewall. The technician is not a network engineer. IT is in a different city. And the VPN credentials they were given three weeks ago have since expired.
Secure remote access to edge devices is one of those problems that sounds straightforward until you’re standing in a plant at 2pm trying to explain to someone on the phone how to open a specific port through a Rockwell firewall.
Daployi’s Tunnel feature was built for exactly this scenario, and quite a few others.
Why Secure Remote Access to Edge Devices in Industrial Environments Is So Hard
The challenge isn’t technical in the narrow sense. The technology to forward a TCP port exists, and anyone with network training could set it up. The problem is structural: industrial sites run on OT (operational technology) networks that are intentionally isolated from external access. Those isolation rules exist for good reason. A compromised PLC or sensor gateway can cause physical consequences, not just data loss. So the same security posture that keeps bad actors out also keeps your own technicians out.
Traditional approaches to solving this create their own set of headaches. A site-to-site VPN requires network infrastructure at both ends and a team to maintain it. A reverse SSH tunnel (the quick hack that works until it doesn’t), is fragile, hard to audit, and requires the person on-site to have the right keys. A bastion host means another server to manage, another credential to rotate, another system that can go offline at the wrong moment. All of these options share a common failure mode: they require the person who needs access to have network engineering skills they don’t necessarily have, or to call someone who does.
The skills gap between IT and OT is real and persistent. Most field engineers, electricians, and plant operators are highly skilled at what they do, but configuring port forwarding rules or SSH tunnels is not part of their training, nor should it be. Any access solution that requires that knowledge will, in practice, require a phone call or a ticket, which adds hours to tasks that should take minutes.
What the Daployi Tunnel Does Differently
The Daployi Tunnel gives team members secure remote access to edge devices, and to any host on those devices’ local subnets, without exposing the device publicly, without VPN infrastructure, and without requiring the end user to know what a port is.
Here’s how it works at a practical level: an administrator pre-configures port rules in Daployi’s web UI, either at the template level (so the rules apply across the entire fleet) or per device. When a user needs to open a tunnel to a device, they click the Tunnel option in the device view. The Daployi Tunnel App (available for Windows, macOS, and Linux), launches automatically with the configured ports already mapped. The user gets a localhost URL or address to click; their control software, browser, or database client connects through it as if the device were sitting right next to them.
No firewall changes. No network knowledge. No VPN.
Because the Daployi agent uses outbound connections back to the Daployi server, there’s no inbound access required on the device’s network at all. The tunnel rides that existing outbound channel. And because MFA is required to open a tunnel session, accidental or unauthorised access is significantly harder than it would be with a shared VPN credential.
Every tunnel session is logged in Daployi’s Events module; who opened it, to which device, at what time. For teams in regulated environments, that audit trail is not optional; it’s the difference between a compliant access pattern and an uncontrolled one.
Six Real-World Use Cases the Tunnel Unlocks
1. PLC Programming and Commissioning
Programmable Logic Controllers are the workhorses of industrial automation, and most of them have a programming interface that runs over a specific TCP port. Normally, accessing that interface requires being physically on the same network segment as the PLC. With Daployi’s Tunnel configured for the relevant port, a controls engineer can connect their programming software, ie. Rockwell Studio 5000, Siemens TIA Portal, Codesys, or whatever the environment uses, directly to the PLC through the tunnel from anywhere, as if they were on-site. Commissioning and remote support that used to require a flight can be done from a desk.
2. Web-Based Admin Interfaces on Edge Hardware
Many industrial devices such as routers, switches, edge gateways, or sensor aggregators, expose a local web admin interface on port 80 or 443 that is only accessible from the device’s LAN. These interfaces are invaluable for diagnostics but completely unreachable without local network access. Tunneling to port 80 or 8080 on the device means your administrator can pull up that interface in a browser tab, review configuration, and make changes. The same applies to containerised services running on the device, like a locally-running Grafana instance, a Node-RED flow editor, or a custom diagnostic dashboard, which now becomes remotely accessible through a pre-configured port rule.
3. Database Access for Troubleshooting and Validation
Edge devices in industrial IoT often run a local time-series database such as InfluxDB, TimescaleDB, or SQLite, for buffering sensor data before it’s forwarded upstream. When something goes wrong with a data pipeline, being able to query that database directly is invaluable for diagnosing whether the problem is in data collection, transformation, or transmission. With the Tunnel configured for the database’s port, an engineer can connect their database client (DBeaver, DataGrip, or InfluxDB’s CLI as examples), directly to the edge instance, run ad-hoc queries, and pinpoint the issue without touching the device’s container configuration. Before Daployi, this kind of access would require either SSHing into the device and running queries from the command line (doable but cumbersome) or forwarding the port manually through an SSH tunnel that needs to be recreated every session.
4. Accessing Hosts Across the Device’s Subnet
This is one of the Tunnel’s more powerful and less obvious capabilities: it can route traffic not just to the edge device itself, but to any host on that device’s local subnet. In a factory floor environment, this means the edge device acts as a gateway into the OT network. If a sensor, a secondary PLC, or a local HMI panel is on the same subnet as the Daployi-managed device, a tunnel configured with that device’s IP as the exit point can reach all of them. One enrolled Daployi device can effectively give you audited, authenticated access to an entire equipment cluster without enrolling each individual piece of hardware.
5. Enabling Non-Technical Field Staff
Industrial teams increasingly include electricians, equipment operators, quality control technicians, who, while they aren’t developers or network engineers, still need to carry out specific tasks on remote devices. Daployi handles this through the combination of its template system and the Tunnel. An administrator pre-configures exactly which ports are available and to whom, using Daployi’s RBAC system to scope access at the role or project level. The field technician opens the Tunnel App, clicks connect, and their access is limited to exactly what’s been pre-approved. They can’t inadvertently expose additional services or browse to ports they shouldn’t touch. It’s the difference between handing someone a full VPN connection and handing them a key that fits only one lock.
4. Accessing Hosts Across the Device’s Subnet
This is one of the Tunnel’s more powerful and less obvious capabilities: it can route traffic not just to the edge device itself, but to any host on that device’s local subnet. In a factory floor environment, this means the edge device acts as a gateway into the OT network. If a sensor, a secondary PLC, or a local HMI panel is on the same subnet as the Daployi-managed device, a tunnel configured with that device’s IP as the exit point can reach all of them. One enrolled Daployi device can effectively give you audited, authenticated access to an entire equipment cluster without enrolling each individual piece of hardware.
How This Compares to Alternatives
Site-to-site VPN is the most common enterprise approach, and it works well when you have the infrastructure team to support it. The problem in industrial IoT at scale is that maintaining VPN connectivity across hundreds or thousands of remote sites is expensive, and operationally demanding.
Manual SSH port forwarding (ssh -L localport:remotehost:remoteport user@device) is the go-to for engineers who are comfortable with command-line tools. It works, and it’s free. But it requires the right SSH credentials on the device, knowledge of what you’re forwarding and why, a new command for every session, and it produces no audit trail unless you’ve separately instrumented your SSH daemon. It also doesn’t help field staff who can’t type a command at all.
MeshCentral and similar tools provide browser-based terminal and remote desktop access, which is genuinely useful, but they don’t have the concept of pre-configured port forward rules, template-level port provisioning, or the Tunnel App experience that Daployi provides. Getting to a specific service running on a device still requires knowing what port it’s on and how to configure a forwarding rule.
Opening firewall ports (the quick-and-dirty approach) solves the access problem by destroying the security boundary. Publicly exposing a PLC interface or a local admin UI is not an acceptable trade-off in an OT environment. Daployi’s Tunnel achieves the access without the exposure, because the connection flows outbound from the device rather than inbound from the internet.
Comparison of Daployi Tunnel, site-to-site VPN, SSH port forwarding, and MeshCentral across setup complexity, audit trail, field staff usability, per-device control, and network exposure risk.
The Administrator’s View: Control Without Friction
From an administrator’s perspective, the Tunnel’s value isn’t just in what it enables, it’s in how precisely it can be controlled.
Port rules are defined in the Tunnel tab of a template, which means they can be rolled out to an entire device fleet in one deploy operation. A single template update can add a new port rule (ie. access to a newly deployed diagnostic service) to every device in a project simultaneously, with no manual configuration on any individual device.
Per-device granularity is available for situations where fleet-wide rules aren’t appropriate. An administrator can enable specific ports on one device and leave them off on others. More significantly, they can delete a port rule from a specific device entirely, not just disable it, which prevents that rule from being re-enabled without a deliberate administrator action. For environments where the principle of least privilege is enforced, this matters.
The Tunnel App itself is straightforward enough that it can be installed once on a technician’s laptop and then used across every device they ever need to access. The experience from the field staff’s side is: open Daployi, navigate to the device, click Tunnel, confirm MFA, and the App opens with the right ports already mapped. No configuration step, no knowledge of what’s being forwarded or why.
What Changes When Secure Remote Access to Edge Devices Is This Deliberate
The pattern that the Daployi Tunnel represents; pre-configured, role-scoped, audited, MFA-gated access, is a fundamentally different mental model from the “we’ll sort it out when we need it” approach that most industrial teams currently operate under.
When access is deliberate and pre-provisioned, field staff stop being blocked waiting for IT to open a firewall rule. Remote support engineers stop needing to coordinate with network teams before they can do their job. Compliance teams get a usable audit trail without having to retrofit logging onto ad-hoc SSH sessions. Administrators get a control plane that reflects the actual access posture of the fleet at any moment, not one that’s slowly drifted into a state nobody is quite sure about.
Secure remote access to edge devices, at this level of control and auditability, used to require significant custom infrastructure. Daployi makes it a configuration choice that’s baked into the same template system your team is already using for deployments.
If you’re managing edge devices in an industrial environment and remote access is still a pain point, Daployi’s Tunnel feature is worth an hour of evaluation time. The documentation at docs.daployi.io covers tunnel setup, port rule configuration, and the Tunnel App installation in detail.