Fibmesh PublishAvailable

Your app stays.
The link travels.

Give your web app or API a public HTTPS address. Keep it on your infrastructure, with application login under your control.

Publish is available with assisted setup. Confirm supported platforms and deployment requirements.
Public app publishingFibmesh / Publish
studio-portal.publish.fibmesh.example
Public gatewayConnectorSelected app
A web address for the app you run. Illustrative model.

One connection. Separate addresses.

Three apps.
One connector.

A portal, an API and a preview can share a connector. Each gets its own hostname and an explicit destination.

Illustrative product modelThree applications / one connector
Public HTTPS addresshttps://studio-portal.publish.fibmesh.exampleA browser or API client starts here. No Fibmesh client needed.
Fibmesh gatewayHostname selects the appHTTPS ends at the gateway
WireGuard tunnel
Host connectorForwards to the chosen serviceConnects outward first
HTTP / HTTPS
Customer portal127.0.0.1:3000Application checks access

Customer portal: the connector on the app host forwards to 127.0.0.1:3000. Replies follow the connection back through Fibmesh.

Example / Customer portal

A familiar way in for your customer.

Share a web address for the portal you already run. Customers sign in with the application’s account; they do not need a Fibmesh client.

Managed hostname
studio-portal.publish.fibmesh.example
Connector on the host
127.0.0.1:3000
Connector on the LAN
192.168.1.20:3000
Example / Integration API

An address the other system can call.

Give an integration a public HTTP endpoint. Validate API credentials and webhook signatures in your application before accepting the request.

Managed hostname
studio-api.publish.fibmesh.example
Connector on the host
127.0.0.1:8080
Connector on the LAN
192.168.1.30:8080
Example / Review preview

Let someone see the work in progress.

Share a selected preview with the people reviewing it. Use test data, protect access in the app and pause or remove the publication when the review ends.

Managed hostname
studio-preview.publish.fibmesh.example
Connector on the host
127.0.0.1:5173
Connector on the LAN
192.168.1.40:80

Illustrative addresses, not live services. .example is reserved for examples; the production suffix is not final. The connector must establish its WireGuard tunnel before visitors use the address.

Each publication pairs one hostname with one selected HTTP application and port. Pause one without changing its neighbours, or retarget it when the app moves. Verify the new destination before sharing.

For your visitorsA browser or API client.

For your applicationA public web URL of its own.

For your siteAn outward connector tunnel.

Illustrative office with a server rack and laptop workstation
Illustrative setting · AI-generated scene.

Keep the app where it belongs

On your host.
Or on your network.

Keep the application on the infrastructure you maintain. Place the connector beside the app, or on its LAN with a path to the selected service.

Explore apps & devices →
01 / Same machine

Connect the app host.

Run the background connector on a supported server or computer. It forwards the chosen requests to an app on that machine, including localhost.

Host connectorlocalhost:3000

Localhost refers to the connector’s own machine.

02 / Another device

Connect from the LAN.

Use a supported LAN connector to reach a selected web service on another server or device. The target keeps its existing local address and software.

LAN connector192.168.1.20:3000

Confirm connector support during setup. Edge hardware remains a development and pilot option.

Useful things, within reach

What will your
link open?

Explore all use cases →
01

Your customer portal.

A familiar web address for an application you maintain. Keep its accounts, data and hosting under your control.

Self-hosted portals ↗
02

Your next integration.

A public endpoint for an API or webhook sender. Let the application validate tokens, signatures and incoming requests.

APIs & webhooks ↗
03

Your work in progress.

A review link for a selected development app. Protect it in the application and retire the publication after the review.

Review environments ↗

Public reach. Deliberate scope.

A front door.
For the app
you choose.

Follow the complete request path →
01 / Visitor access

The application checks who gets in.

A public URL makes the app reachable. Its login, permissions, API credentials and webhook checks decide what a visitor can do. Fibmesh-managed visitor access is a planned extension.

02 / Connection security

Understand each part of the path.

Visitor HTTPS terminates at the Fibmesh gateway, which processes the request. WireGuard protects the connector tunnel. Use appropriate HTTP/HTTPS protection between the connector and the app, especially across a LAN.

03 / Product fit

Choose the connection the service needs.

Publish routes a selected HTTP app by hostname; each app does not need a dedicated public IPv4. Use Networks for private resource access, or assess Public IPs for address-level reachability and other supported protocols.

Compare connection options →

Before you publish

A useful link
starts here.

Read the full limits & FAQ →
Do we need a static IP or router port forwarding?

The connector initiates its tunnel outward, so the origin does not need a dedicated public address or an inbound router port-forward. Your internet path must permit the required WireGuard UDP traffic. CGNAT can work when that connection can be established and maintained; restrictive networks need testing.

Can we use a domain we already own?

The core model uses a Fibmesh-managed subdomain for each publication. Custom domains are a planned extension with separate ownership, DNS and certificate requirements.

Explore domains & access →
What needs to stay online?

The app, its host, the background connector and their internet path must remain available. Closing an administrative terminal does not stop a persistent connector, but suspending the host can interrupt it. Publish does not supply application hosting or backups, and leaves the host’s ordinary outgoing route in place.

Will every application or device work?

Confirm application and connector compatibility during setup. WebSockets, SSE and device web interfaces need application-specific checks. Raw TCP, UDP and local discovery are outside the web publishing model. Video streams and native clients can need other protocols. Separately marked proposals remain outside the released scope; CLI commands are proposed syntax.

Your first publication

Pick the app.
Plan its public address.

Tell us what runs, where it lives and who needs to reach it. We’ll help confirm the right setup.