Fibmesh Publish / Limits & FAQ
A practical reference for protocols, operating responsibilities and the checks that keep a public application reachable.
Check your protocol Limits & troubleshooting reference · 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 / Protocol fit
Start with the service’s actual protocol. A working web interface does not establish support for every connection that device or application makes.
| Service | Fit decision | What to check |
|---|---|---|
| Available core workflow | ||
| HTTP and HTTPS web apps | Core workflow | External URLs, redirects, cookies and application authentication. |
| REST APIs and webhooks | Core workflow | Authentication, body fidelity, timeouts and sender retries. |
| Validate for your application | ||
| WebSockets and SSE | Confirm app and connector compatibility | Upgrade handling, buffering, reconnects and connection lifetime. |
| gRPC | Separate protocol validation | HTTP/2 on the appropriate connections and client behaviour. |
| Device web interfaces | Application-specific fit | Extra ports, media streams, private-address redirects and native clients. |
| Outside initial Publish scope | ||
| Raw TCP: SSH, RDP, databases | Choose another delivery model | Use Networks or assess Public IPs. |
| UDP, discovery and broadcast | Choose another delivery model | A hostname is not a network bridge or generic UDP relay. |
| TLS passthrough | Choose another delivery model | Different certificate ownership and access-control capabilities. |
03 / Diagnose the path
Follow the connection from the public name to the app. A saved publication is not evidence that every stage is ready.
04 / Common questions
Fourteen answers about setup, public addresses and the boundaries of the connection. Open any question to read its answer.
No. You provide and maintain the application and its host. Publish supplies the connection to that application. Your app’s data, backups and database remain your responsibility.
Pricing and usage allowances have not been announced. Confirm app count, traffic and connection limits when arranging setup.
Yes. Each publication selects a service and gets its own hostname; several can share one connector and WireGuard connection. Confirm publication counts and usage limits during setup.
Yes, with a connector on that host to perform local forwarding. Localhost means the connector’s own machine. WireGuard alone does not make the remote loopback interface reachable from the public gateway.
Public HTTP visitors need a compatible browser or API client, not a WireGuard connection. A future protected-browser policy may require visitor authentication without requiring network enrollment.
The connector establishes the WireGuard path outward, so the origin does not need a dedicated public address or an inbound router port-forward. The network must permit the required UDP traffic. There is no automatic TCP fallback in the current transport direction.
It can when the connector can establish and maintain its WireGuard connection. Keepalive traffic may be needed to preserve the connection through the router; restrictive firewalls and carrier policies still need testing.
Verified custom domains are a planned extension. They require ownership checks, DNS configuration and certificate management. Publish availability does not release this extension.
Path routing is technically possible, but applications may need base-path, redirect and cookie changes. The initial model uses a separate hostname per publication. General path routing and rewriting remain outside that initial scope.
Persistent publications run through a background connector. Closing the administrative terminal does not stop it, but shutting down or suspending the host can interrupt service. Temporary publication semantics are a separate proposal.
A compatible HTTP interface may fit. Printing, scanning, discovery, native clients and video streams can use different protocols. Use Networks for private equipment access or assess Public IPs for supported public delivery.
With managed HTTPS termination, the public gateway processes decrypted requests. WireGuard encrypts the connector transport. This model is not opaque browser-to-origin TLS passthrough.
Public gateway IPv4/IPv6 support and connector-to-origin address families are separate capabilities. An IPv6-only origin is technically possible with a suitable connector path; the released gateway and origin support matrix must establish availability.
No. A publication identifies one selected HTTP application and port. Other services need separate rules. Application vulnerabilities can still expose data through the selected app, so keep its permissions and security controls in place.
Next / Confirm your deployment
Confirm the protocol, connector, usage allowances and operating responsibilities during assisted setup, then test a real visitor task before sharing the link.
