A browser preview and a routed server target are different public-access requirements. Choose the smallest supported boundary that lets the intended client do the work.
01 · Two public surfaces
Compare the public surface
An application hostname
Publish
- Service
- One selected HTTP app and port
- Protocol
- Supported HTTP application delivery
- Audience
- A visitor opening the app in a browser
An assessed public address
Public IPs
- Service
- An assessed device or gateway target
- Protocol
- The required service protocol and address family
- Audience
- A compatible client that needs the target’s address
Compare the delivery and operating responsibilities. Scroll horizontally when needed; focus the table and use the arrow keys.
| Decision | Publish | Public IPs |
|---|---|---|
| Primary target | Selected HTTP app and port | Assessed device or gateway target |
| Delivery model | Gateway-mediated publication | Assessed routed address delivery |
| Address need | Managed subdomain direction | Public allocation and address family |
| Security review | App permissions and publication rule | Target, firewall, forwarding and return path |
| Multiple workloads | Separate app hostnames over a connector | Separate addresses using Routed Subnets |
| Lifecycle focus | Enable, disable, delete rule | Pause, resume, release reservation |
02 · Check the direction first
Check the outgoing requirement separately
If the only problem is an external provider’s source-IP allowlist, compare Public IPs and Outbound. An inbound link or public target may not be needed at all.
Compare Publish and Public IP capabilities against your target, then verify availability before an evaluation.
03 · Select the application
Start with a web application
For one supported HTTP app, a Publish link ties publication to a selected service. It can avoid assigning scarce dedicated IPv4 purely to share a browser preview. Publish delivers selected HTTP applications through a managed gateway and WireGuard connector. Multiple applications can have separate hostnames over one connector; custom domains and additional access controls remain distinct extensions.
Keep administration, databases and unrelated services outside the public grant. Gateway TLS does not replace application authentication or turn every transport segment into an end-to-end encryption guarantee.
- External visitorOpens studio-preview.fibmesh.example
- Fibmesh gatewayResolves hostname to the chosen app; HTTPS terminates here
- Customer connectorWireGuard tunnel to the enrolled host
- Local application127.0.0.1:3000 on that host, or an approved reachable LAN target
Policy: The publication selects the target. Application authentication remains the app’s responsibility. Other ports are not published by this rule.
Return path: The application response returns through the connector and gateway to the visitor. The hostname is a fictional example, not a live service.
Publish is available with assisted setup. Custom domains and richer access controls remain separately planned.
04 · Assess the target and allocation
Use public identity for a real target requirement
A workload may need an assessed public address for compatible clients or a particular delivery model. Choose a device or gateway target, verify IPv6/IPv4 requirements and define permitted ports and sources. Check return routing as well as incoming requests.
Target and family
Identify the device or gateway and confirm the actual client’s IPv6/IPv4 support.
Permitted access
Record the required service, allowed ports and source restrictions.
Request and reply
Verify forwarding and the configured return route with the real client.
A routed address can carry a broader exposure surface. Its presence should not be treated as permission to open every service. Routed Subnets is a separate, invitation-led managed service within Public IPs, with provisioning arranged directly with Fibmesh. Orchestration and failover remain separately scoped.
For an internal service used only by approved workspace members, assess private access before choosing a public surface.
05 · Choose your next reading
Does the visitor need a browser link or a routed address?
The visitor needs an HTTP app in a browser.
Start with the smallest public surface: a Publish link to a selected application address and port, using the supported managed hostname and gateway.
Explore Publish →The service protocol actually needs a public address.
Consider Device IPs or Gateway IPs. Confirm allocation, protocol, explicit firewall rules, return routing and the actual client’s address-family support.
Explore Public IPs →The provider needs to allow my outgoing source.
That is a source-identity requirement. A public link to your application will not satisfy it; use the inbound/outbound guide before selecting an allocation.
Check the connection direction →