A public URL or a public IP?

You have an application that works on your own machine. Now somebody outside your network needs to use it.

Choose service-specific publishing when visitors need one web application or API through a public URL. Choose a public IP when the deployment needs direct network addressing or a protocol outside the supported publishing scope. Team-only resources may instead need a private path.

Those choices determine the services you expose and the routing, firewall and application controls you have to operate.

Use a public URL for a selected web application

A customer portal, browser-based tool, application programming interface (API) or webhook receiver often needs a specific HTTP (Hypertext Transfer Protocol) endpoint. The visitor does not need general access to the machine running it.

A publishing service can accept requests at a hostname, select the approved application and carry those requests to a connector that can reach it. This reverse-proxy pattern keeps the destination tied to a particular service. MDN’s guide to proxy servers explains how a reverse proxy sits in front of servers.

Fibmesh Publish is designed around that job. It is available with assisted setup; the examples here explain the connection model rather than a self-service installation procedure.

The target might be an application on the connector’s host, in a container or on a reachable LAN server. The connector must be able to reach that target itself. Publishing a hostname does not give the public gateway a direct path to an arbitrary private address.

Use a public IP for direct network reachability

Some clients expect to connect to an IP and port using a protocol outside HTTP application publishing. A supported device or gateway may also need an address under its own routing and firewall configuration.

That is a Public IPs question. A device assignment, gateway-backed target or routed subnet can meet different addressing requirements, subject to the supported delivery and commercial terms.

It is also a broader operating responsibility. Review the services listening on the target, the inbound rules and the return path. The public address creates the possibility of reachability; it does not decide which connections are permitted or whether an application is safe to expose.

If the only intended audience is your own team, pause before making either choice. Networks may provide the private path the team actually needs.

Compare which services each access boundary exposes

Imagine an office machine running a web portal, a database and an administration service. The public job is to let customers open the portal.

In a service-specific publishing design, the published hostname selects the portal target. The database and administration service must remain outside that publication. The customer does not get a route to choose a different local port or a different machine.

With a public IP assignment, firewall and service configuration define what clients can reach. You can restrict that exposure carefully, but the responsibility sits at a different boundary. A public IP is appropriate when you need that addressing model; it should not be a reflexive answer to every request for a web link.

Check where HTTPS and tunnel encryption end

For the Publish design, HTTPS protects the connection from the visitor to the public gateway and terminates at that gateway. WireGuard protects the gateway-to-connector transport. The connector then connects to the application over HTTP or HTTPS.

Those are separate connections. A plaintext hop across a LAN remains plaintext even if another part of the path uses a tunnel. Choose HTTPS with certificate validation where that hop needs protection.

Application login is another separate concern. Network policy and a permitted publishing target do not automatically authenticate a customer inside your app. Keep the application’s login, authorization and session controls appropriate to its audience. Treat richer identity-aware publishing controls as capabilities to verify, not assumptions.

Compare a partner API preview and equipment access

A development team wants a partner to test a proposed API endpoint. The requirement is a specific HTTP service with a limited audience and a defined lifetime. Publishing is a sensible model to evaluate. Decide what credentials the partner uses, whether the test data is safe to expose and how the publication ends.

A service engineer needs to reach equipment using an existing protocol. A browser URL may not represent that protocol at all. If the equipment can use private access, evaluate Networks. If public IP reachability is required, evaluate the supported Public IPs and gateway arrangement, with explicit port and audience restrictions.

Document the protocol, audience and access boundary

Record the protocol, target and port, who starts the connection, who is allowed to use it and where encryption terminates. Include what must remain inaccessible. For a temporary preview, include the removal date and owner.

That brief makes the choice easier. Publish one application when the application is the public destination. Use a public address when the deployment needs public network addressing. Keep team-only resources private when there is no reason to invite public traffic to them.