Managed HTTPS ends at the gateway.
The gateway receives and decrypts the HTTPS request, so it processes application traffic in plaintext internally. This is not opaque browser-to-origin TLS passthrough.
Fibmesh Publish / How it works
A public name.
A deliberate path.
Follow a request from the visitor to the app—and back. Know where the tunnel ends, who handles authentication and what a working publication requires.
Follow the connection Architecture guide · Confirm platform and deployment support during assisted setup.Publish is available with assisted setup. Confirm supported platforms and deployment requirements. Separately marked proposals remain outside the released scope.
01 / From the visitor to the application
Four steps.
One selected application.
The customer’s connector establishes its tunnel first. A visitor then uses a browser or API client; no connector is installed on the visitor’s device.
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
Unrelated outgoing connectionYour appExisting router / ISPExternal service
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.
- 01
DNS finds the gateway.
The publication hostname resolves to Fibmesh’s public gateway. It selects an application; it does not reveal or assign a public IP to the device running it.
- 02
The hostname selects the publication.
The gateway decrypts HTTPS, matches the requested name to an authorised connector and target, and checks that the publication is enabled. Application login remains the app’s responsibility; a Fibmesh-managed visitor gate is planned.
- 03
The existing tunnel carries the request.
The connector establishes its outbound WireGuard tunnel before the visitor arrives. Hostname selection and application forwarding are separate gateway and connector functions; the tunnel does not grant general access to the host.
- 04
The connector reaches the selected app.
A host connector reaches an address and port on its own machine. An Edge connector reaches an explicit LAN target. The response returns through the connector and gateway.
03 / Every encryption boundary
Protect each leg.
Understand each endpoint.
Explore the security model →WireGuard protects this transport.
Device private keys stay on the device. Backend policy authorises the connector and publication; the tunnel carries the permitted traffic.
Localhost belongs to that host.
The connector can use HTTP or HTTPS. Local HTTP can remain on the app’s machine; the public gateway cannot directly reach a remote machine’s loopback interface.
The final LAN hop is separate.
Use HTTPS with certificate validation to encrypt this connection. WireGuard ending at Edge does not encrypt subsequent plaintext HTTP on the LAN.
04 / Workspace and target isolation
One publication.
An explicit destination.
The backend authorises the hostname, connector and target together. Gateway and connector policy must prevent arbitrary forwarding, tenant crossover or an open proxy. Unknown hostnames must not fall through to another customer’s app.
Only the selected application should receive traffic. Other services, internal cloud management addresses and destinations outside the rule remain outside that publication.
- Application permissions
- The app owns accounts, API credentials and data access. A future Fibmesh visitor gate does not replace these controls.
- Visitor address
- Apps normally see a proxy connection. Address headers must be set by the trusted gateway and accepted only from the trusted proxy path; they provide context, not authentication.
05 / From saved configuration to usable service
A name is a start.
Verify the whole publication.
Check each stage before sharing the address. A saved rule does not establish certificate readiness, a healthy connector or a responding application.
- 01
Address assigned.
The public name selects the intended publication.
- 02
HTTPS ready.
The certificate is ready and matches that name.
- 03
Application reachable.
The online connector can reach the selected target.
- 04
An external request succeeds.
A real visitor can complete the intended application task.
Pausing should stop new requests while reserving the hostname. Agree how removal handles existing WebSockets and other long-lived sessions. Retargeting needs a health check and rollback to the previous target.
Review operating limits & troubleshooting →Next / Apps & devices
Choose the connector.
Reach the right app.
Run the connector with the application, or use an approved connector on its local network. The target is always interpreted from that connector’s point of view.