01 / Business applications
The customer portal stays on your server.
https://studio-portal.publish.fibmesh.examplePublic HTTPS addressA business runs a portal alongside its inventory system on an office server. Customers need the portal; they do not need access to the rest of the office network.
A publication routes a public hostname to the portal’s web address and port through the server connector. The application continues to own customer accounts and data permissions. Its database remains an internal dependency with no publishing rule.
Plan for: a supported always-on host, the public base URL, reliable application login, backups and the upload capacity of the office connection. Publish supplies reachability; it does not host the application or store its data for you.
02 / Integrations
Receive the event where your code runs.
https://studio-hooks.publish.fibmesh.examplePublic HTTPS addressA developer is testing an integration, or a small team operates an API on its own server. An external system needs an HTTPS endpoint it can call without joining a private network.
The publication gives that HTTP endpoint a hostname. The application verifies tokens or the sender’s signature, rejects unauthorised requests and handles retries safely. Webhook delivery behaviour belongs to the sending service; Publish is not a queue or a replay store.
Plan for: preserving the request body, checking authentication, handling timeouts and safely processing repeated events. A callback made by your application uses its existing outgoing route unless you configure a separate outbound service.
03 / Client review
Show the work without creating another deployment.
https://studio-preview.publish.fibmesh.examplePublic HTTPS addressA studio has a preview running on a workstation. Give the preview a separate address so a client can open it in a browser. Keep test data in the environment and use the app’s access controls for the review.
Several projects can have separate publications on the same workstation. Closing one review means pausing or removing that publication, not taking every project offline.
Plan for: workstation sleep, development-server host restrictions and any exposed debugging tools. Automatic expiry and Fibmesh-managed visitor login are proposed extensions, not prerequisites you can assume are already supplied.
04 / Self-hosted services
Keep the application on infrastructure you choose.
https://team-docs.publish.fibmesh.examplePublic HTTPS addressA document portal, reporting tool or collaborative web app can run on a home server, dedicated machine or cloud VM. The public hostname belongs to the publication, so its intended identity is separate from the current hosting provider.
When moving the application, bring up and verify the new target before changing the publication. Moving a hostname does not move application data, active sessions or databases, and it does not guarantee uninterrupted migration.
Plan for: sustained bandwidth, resource limits, application updates and a realistic availability target. Private file shares and backup protocols may be better served by Networks.
05 / Edge and local equipment
Give an approved site application a reachable address.
https://branch-console.publish.fibmesh.examplePublic HTTPS addressA software vendor needs browser access to a web application installed at a customer site. The application server cannot run a connector, but a Fibmesh Edge connector can reach it on the LAN.
The publication selects that Edge connector and a specific LAN address and port. Other site applications can receive separate links. Ordinary local and outgoing traffic keeps using the existing network.
Plan for: customer approval, application authentication, a stable target address and LAN HTTPS where required. A Windows desktop ERP, NVR stream or proprietary native client needs protocol assessment; a public web link is not a universal remote-access client.
06 / Compute and specialist workloads
An HTTP interface to compute you operate.
https://lab-api.publish.fibmesh.examplePublic HTTPS addressA team runs an inference API or a processing service on its own machine. Publish can provide the intended HTTP entry point while the workload stays with that compute.
Streaming responses need validated buffering and timeout settings; large jobs may need an application-level job API rather than one very long request. Authenticate callers and enforce application quotas before accepting expensive work.
Plan for: concurrent connections, request sizes, processing duration and cost controls. Raw model-serving protocols, GPU scheduling and job queues are outside Publish’s role.
When another product fits
Choose the access model your clients need.
Networks fits colleagues and devices that should join a private network. Public IPs fits clients that need an address or non-HTTP service delivery. Outbound fits applications that need a chosen source IP for outgoing connections. Publish fits an HTTP application’s public entry point.
Compare a public link with a public IP →