Sign-in helpTalk to Fibmesh
Menu

Vendors & OEMs

Stay connected to the equipment you deliver.

Give service teams a customer-approved path to installed equipment and software. Connect supported devices directly or through a gateway.

Assess an installed deviceExplore deployment options →

Connection paths

A supported device, or a gateway beside it.

Follow the connectionIllustrative connection paths

Service the machine without publishing its administration.

  1. Authorised technicianApproved support deviceWireGuard
  2. Fibmesh routing nodePermitted private accessWireGuard
  3. Installed equipmentSupported agent + management service

Networks can provide the path to a supported management interface on enrolled equipment.

Fibmesh supplies connectivity. Remote desktop, diagnostics and commands require the equipment’s own supported tools and credentials; this is not a remote-command or firmware-management service.

Explore equipment connectivity →

Put the connector beside the equipment.

  1. Approved technicianPrivate connectionWireGuard
  2. Fibmesh routing nodeCustomer-approved pathWireGuard
  3. Site gatewaySupported connectorLAN
  4. Existing applianceLocal management address

A gateway can reach an appliance that cannot run the endpoint software, without modifying its firmware.

The appliance remains a LAN resource, not an individually enrolled Fibmesh device. Validate protocols, isolation and local recovery before using the path for maintenance.

Compare deployment options →

Give a device’s outgoing requests a known source.

  1. Equipment / local serverStarts request to vendor serviceLocal route
  2. Supported agent or gatewayRoutes selected trafficWireGuard
  3. Fibmesh public sourcePublic IPs or suitable exitHTTPS
  4. Vendor APIChecks source and device credentials

A public source can help an equipment service accept calls from known installations even when their access providers differ.

Keep device or application authentication. A shared gateway source identifies that egress point; it does not distinguish every appliance behind it.

Explore outgoing identity →

Put it to work

The installation is only the beginning.

Equipment and customer-hosted software often need attention after delivery. Networks can provide private service access, while Public IPs can support external service connections or a known outgoing source. Match the connection to the maintenance task and the customer’s rules.

Service a supported installation

Use Networks to reach an approved diagnostic or administration interface from a technician’s supported device. Use the equipment’s own tools, login and permissions.

Equipment and IoT →

Reach existing appliances

Use a supported gateway when an NVR, controller, NAS or appliance cannot run the endpoint. Limit reachable targets rather than exposing the whole customer LAN.

Devices and gateways →

Connect customer-hosted software

Make a server reachable through an assigned public IP when its clients need an internet endpoint. A gateway can deliver selected traffic to a local target.

Public delivery to a local target →

A shared outgoing address does not identify individual appliances. A Publish path requires a compatible HTTP application with its own authentication. Compare the connection options →

Illustrative on-site server and laptop
Illustrative photography · not a photograph of the described customer or deployment.

From a customer deployment

An ERP service on customer premises.

An anonymous customer-site ERP example used Public IPs with full tunnel. It informs an external-access design without establishing fleet orchestration or a private support network.

  • Customer-hosted application
  • Public IPs with full tunnel
  • Application authentication remains necessary
Read the customer-site ERP example →

A practical first deployment

Plan for the whole installation lifecycle.

  1. Confirm the customer’s approval

    Specify the maintenance interface, technician access, operating window and installation owner. Keep a local service method for when internet access is unavailable.

  2. Choose agent or gateway

    Verify the device runtime, privileges and target protocol. If it cannot run the software, assess a supported gateway and an approved route to the local target.

  3. Test service and retirement

    Use the actual maintenance tool, then test access removal. A replacement device needs its own enrollment process; remove retired device credentials and stale target mappings.

Questions, answered

Before you connect.

Can Fibmesh run inside our product firmware?

A supported native runtime and integration are required. There is no released embedded SDK or universal agent promised by this page. An external gateway may be the appropriate option for existing equipment.

Does this provide remote commands, telemetry or firmware updates?

It provides the network path. Your product still needs its own authenticated diagnostics, telemetry or update service. Network access is not a complete fleet-management system.

Can this be used for industrial or safety-critical equipment?

Evaluate the specific protocol, segmentation, operating procedures and failure behavior with the equipment owner. This page does not establish industrial certification, deterministic timing or suitability for safety-critical control.

Will a gateway give every appliance its own identity?

No. The gateway is enrolled; ordinary LAN targets retain local addresses. Individual Fibmesh device identity requires individual supported enrollment, while application-level device identity remains your product’s responsibility.

Start with one installed device and one service task. Establish the supported connection before designing a wider rollout.

Plan your first deployment →