Sign-in helpTalk to Fibmesh
Menu

MSPs & integrators

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.

Plan a customer deploymentExplore deployment options →

Connection paths

A clear connection inside each customer’s scope.

Follow the connectionIllustrative connection paths

Reach the customer resource approved for the job.

  1. Support engineerAuthorised identityPrivate access
  2. Customer private networkCustomer-approved membershipWireGuard
  3. Customer gatewayApproved routeLAN
  4. 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.

  1. External user / systemPublic endpointService request
  2. Fibmesh public deliveryAllocation and inbound rulesWireGuard
  3. Customer gatewayWireGuard and target mappingLAN
  4. 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.

  1. Customer AOwn resources and credentialsNo implied route
  2. Separate administrationExplicit authority for each customerNo implied route
  3. 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 →

Put it to work

Start with the service you are delivering.

An integrator may be connecting a branch, enabling support for a local server or giving an application a public endpoint. Fibmesh can supply the connection model; your implementation brings together the customer’s equipment, application and operating arrangements.

Support customer resources

Use a supported Networks deployment to reach approved servers or equipment interfaces. Scope the access to the customer and job being serviced.

Private resource access →

Connect a customer site

Put a supported gateway beside existing equipment or use a compatible router. Choose private routes, public port mappings or outgoing routing according to the requirement.

Deployment options →

Deliver an external endpoint

Use Public IPs for address-based access and source identity. Publish is a separate option for selected web apps with public hostnames.

Public service delivery →

Keep each customer’s credentials and access separate. Confirm gateway support and the current organisation-wide Outbound profile scope before promising a customer routing arrangement. Compare the connection options →

Illustrative customer-site infrastructure and workspace
Illustrative photography · not a photograph of the described customer or deployment.

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.

  • Agree who owns and authorises the installation
  • Test the actual customer application
  • Document recovery and remove temporary support access
Discuss a deployment partnership →

A practical first deployment

Build something the customer can take over.

  1. Agree on the working result

    Name the customer’s resource, who needs it and how success will be tested. Confirm who can authorise public exposure or an outgoing route change.

  2. Deploy within that customer’s scope

    Keep credentials and resource plans separate from other customers. Check supported software, routes, return paths and application access with the customer’s administrator.

  3. Hand over the operating details

    Document the allocation, targets, gateway placement, recovery method and support responsibilities. Remove temporary support access and keep a record of what remains in service.

Questions, answered

Before you connect.

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. 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. 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 is still development/pilot; agree device support, provisioning, updates and recovery before treating it as a repeatable offer.

Can provisioning be automated?

Some API contracts and development CLI operations exist. The developer reference distinguishes these from released automation workflows. Do not infer a complete remote provisioning system from a successful API record creation.

Bring a customer scenario and the installation you expect to support. We can map the connection, the equipment and the handover together.

Plan your first deployment →