Start by identifying who initiates the request. Then ask which public identity matters and how much traffic should change. These three questions separate requirements that often get bundled under “an IP.”
Compare the direction and scope
| Requirement | Initiator | Relevant identity | Product direction |
|---|---|---|---|
| A visitor opens your app | External visitor | Your public entry point | Publish |
| A client reaches a device or gateway | External client | Assigned public address | Public IPs |
| Your worker calls an allowlisted API | Your workload | Its agreed outgoing source | Outbound or Public IPs |
| Your laptop uses a chosen internet path | Your endpoint | The selected gateway path | Outbound |
| Your colleague reaches an internal tool | Approved teammate | Private workspace identity | Networks |
Publish is available with assisted setup. Its row describes the application path; confirm the connector and target before activation.
Look at the provider’s rule
If an external API checks the source of your request, publishing your app will not satisfy that allowlist. Assess the outgoing source and keep credentials and application permissions separate.
If an external client needs to initiate a request to your service, an outbound identity alone does not create an inbound path. Assess the selected public target and its firewall or application publication rule.
Change only the traffic that needs changing
A provider allowlist can be met by an agreed stable Outbound exit or a Public IP assignment with an appropriate routing mode. The current Outbound profile model uses full-tunnel routing. Public IPs separately supports selected outgoing destinations as well as full internet routing. Check platform, DNS, disruption and restoration implications before choosing.
One device can have both an inbound public target and outgoing traffic through its local ISP. Do not infer one mode from the presence of the other.
Replies are part of the connection
“Inbound access” describes who starts the conversation. It does not mean replies travel through the ordinary ISP. A service reached through Fibmesh needs its replies to follow the configured Fibmesh return path. Unrelated outgoing connections can still use the ISP.
For selected outbound, both the route and source address must match the intended destination. An outbound-only configuration also needs explicit inbound-deny rules; naming a preset does not create that firewall policy.
Compare selected destinations with full-tunnel Outbound →Record an evaluation brief
Write down the initiating party, destination, source identity the destination expects, required protocol and affected traffic scope. Add the owner who can approve and remove the change. Verify the relevant release, allocation and market before translating the brief into setup.
Use Publish for an application-specific endpoint, Public IPs for assigned addresses with incoming and outgoing traffic options, or Outbound for internet routing and source identity. Networks covers approved private access.
Start with the sentence that describes your job.
Someone needs to open my application.
The request starts outside your resource. Assess a selected HTTP publication or an advanced public target, then define its authentication and exposure.
Compare web URLs and public IPs →My worker calls an API that checks its source IP.
The request starts in your workload. The provider sees the outgoing source. An agreed Outbound exit or a Public IP assignment can supply that source. Choose by delivery and traffic scope, then coordinate the provider’s allowlist.
Explore outgoing identity →I want the laptop’s general internet path to change.
The scope is the default internet path, not one provider call. Assess supported Outbound behaviour, DNS, interruption and restoration.
Explore default routing →A colleague needs an internal resource.
The audience is an approved workspace member. Use the private membership model and keep the application’s own login and roles.
Explore private access →