Where Fibmesh runs
Start with the resource, then choose the connector.
The deployment method determines how a resource participates. The product determines what it can do: join a private network, serve a public application, receive public addresses or route internet traffic. A supported tunnel alone does not establish support for every product.
Keep the resource where it belongs.
Bring the permitted connection to it.Apps & agents
Join a working device or an unattended server directly.
Computers and mobile devices
A supported native app provides enrollment and visible connection state. Its platform-specific networking runtime applies authorised settings. Mobile permissions, background execution and VPN behaviour differ from desktop systems.
Servers, VMs and workloads
A supported headless agent can participate without a desktop session. Confirm service installation, local privileges, credential storage, boot behaviour and recovery after a restart.
Direct enrollment gives the device its own identity. Joining another private access group changes membership rather than creating another device or private address. Native software can manage policy and report local results where implemented; installation instructions must match the actual release.
Container and mobile deployment boundaries
A container needs an appropriate network namespace and permissions. A host-level installation does not automatically enroll every container, and a network sidecar is a topology choice rather than proof of a supported Kubernetes integration.
The current v1 platform intent excludes iOS and Android as public ingress targets. Do not use phone VPN support as evidence that a mobile device can host the same public service as a supported server.
Sites & equipment
Reach resources that keep their existing software.
A customer gateway can connect approved LAN or cloud subnet resources: servers, NAS storage, printers, NVRs or IoT equipment. It needs an enrolled identity, permission to forward traffic and explicit destination scope. These resources retain their local addresses and do not each receive a Fibmesh device identity merely by being on that LAN.
The destination must have a valid reply path. Depending on the supported deployment, that can require a route back to Fibmesh addresses or source NAT at the gateway. Source NAT changes the source seen by the target; it is not transparent preservation of the original client identity.
A Fibmesh routing node carries the service-side connection. A customer gateway reaches your local network. A Fibmesh Edge device is a possible physical deployment of a connector or gateway role, not another public product.
What the Edge pilot demonstrated
The Edge POC demonstrated access to existing equipment through remotely configured targets. A connector attached to one LAN port does not automatically take over internet routing for the site. Serving inbound targets, providing an outgoing identity and acting as the default route are different configurations.
Manual WireGuard profiles
Compatibility Mode has a smaller managed experience.
An assessed manual WireGuard profile can connect supported equipment that does not run a managed Fibmesh app. Generate private key material locally and submit the public key through the approved process. Do not treat generic WireGuard support on a router as confirmation that every Fibmesh capability works there.
Manual profiles do not provide the native dynamic policy refresh, diagnostics or complete route and DNS lifecycle. Record who installs and updates the configuration, who can remove it, and how access is revoked at the service boundary. Choose this mode deliberately when its limits fit the job.
Before setup
Answer these questions once, before changing the network.
Scroll sideways to compare deployment requirements.
| Check | What you need to know |
|---|---|
| Resource and owner | Which device, service or destination range is involved, and who authorises it? |
| Software | Is there a supported package and capability for the exact OS, appliance or host? |
| Existing routes | Are there overlapping LAN ranges, other VPNs, cloud routes or security groups? |
| Reply path | Can the target return traffic correctly? Is source preservation required? |
| Names and applications | Are DNS, application accounts, certificates and any required drivers configured? |
| Operations | Who handles upgrades, failures, key protection and retirement? |
Evaluate permitted access, denied access, restart/reconnect and removal. Check ordinary ISP traffic as well as the new path. A working handshake alone is not a complete application test.
Check software and release information →Deployment questions
Fit the connection to your environment.
Do we need Fibmesh hardware?
Not for every deployment. Supported devices can join directly, and a suitable supported gateway can connect a site. Fibmesh Edge hardware remains development/pilot; it is a deployment option, not a mandatory purchase.
Can a printer or scanner work across the private network?
Routable services can be reached through an approved gateway path. The application still needs the appropriate protocol, driver and account. Broadcast discovery and “same Wi-Fi” behaviour are not automatically carried across a routed network.
Can we connect several clouds without moving applications?
Use supported agents or gateways in the relevant environments and approve the required paths. Check address overlap, cloud firewalls, return routing and provider egress costs. Dedicated cloud circuits and automatic failover are separate capabilities, not implied by this design.