Managed hostnames
An address that belongs to the publication.
https://studio-portal.publish.fibmesh.example/orders- https://
- The encrypted connection between a visitor and the public gateway.
- studio-portal.publish.fibmesh.example
- The hostname selects the publication and its application.
- /orders
- A page or route handled by that app. It is not a second publication.
The default is a Fibmesh subdomain for each publication. You do not need to buy a domain or manage DNS records for that address. DNS leads visitors to the gateway; the publication selects the application behind the connector. Several names can share a gateway address without needing a dedicated public IPv4 address for each app.
Keep the name reserved while the publication is paused. When an application moves, retarget the publication rather than asking every visitor to learn a new URL. The application’s availability still depends on an online application and connector.
Addresses such as studio-portal.publish.fibmesh.example illustrate a Fibmesh-managed subdomain. The .example ending is reserved for documentation, so these are not live links. Confirm your assigned production hostname and naming rules during setup. Treat a public hostname as discoverable, even if you have shared it with only one person.
Planned extension / custom domains
Use the name your customers already know.
A custom domain is an optional address you own, such as portal.northstar.example. In the planned custom-domain workflow, it points to the same publication through Fibmesh. The application stays on your host or LAN; changing its public name does not change how the tunnel works. Northstar is a fictional organisation used only for this example.
- Claim a domain you control.
Domain ownership must be verified before a workspace can attach it. A domain already claimed by another workspace cannot be silently reassigned.
- Add the required DNS record.
A subdomain can usually point to the assigned gateway name with a CNAME. Apex domains need a separately supported DNS arrangement. Moving all authoritative DNS to Fibmesh is not a requirement of this design.
- Issue and verify HTTPS.
Certificate automation must complete before the domain is shown as ready. DNS propagation, restrictive CAA records and validation failures need clear status and corrective instructions.
- Check the application.
Update permitted hostnames, canonical URLs and authentication callback URLs where necessary. Verify that cookies and redirects use the public domain.
Disconnecting a domain must remove its route and certificate association. Ownership must be checked again before reuse so a stale DNS record cannot give another account control of the old application address.
Audience
A customer, a colleague and an API caller need different access.
Available core workflow
Public route, application login
The endpoint is reachable from the internet. The application validates its own users, sessions and permissions. This suits public sites and applications that already have appropriate authentication.
Planned access extension
Protected browser access
A Fibmesh access gate checks an invited visitor before forwarding the request. Email-based access and organisation sign-in need their own implementation and release validation.
Planned access extension
Machine credentials
Service clients need non-interactive authentication. Scoped tokens or other approved mechanisms must be revocable and must not be embedded in public URLs or application logs.
Application responsibility
Webhook authentication
Many webhook senders sign requests using their own scheme. Preserve the body and relevant headers, validate the signature and handle retries. A browser login prompt cannot stand in for this check.
For example, a customer portal can accept connections from anyone while showing orders only after the customer signs in. An API checks a token instead. HTTPS protects those connections; it does not decide whose orders or data a caller may see.
A Fibmesh access gate does not replace the application’s own data permissions. IP allowlists, when added, need to use the verified visitor address rather than an untrusted forwarded header.
Certificate lifecycle
HTTPS includes renewal and failure handling.
The public gateway manages its certificate independently of the application’s certificate. An HTTPS application on the LAN must be validated against the intended hostname and trust configuration; ignoring certificate errors is not a production setup method.
Certificate expiry, renewal failure and domain removal should be visible to the owner. Managed HTTPS termination lets the gateway apply HTTP access controls; TLS passthrough is a different delivery mode and is outside the current Publish scope.
See every encryption boundary →