IT partners / One customer, one working result
Deliver the connection your customer needs.
Design a useful customer connection with clear ownership, installation and handover. Work with the equipment and internet access already in place.
Available with assisted setup. Confirm the supported devices, locations and connection scope before deployment.
01 / Start inside the customer’s scope
Your expertise.
Their environment.
Managed service providers and integrators bring together the customer’s equipment, application and operating arrangements. Fibmesh supplies a supported connection path for the service you are delivering.
Reach the customer resource approved for the job.
- Support engineerAuthorised identity→Private access
- Customer private networkCustomer-approved membership→WireGuard
- Customer gatewayApproved route→LAN
- Managed resourceServer or equipment interface
A supported Networks deployment can provide remote access to the customer’s server or management interface.
The customer’s environment remains separate from other customers. This illustrates the service workflow, not a released delegated MSP portal or multitenant console.
Explore Networks →Connect a local service to its external users.
- External user / systemPublic endpoint→Service request
- Fibmesh public deliveryAllocation and inbound rules→WireGuard
- Customer gatewayWireGuard and target mapping→LAN
- Customer applicationOwn login and data permissions
Public IPs supports an address-based deployment; Publish suits selected HTTP applications with public hostnames.
Keep customer allocations, target mappings and recovery instructions in the handover. Hardware pilots and service availability need their own deployment agreement.
Explore public delivery →Repeat the method, not the shared trust.
- Customer AOwn resources and credentials·No implied route
- Separate administrationExplicit authority for each customer·No implied route
- Customer BOwn resources and credentials
Supporting two customers does not require connecting their networks to each other.
This is an ownership diagram, not a packet path. Separate customer identities and permissions; delegated management, reseller billing and cross-customer orchestration are not promised here.
Explore partnership discussions →Customer support and public service delivery are different paths. The customer-separation view describes authority and ownership; its dots do not represent traffic between customer networks.
02 / Keep the responsibilities visible
Agree it.
Install it.
Leave it in good hands.
A customer connection needs more than a working tunnel. Keep the permission, installation record, acceptance test and handover together throughout the job.
Agree
A useful result, with permission.
Name the resource, its users and the task you will demonstrate. Record who may approve private access, public exposure or an outgoing route change.
Keep in the deployment recordResource owner · authorised users · acceptance task
The customer authorises the installation and keeps ownership of its data, application accounts and access decisions.
Install
Work within this customer’s scope.
Use supported endpoint software or a supported gateway beside the equipment. Check target addresses, ports, permitted routes, return paths and application credentials.
Keep in the deployment recordGateway placement · allocation · targets · route changes
The customer’s administrator agrees local network changes and retains a way to administer and recover the installation.
Verify
Test the service the customer uses.
Complete the real application task. Check an allowed user and an unrelated user or resource that should remain inaccessible; test the intended public listener or outgoing source where relevant.
Keep in the deployment recordObserved result · access checks · recovery check
The customer checks the application result and confirms the approved audience, data permissions and operating behavior.
Hand over
Leave an installation they can operate.
Document what remains active, how to recover it and who handles support. Remove temporary technician membership, credentials and mappings, then verify withdrawn access stops.
Keep in the deployment recordOperating owner · recovery method · retained access
A named customer owner receives the operating record and agrees any continuing support access explicitly.
03 / Choose the service path
Start with the job
you are delivering.
Private support, an external endpoint and a known outgoing source need different scope. Choose the connection the customer needs before specifying the installation.
Compare the connection options →Approved servers and equipment interfaces
Support a private resource.
Networks can connect authorised technicians through supported enrolled devices or a supported gateway. Keep application login, allowed destinations and customer permissions in place. A LAN appliance behind a gateway does not automatically become an enrolled endpoint.
Explore private resource access →A service has external users
Deliver the selected endpoint.
Use Public IPs for address-based delivery to a supported device or gateway. Publish is a separate option for selected HTTP applications with public hostnames. Agree inbound rules, application authentication and any target mapping with the customer.
Explore Public IPs →Explore Publish →An external system checks the source
Agree the routing impact.
Confirm supported gateway delivery and which traffic must use the outgoing identity. LAN traffic must actually traverse the gateway; a shared source address or source NAT does not give every appliance an individual device identity. Current Outbound profiles are full tunnel, with one active organisation-wide profile.
Review deployment options →Keep the return path in the installation plan.
Private gateway targets need a return route or supported source NAT. Public service replies need the supported return path through Fibmesh. Placing a one-port connector on the LAN does not redirect unrelated equipment’s internet traffic.
04 / Your first working result
A connection the customer can take over.
Demonstrate one customer service, then hand over its configuration and operating responsibilities. Keep that customer’s authority, credentials and resources separate.
Discuss a deployment partnership →- 01 / Customer acceptance
Use the actual application.
Have the customer complete the agreed task through the intended connection. A tunnel coming up or an API record being accepted does not show that the application, login and return path work.
- 02 / Customer acceptance
Prove the access boundary.
Check both permitted and denied access. Keep customer credentials and resource plans separate; supporting another customer does not authorise a route between the two environments.
- 03 / Customer acceptance
Finish the operating handover.
Give the customer the allocation, targets, gateway placement, recovery procedure and support contacts. Verify temporary support access is removed and record any access they have agreed to retain.
The customer accepts
a working service.
Keep the acceptance result with the operating record. Agree who handles the application, local equipment, connectivity and recovery, including how the customer can withdraw ongoing support access.
05 / A practical first deployment
One installation.
A complete handover.
Start with a customer who can authorise the work and test the result. Settle the recovery and support arrangements before repeating the deployment elsewhere.
- 01
Agree on the working result.
Bring one customer resource, its owner and a useful task. Agree who needs access, who can authorise the changes and what the customer will test before accepting the installation.
- 02
Deploy within that customer’s scope.
Confirm supported software or gateway placement. Check local routes, return paths and application access with the customer’s administrator, keeping credentials and resource plans separate from other installations.
- 03
Hand over the operating details.
Demonstrate the real service, document recovery and assign ongoing responsibilities. Remove temporary technician access and keep a clear record of what remains in service.
Working with an existing appliance?
06 / Questions, answered
Before the
customer rollout.
Is there a released MSP or multitenant administration portal?
This solution does not establish one. Delegated customer management, consolidated billing and reseller entitlements need separate product and commercial confirmation. It does not introduce a formal partner programme, tier or certification. Discuss the partnership model.
Can one engineer support several customers?
The work can span several customer environments, but authority and credentials must remain explicit for each. Keep customer resources, permissions and operating records separate. Do not join their networks together just to simplify administration.
Can we ship preconfigured hardware?
The demonstrated Edge POC is a useful deployment pattern for compatible customer networks. Hardware remains development/pilot. Agree device support, provisioning, updates and recovery before treating it as a repeatable offer. The original POC demonstrated one configured target; later multi-target mapping designs are not evidence of fleet provisioning or simultaneous multi-target operation in that POC.
Can provisioning be automated?
Some API contracts and development CLI operations exist. The developer reference distinguishes these from released automation workflows. A successful API record creation does not establish a complete remote provisioning system, configured routes or working customer traffic.