Fibmesh Publish / Apps & devices

Choose the host.
Select the app.

Run a connector beside the application, or reach it through a connector on its local network. Choose a target from the connector’s point of view.

Find the right target Deployment 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 / Start where the connector runs

Localhost belongs
to that machine.

A connector is the background service linking the host or LAN to Fibmesh. Visitors use a browser or API client; they do not install it.

Illustrative host-local targetConnector + target identify the destination
Administration

Your laptop

The CLI selects the connector and the application target.

Running the command here does not make the server’s localhost refer to this laptop.

Selected application host
Host connectorTarget resolved here
Web application127.0.0.1:3000

The connector can reach this local listener on its own machine. The app can stay bound to loopback instead of every network interface.

02 / Separate the app from the connection

One connector.
Several app links.

Several applications can share the same WireGuard connection. Give each application its own publication so its public link and pause control remain separate.

Illustrative mappingsSame host connector · same tunnel
PortalSeparate public link
127.0.0.1:3000Pause independently
APISeparate public link
127.0.0.1:8080Pause independently
PreviewSeparate public link
127.0.0.1:5173Pause independently

Pausing one publication does not pause its neighbours. Each app still handles its own user login or API credentials; Fibmesh-managed visitor controls are a planned extension.

03 / Choose a dependable origin

Reach the listener.
Keep the host awake.

A local server, cloud VM or container host can 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.

  1. 01

    Confirm the network boundary.

    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.

  2. 02

    Expose the application deliberately.

    Use an application address and port the connector can reach. Do not expose the container runtime socket to make publishing work.

  3. 03

    Plan for continuous operation.

    An always-on server is a better home for a business app than a laptop that sleeps. Suspension, power loss and application restarts can interrupt the endpoint even while its hostname remains reserved.

04 / The alternative for LAN equipment

The device keeps its software.
Edge connects to it.

Choose a connector on the local network when the app’s device cannot run one. The target device does not need WireGuard.

Selected connectorFibmesh Edge

On a network that can reach the app

Explicit application targethttp://192.168.1.20:8080

Illustrative LAN address and port

A server on the LAN

Reach a web ERP, reporting tool or customer portal. Keep its LAN address stable through a reservation or an approved name so the publication selects the intended server.

An equipment web interface

Reach a supported NAS, appliance or other device’s web interface. Verify redirects, authentication and additional browser connections before sharing it.

One Edge connector can serve several explicit LAN targets. It proxies each selected request and reply; it does not become the site’s default router. Local traffic and unrelated internet traffic keep their existing path.

05 / Before sharing the link

Test the application.
Beyond the first page.

Some apps assume a local IP, redirect to private names or need more than one protocol. Check the complete visitor task from outside the site.

  1. 01

    Set the external address.

    Where the app supports it, set its external base URL. Follow redirects and check that they do not send visitors to a private IP or local hostname.

  2. 02

    Complete a real sign-in.

    Test login, application permissions and logout from outside the site. Check cookies and login redirects against the intended public domain.

  3. 03

    Move real data.

    Try uploads, downloads and live updates. A working landing page does not establish that every browser connection the app needs will work.

  4. 04

    Identify every protocol.

    A camera or NVR can serve settings over HTTP while video uses RTSP, UDP or a vendor-specific protocol. Publishing the settings page does not automatically publish those streams. Native mobile clients may also need protocols outside HTTP.

  5. 05

    Keep phones on the visitor side.

    Phones can visit compatible published applications. Phone-hosted origins are outside the current origin scope because operating systems constrain background services and tunnel lifetimes.

Review protocol fit and limits →

Next / Domains & access

Give the app a name.
Keep access intentional.

With the connector and target chosen, plan the public address and the authentication your application needs.