Begin with the audience
An internal database, a customer-facing web app and a supplier API can use the same server while needing different paths. Decide who should reach each service before choosing a hostname, address or route.
| Job | Product | What it changes |
|---|---|---|
| Approved colleagues reach an internal resource | Networks | Private reachability between permitted participants and resources |
| Visitors open a selected web app | Publish | A public hostname leads to that application through a Fibmesh gateway and customer connector |
| Clients reach a public address, or a workload needs that address as its source | Public IPs | Routed public identity, with separate routing and firewall choices |
| A device needs a chosen internet exit | Outbound | Eligible internet traffic follows a full-tunnel profile |
A private path to the build server
- Your enrolled laptopHome, office or mobile internet
- Fibmesh nodeCurrent node-routed connection
- Enrolled serverOr a gateway to a private LAN
- Internal applicationApplication login still required
Policy: Access rules decide which resources the laptop may reach. The rules govern this path; they are not an extra network hop.
Return path: Replies use the established private path. Unrelated internet traffic keeps its existing route unless another routing policy changes it.
The colleague needs network permission and the build system’s own login. A private name helps locate the server; it does not grant access. Current connections use Fibmesh nodes. Direct peer-to-peer paths are planned.
A public path to one web application
- 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.
The connector must be able to reach the target. A loopback address such as 127.0.0.1:3000 refers to the connector’s own host; it cannot identify an app on a different LAN server. Use that server’s reachable LAN address when appropriate.
Several apps can have separate hostnames over one Publish connector. Opening one app does not open SSH, a database or every port on the machine. Publish is available; custom domains and additional access controls remain planned extensions.
A public address has separate traffic controls
Public IPs can deliver a routed address directly to a supported device or use a gateway and forwarding/NAT arrangement. Routed Subnets supplies a block for multiple workloads. IPv4 and IPv6 allocations are separate decisions.
Choose inbound access, selected outgoing destinations or full tunnel. Then set incoming firewall rules independently. Allowing a reply to a connection you started is different from allowing a new connection from the internet.
Compare Public IP traffic options →An internet exit is a different decision
Outbound currently uses full-tunnel routing for eligible internet traffic, including its stable-source use case where an allocation is confirmed. It does not publish an incoming service. If only selected destinations should use a public source while other traffic stays on the ISP, compare Public IPs.
Choose between Public IPs and Outbound →Check the boundary from both sides
Test the connection that should work. Then test an unrelated port or unauthorised source that should remain blocked. Check the return path, application login and the route for unrelated traffic. These checks are more useful than treating “connected” as permission to reach everything.