“We need a static IP” often turns out to mean several different things.
A shared outbound IP is used by multiple customers; a dedicated one is allocated for your use. Choose shared when an exclusive source address is unnecessary. Assess a dedicated address when the receiving service needs your organization’s own source identity. In either case, agree address stability separately and retain application authentication.
If customers need to connect to a server you run, that is an inbound requirement. Finish the sentence “We need this IP so that…” before comparing address options.
Compare address stability and exclusive use separately
A stable address stays consistent under the agreed service conditions. A dedicated address is allocated for your use rather than being shared with unrelated customers. An address can be one, both or neither.
For a scheduled job that calls a partner API, stability reduces configuration churn. The partner adds an address once, and your job keeps using it. If the partner’s allowlist is also meant to restrict access to your organization, exclusivity matters too: another customer sharing the same source address could satisfy that part of the check.
Ask about both properties. Also ask what the service considers a change: disabling a profile, moving to a different exit, ending a subscription or replacing a gateway. “Static” on a pricing page does not settle those lifecycle details.
Shared · changing
- Neither property assuredOther customers may use the address, and its value can change.
Shared · stable
- Predictable, not exclusiveUseful for consistency, but other customers can present the same source.
Dedicated · changing
- Exclusive, not retainedReserved for your use; replacement or lifecycle changes may change the IP.
Dedicated · stable
- Both properties agreedReserved identity retained under the explicit service terms.
Conceptual address properties, not offered plan combinations. Stable means retained under agreed conditions; dedicated means reserved for your use. Confirm allocation, replacement and retention terms separately.
When a shared outbound IP fits the job
If the job is simply to route internet traffic through a supported exit, an exclusive address may add nothing you need. A shared exit can serve that purpose without reserving an address for each customer.
The practical trade-off is that other users’ traffic can affect how external services treat the address. An address might acquire a poor reputation, trigger additional checks or be blocked. A dedicated address gives you more control over the traffic associated with it, though a history from a previous assignment or a provider’s own rules can still matter.
Neither option guarantees fewer CAPTCHAs, access to a particular bank or acceptance by a streaming platform. A dedicated address also does not become a residential address merely because one customer uses it. The receiving service makes its own decision.
Distinguish outbound identity from inbound reachability
When your device opens a connection to a provider, the provider sees a source address. That is the outbound side of the question.
When an external client opens a connection to your server, routing and inbound firewall rules must permit it. Knowing the source address of your outgoing traffic does not tell you whether anybody can initiate a connection back to you.
Fibmesh Outbound focuses on the exit and routing profile. Fibmesh Public IPs focuses on an address assignment to a supported device, gateway or routed subnet. Supported Public IPs arrangements can also supply an outgoing identity. Pick the delivery model that suits the deployment; the overlap does not mean every deployment needs both products.
See how Public IPs and Outbound overlap →Keep IP identity, anonymity and encryption separate
An IP address is only one piece of the information a service sees. A signed-in account, browser cookies and the application’s own identifiers may be more useful for recognizing you. A shared exit does not erase those signals. A dedicated exit gives your traffic a more consistent network identity, which can be useful operationally and undesirable if anonymity is your goal.
Treat encryption as a separate question too. Fibmesh currently uses WireGuard for supported tunnel connections. The tunnel protects traffic between its peers. Beyond the exit, use HTTPS, SSH or the appropriate application encryption; the public IP itself adds no encryption. The WireGuard overview explains the tunnel’s packet transport and peer model.
Compare a partner integration and a public application
Take an accounting integration that submits a file every evening. The receiving system accepts only approved source addresses. The job needs a predictable exit, clear address-retention terms and a tested recovery procedure. A supported stable, dedicated identity may be a good fit. If you use Fibmesh Outbound, allow for its current full-tunnel scope rather than assuming only that integration is rerouted. One egress profile is active per organization, so coordinate changes with other affected workloads.
Now take a small web application customers must open from their browsers. Reserving an outbound IP does not solve the inbound publishing job. A service-specific public link may be the better starting point, or a public address assignment if the deployment requires direct network reachability.
You can reduce most address conversations to four questions: who starts the connection, which address must the other side see, whether other customers may share it, and how long you need to keep it. Answer those before comparing plans. It saves buying the right-sounding IP for the wrong direction of traffic.
