Fibmesh Publish / Domains & access

Choose the address.
Decide who gets through.

A memorable name gets a visitor to the application. Domain ownership, HTTPS and application permissions each have a separate job.

Read the address Domains & access guide · Confirm platform and deployment support during assisted setup.

Publish is available with assisted setup. Confirm supported platforms and deployment requirements. Separately marked proposals remain outside the released scope.

01 / The default address

A name for the app.
A route for the visitor.

Each publication gets a Fibmesh-managed subdomain. Start without buying a domain or managing its DNS records.

Anatomy of a public application addressIllustrative · not a live hostname
https://studio-portal.publish.fibmesh.example/orders
01 / Connectionhttps://
HTTPS encrypts the visitor’s connection to the public gateway.
02 / Publicationstudio-portal.publish.fibmesh.example
DNS leads to the gateway. The hostname selects the publication and its application.
03 / Application route/orders
The app handles this page or route. It is not a second publication.

The .example suffix is reserved for documentation. All addresses shown here are fictional and are not live links. Confirm your assigned production hostname and naming rules during setup.

Keep the address

Pause. Move. Retarget.

Keep the name reserved while a publication is paused. When an application moves, retarget the publication so visitors can keep using the same URL. Availability still depends on an online application and connector.

Share the gateway

One name does not mean one IP.

Several names can share a gateway address. Each app does not need a dedicated public IPv4 address. Treat every public hostname as discoverable, even when you have shared it with only one person.

02 / Planned extension · custom domains

Your domain.
The same publication.

A custom domain is an optional address you own. In the planned workflow, it points to the publication through Fibmesh while the application stays on your host or LAN. The tunnel works the same way.

Planned custom-domain workflowportal.northstar.exampleNorthstar is a fictional organisation.
  1. 01Verify ownership

    Claim a name you control.

    Verify domain ownership before attaching it to a workspace. A domain claimed by another workspace cannot be silently reassigned.

  2. 02Connect DNS

    Point the name to the gateway.

    A subdomain can usually use a CNAME to the assigned gateway name. Apex domains need a separately supported DNS arrangement. Taking over your authoritative nameservers is not required.

  3. 03Make HTTPS ready

    Wait for certificate validation.

    Complete certificate automation before showing the domain as ready. DNS propagation, restrictive CAA records and validation failures need visible status and corrective instructions.

  4. 04Check the app

    Use the public name throughout.

    Update permitted hostnames, canonical URLs and authentication callback URLs where needed. Verify cookies and redirects against the public domain.

03 / Who is calling?

The audience changes.
Authentication matters.

A public route can lead to a private account. A customer portal may accept a connection from anyone, then show orders only after sign-in. An API checks its caller’s credential instead.

Browser / public application

Public route,
application login

The app validates its own users, sessions and permissions. Suitable for public sites and applications with appropriate authentication.

Available core workflowThe endpoint is reachable from the internet.
Browser / invited visitor

Protected
browser access

A proposed Fibmesh access gate checks an invited visitor before forwarding the request. Email access and organisation sign-in require their own implementation and release validation.

Planned access extensionConfirm separately before relying on it.
Service / non-interactive caller

Machine
credentials

Service clients need non-interactive authentication. Scoped tokens or other approved mechanisms must be revocable. Never embed tokens in public URLs or application logs.

Planned access extensionA browser login is not a machine credential.
Webhook senders

Validate the sender’s signature.

Preserve request bodies and relevant headers, validate the sender’s signature scheme and handle retries. A browser login prompt cannot stand in for webhook authentication.

Application permissions

Keep data access in the app.

A Fibmesh gate does not replace the app’s data permissions. HTTPS protects the connection; it does not decide whose orders or data the caller may see.

IP allowlists, when added, must use a verified visitor address from a trusted proxy path, never forged or untrusted forwarded headers.

04 / Certificate responsibilities

Two endpoints.
Two certificates to trust.

The public gateway’s certificate and the application’s certificate have independent lifecycles. A working public certificate does not validate the HTTPS connection to the origin.

Visitor → public gateway

Managed public HTTPS.

The gateway manages the public certificate. Managed HTTPS termination lets it apply HTTP access controls. Expiry, renewal failures and domain removal should be visible to the owner.

Connector → HTTPS application

Validate the origin separately.

Validate the application’s certificate against the intended hostname and trust configuration. Ignoring certificate errors or bypassing validation is not a production setup method.

TLS passthrough is a different delivery mode and is outside the current Publish scope.

See every encryption boundary →

Next / Getting started

A name is the start.
Check the complete route.

Choose a connector and target, confirm the assigned public address, then verify HTTPS and a real application task before sharing the link.