Vendors & OEMs / From installation to retirement
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.
Available with assisted setup. Confirm the supported devices, locations and connection scope before deployment.
01 / A path the customer approves
Deliver the product.
Keep service within reach.
Start with the interface your service team needs and the customer who authorises it. Networks can provide a private connection to a supported installation; the equipment’s own tools and accounts remain responsible for the maintenance task.
Service the machine without publishing its administration.
- Authorised technicianApproved support device→WireGuard
- Fibmesh routing nodePermitted private access→WireGuard
- 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.
- Approved technicianPrivate connection→WireGuard
- Fibmesh routing nodeCustomer-approved path→WireGuard
- Site gatewaySupported connector→LAN
- 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.
- Equipment / local serverStarts request to vendor service→Local route
- Supported agent or gatewayRoutes selected traffic→WireGuard
- Fibmesh public sourcePublic IPs or suitable exit→HTTPS
- 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 →These are illustrative paths. Confirm the specific model, supported software and protocol before deployment; a network connection does not supply remote commands, diagnostics or firmware management.
02 / The installation is only the beginning
Install. Service.
Replace. Retire.
Keep the customer’s authority attached to the installation throughout its life. Each service visit or equipment change needs a deliberate access decision and a record the next technician can use.
- 01
Install
Establish the supported connection.
Confirm the customer’s approval, the equipment model, runtime and required privileges. Enrol a supported endpoint or commission a supported gateway beside the equipment. Record the approved maintenance interface and its owner.
Keep in the service recordModel and runtime · placement · permitted interface
- 02
Service
Use the tools your product already needs.
An authorised technician reaches the agreed diagnostic or administration service. Your own tools, application accounts and product permissions still perform and authorise the work. Keep the operating window and local recovery contact explicit.
Keep in the service recordTechnician authority · service tool · local recovery
- 03
Replace
Treat the replacement as a new installation.
Check the new model and software support, then give a directly connected replacement its own enrollment. For a gateway target, confirm the replacement’s stable local address and approved services before changing mappings.
Keep in the service recordNew enrollment or target · service checks · old access removal
- 04
Retire
Close the path when the job ends.
Remove retired enrollments, target mappings and obsolete application credentials. Withdraw temporary technician access and verify the former path no longer works. Keep the customer’s local service and recovery procedure usable.
Keep in the service recordWithdrawn access · removed mappings · retained owner
03 / Put the connection in the right place
Inside a supported host.
Or beside the appliance.
A supported native endpoint and a supported gateway are different installation choices. Neither turns an unsupported firmware image into a supported runtime.
Supported endpoint
The installation can run the software.
Enrol the supported host and allow the intended technician to reach its management service through Networks. Verify operating-system support, privileges and the equipment’s own application permissions.
The enrolled endpoint has its own Fibmesh identity. A replacement host needs its own supported enrollment and acceptance checks.
Explore Networks →Explore equipment connectivity →Supported nearby gateway
The appliance keeps its local interface.
Place a supported gateway beside an NVR, controller, NAS or appliance that cannot run the endpoint. Permit only the required LAN targets and verify a return route or supported source NAT.
The gateway is enrolled; the appliance retains its local address and application identity. A generic WireGuard-capable device is not automatically a supported Fibmesh gateway. Edge hardware remains development/pilot.
Check devices and gateways →When clients need an internet endpoint.
Public IPs can provide an assigned public address on a supported host or deliver selected traffic through a gateway. Agree inbound rules, application authentication and the reply path. Publish requires a compatible HTTP application with its own authentication.
Public delivery to a local target →When the vendor checks an outgoing source.
The intended traffic must actually use the supported endpoint or gateway route. A one-port connector does not redirect unrelated LAN traffic. A shared public source identifies the outgoing connection point, not every appliance; retain device or application credentials.
Explore outgoing identity →04 / 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.
Read the customer-site ERP example →The demonstrated deployment
Software on customer premises.
An address independent of the access ISP.
The software supplier’s Windows ERP servers stayed at customer sites, with Fibmesh installed directly on those hosts. The deployments used Public IPs with full-tunnel routing.
- Customer-hosted application
- Public IPs with full tunnel
- Application authentication remains necessary
This historic example does not establish a private support fleet, fleet orchestration or release parity across current native clients. Its public/full-tunnel path is separate from the private maintenance example above.
For your model,
test the service work.
Use one actual installation and the customer’s maintenance procedure. A tunnel connection alone does not prove that the technician can complete the task or that withdrawn access has stopped.
- 01 / Model acceptance
Use the real model.
Record model, firmware or operating system, native runtime, privileges, target address, transport and service port. Test the actual diagnostic or administration application from another internet connection.
- 02 / Model acceptance
Check both sides of permission.
Complete the customer-approved task with an authorised technician. Check that an unrelated user or resource is denied, and that application login remains required. Verify the intended return route.
- 03 / Model acceptance
Rehearse a service change.
Restart the endpoint or gateway and test internet loss and restoration. Withdraw access and confirm it stops. For a replacement, verify the new path and removal of the old credentials or mapping; retain local recovery.
05 / A practical first deployment
One installed model.
One service task.
Establish the supported connection and the operating agreement before planning a wider rollout. Keep the installation, acceptance and retirement records together.
- 01
Agree the customer’s service task.
Name the installation owner, maintenance interface, authorised technician and operating window. Bring the actual management tool and a local method for service when internet access is unavailable.
- 02
Choose endpoint or gateway.
Confirm supported native software, privileges and protocol. If the appliance cannot run the endpoint, assess a supported nearby gateway, selected LAN target and working return path with the customer’s administrator.
- 03
Accept the whole lifecycle.
Complete the real task, test denied access and recovery, then rehearse withdrawal and replacement. Keep the installation record and removal responsibilities with the customer before extending the approach to another model.
06 / Questions, answered
Before you build
it into the service.
Can Fibmesh run inside our product firmware?
A supported native runtime and integration are required. There is no released embedded SDK or universal firmware agent promised by this page. An external supported gateway may be the appropriate option for existing equipment; confirm the model and platform before choosing the installation.
Does this provide remote commands, telemetry or firmware updates?
Fibmesh provides the network path. Your product still needs its own authenticated diagnostics, telemetry, update service or remote-access tools. Customer-approved connectivity does not establish remote-command execution, firmware management or automatic fleet lifecycle orchestration.
Can this be used for industrial or safety-critical equipment?
Evaluate the specific protocol, segmentation, operating procedures and failure behavior with the equipment owner. Retain local service and recovery. 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. A shared outgoing address does not distinguish each appliance, and application-level device identity remains your product’s responsibility.