The complete path
Four steps between a visitor and your app.
Before the first visit: the customer’s host or Edge connector establishes an outbound WireGuard tunnel to Fibmesh. Requests and replies then use that tunnel.
- 01VisitorBrowser or API clientHTTPS
- 02Fibmesh gatewayHTTPS and hostname routingWireGuard
- 03ConnectorOn the host or an Edge deviceHTTP / HTTPS
- 04Your applicationThe selected address and port
DNS directs the visitor to Fibmesh. The gateway matches the hostname to a connector and app, then forwards the request through the existing WireGuard tunnel.
A host connector reaches an app on its own machine; an Edge connector reaches a selected LAN server or device. Replies return through Fibmesh. Unrelated outgoing traffic keeps its existing route. The final connection uses HTTP or HTTPS; HTTP on the LAN is not encrypted by WireGuard.
- DNS directs the visitor to Fibmesh.
The browser resolves the publication’s hostname to the gateway’s public address, then connects to it over HTTPS. The hostname identifies a publication; it does not reveal or assign a public IP to the device running your app.
- The gateway selects the publication.
The gateway receives and decrypts the HTTPS request, matches the requested hostname to its authorised connector and application, and checks that the publication is enabled. The application validates visitor accounts or API credentials; a Fibmesh-managed visitor gate remains a planned extension. Unknown hostnames must not fall through to another customer’s application.
- WireGuard carries traffic to the connector.
The gateway forwards the request through the tunnel already established by the customer’s connector. WireGuard carries IP traffic; hostname selection and application forwarding are separate gateway and connector functions. The publishing path is restricted to the authorised connector and service; it does not grant visitors general access to the host.
- The connector reaches the application.
A host connector forwards to the app’s selected local address and port. An Edge connector makes a connection to the selected LAN target. Responses travel back through the connector and gateway to the visitor.
Routing
Requests arrive through Fibmesh. Their replies return through Fibmesh.
The application responds to the connector’s connection. The connector carries the response back to the gateway, which responds to the visitor. This avoids asking an ordinary LAN server to know a route to every public visitor.
Other traffic keeps its existing routes. An application making an unrelated outgoing API call still uses its normal internet path unless you separately configure Outbound or Public IP routing.
Encryption
Be precise about what each connection protects.
Visitor → public gateway
HTTPS protects this connection. Managed HTTPS terminates at the gateway, so the gateway processes application requests in plaintext internally.
Gateway → connector
WireGuard protects the transport to the enrolled connector. Device private keys stay on the device; the backend governs the authorised publishing policy.
Connector → local app
The connector can use HTTP or HTTPS to reach the app. Local HTTP can remain on the application host. A loopback address is meaningful only on that host; the public gateway cannot directly reach a remote machine’s localhost.
Edge → LAN service
This is a separate connection. HTTP and HTTPS are both possible. Use HTTPS with certificate validation to encrypt this LAN connection. A WireGuard tunnel ending at Edge does not encrypt a subsequent plaintext LAN hop.
Identity and isolation
A publication belongs to a workspace and an owner.
The backend authorises the hostname, connector and target as one publication. The gateway and connector apply that policy. A visitor cannot supply an arbitrary destination, choose a different tenant’s connector or turn the service into an open proxy.
Only the app you select should receive traffic. Other local services, internal cloud management addresses and destinations outside the approved rule must remain inaccessible through that publication.
Applications normally see a proxy connection rather than the visitor’s source IP. Visitor-address headers must be set by the trusted gateway and accepted only from the trusted proxy path. They are useful context, not authentication.
Operations
A saved rule and a working publication are different states.
A saved address is only the beginning. Before people can use it, the certificate must be ready, the connector must be online and the application must respond through the public link. Status needs to show which step is waiting, so you know what to fix.
- Address assignedThe public name selects your publication.
- HTTPS readyThe certificate matches that name.
- App reachableThe connector can reach the target.
- Public check passesA visitor can complete a real request.
Pausing should stop new requests while keeping the hostname reserved. Removal also needs defined handling for existing WebSockets and other long-lived sessions. Retargeting should include a health check and a clear rollback to the previous target.
Troubleshooting and operating limits →