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.
Compare the public surface
| 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 |
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.
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.
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 Public IPs service, outside the app MVP; new orchestration and failover features remain separately scoped.
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.
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 →