Conceptual scenario
Put an application within reach.
A customer portal, webhook receiver or review environment can share the same publishing model. Choose the origin and audience that fit your application.
Explore products ↗A conceptual application plan, not a customer case study or released installation instructions.
Publish / Available
The app stays with its host. Its audience gets a URL.
Start with a client review application. Its selected HTTP listener gets a public HTTPS hostname. The database and administration services stay outside that publication.
One application
The client’s review application
- Reviewer
- Managed Publish link
- HTTP preview
- Target
- Selected enrolled server
- Listener
- 127.0.0.1:3000 · example HTTP app
- Other services
- Database and administration outside this rule
A public review does not grant private workspace membership.
Follow the request across three boundaries.
- Visitor and gateway
- The reviewer uses a browser; no connector is needed on their device. Managed HTTPS ends at the public gateway, which decrypts and processes the request. The hostname selects the authorised publication.
- Gateway and connector
- The selected connector establishes its outbound WireGuard tunnel before the visitor arrives. The tunnel protects transport to the connector; it does not grant general access to the host.
- Connector and app
- The host connector reaches the selected listener on its own machine. Here,
127.0.0.1:3000means that host’s example HTTP app. Replies return through the connector and gateway.
The review app still owns its login and data permissions. A public link does not create an application account or private workspace membership.
Publish is available with assisted setup. Contact Fibmesh to confirm the connector, application and location requirements.
Choose what the audience should reach
Different apps. Deliberate destinations.
Several applications can share one connector and tunnel. Give each app a separate publication so its public link and pause decision remain independent.
Illustrative choices, not verified deployments. Scroll sideways to compare all columns. With a keyboard, focus the table region and use the arrow keys.
| Application | Intended audience | Origin from the connector | Application responsibility |
|---|---|---|---|
| Customer portal | Customers with an application account | Host-local HTTP or HTTPS service | Retain login, roles and data permissions. |
| API or webhook receiver | Authorised callers or a known webhook provider | Selected server’s HTTP or HTTPS listener | Validate API credentials or webhook signatures and safe retries. |
| Client review | Intended reviewers | Review app on the selected host | Choose suitable test data, keep app authentication and retire the publication after review. |
| Customer-site web app | Approved users of that application | Explicit LAN address and port reached by an Edge connector | Obtain site approval and test the app’s own login and protocol needs. |
Localhost is relative to the connector.
The selected host defines the target, even when an administrator works from another computer. A container’s loopback and the host’s loopback are separate network environments.
The LAN hop has its own boundary.
WireGuard ends at Edge. Plaintext HTTP from Edge to a LAN app is not encrypted by that tunnel; use HTTPS with certificate validation to protect that hop. Edge hardware remains development/pilot, separate from Publish availability.
Plan the connection
Start with the service, its owner and its audience.
Record these decisions before sharing a link. A saved publication is a plan; a real external request checks whether the intended application is usable.
Name the owner and target.
Record who operates the app, where it runs, the supported connector and the exact listener address and port. Confirm that the connector can reach it and that the host stays online.
Check the protocol and audience.
Choose public HTTP reachability deliberately. Native protocols outside HTTP require a separate delivery decision. The app remains responsible for login, API credentials and webhook signatures; Fibmesh-managed visitor controls are planned.
Complete the actual task.
Verify the public name and HTTPS readiness, then test login, redirects, uploads and live updates from outside the site. Check an unauthorised application request as well as a successful one. Confirm that unrelated database and administration services remain outside the publication.
Agree how the link ends.
Choose when to pause or remove the publication, verify that new requests stop, and agree how existing sessions are handled. A temporary review should have a named person responsible for retiring it.
Continue with the product guides
Use the deployment guide for origin details and the getting-started guide for the supported evaluation path.