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.”
01 · Initiator, identity, scope
Compare the direction and scope
Five requirements, four product directions. Scroll the comparison horizontally when needed.
| 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.
02 · Read the requirement
Look at the provider’s rule
The provider checks your request
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.
The client reaches your service
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.
03 · Choose the traffic scope
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.
Selected destinations
Public IPs · appropriate selected outgoing mode
Full internet routing
Outbound · current full-tunnel profile model
Public IPs · separately selected full routing mode
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.
04 · Keep the return path
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.
Unrelated outgoing connections can still use the local 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 →05 · Take a useful brief forward
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.
06 · Choose your next reading
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 →