On the application host
Localhost can stay local.
A connector is the small background service that links your host or LAN to Fibmesh. Visitors use a browser or API client; they do not install the connector.
A web app may listen only on 127.0.0.1:3000. A connector on that same host can deliver selected requests to it without binding the app to every network interface.
Localhost means “this machine.” The configuration must identify the connector as well as the target. Running an administrative CLI from your laptop does not make localhost refer to that laptop when the selected connector is on a server.
Several apps, separate links
Map the portal to port 3000, the API to 8080 and the preview to 5173. Each publication can be paused without pausing its neighbours. Each app handles its own user login or API credentials; Fibmesh-managed visitor controls are a planned extension.
One app, several names
A managed hostname and a verified custom domain can point to the same application in the proposed domain model. Cookies, canonical URLs and login redirects still need an intentional primary domain.
Servers and containers
Use an app address the connector can reach.
A local server, cloud VM or container host can be a place to run a published app when it has a supported connector and an internet path to Fibmesh. Hardware ownership and hosting provider do not determine the public hostname.
Container networking matters. A host’s loopback address is not a container’s loopback address. Choose a controlled host-bound port or a supported connector deployment in the appropriate container network. Do not expose the container runtime socket to make publishing work.
An always-on server is a better home for a business application than a laptop that sleeps. Device suspension, loss of power or application restarts can interrupt the public endpoint even while its hostname remains reserved.
Through Fibmesh Edge
The device keeps its software. Edge provides the connection.
Place a Fibmesh Edge connector on a network that can reach the selected application. A publication names that connector and an explicit target such as http://192.168.1.20:8080. The target device does not need to run WireGuard.
A server on the LAN
Publish a web ERP, reporting tool or customer portal. Keep its LAN address stable through a reservation or an approved name so the publication continues to select the intended server.
An equipment interface
Reach a supported NAS, appliance or other device’s web interface. Verify redirects, authentication and any additional browser connections before making it available.
One Edge connector can serve several explicit LAN targets. It proxies the selected request and its reply; it does not become the site’s default router. Existing local traffic and unrelated internet traffic keep their current path.
- Install on the host
- Choose this when you control the app’s machine. A local target such as 127.0.0.1:3000 stays on that machine.
- Connect through Edge
- Choose this when the app’s device cannot run a connector. Edge needs a reachable LAN address and port.
- Keep visitors simple
- Send the public link. Customers and API callers use the app’s existing authentication.
Compatibility
Having a web page is a useful start, not the whole test.
Some applications assume a local IP, redirect to a private hostname or require more than one protocol. Set the external base URL where supported and test login, uploads, downloads, live updates and logout from outside the site.
A camera or NVR may serve its settings over HTTP but use RTSP, UDP or a vendor-specific protocol for video. Publishing the settings page does not automatically publish those streams. Native mobile clients may also depend on protocols outside HTTP.
Phone-hosted origins are outside the current origin scope because operating systems constrain background services and tunnel lifetimes. Phones can still be visitors to compatible published applications.
Review protocol fit and limits →