Does Your Self-Hosted Application Need a Stable Outbound IP? An Egress Allowlisting Checklist
A custom domain and HTTPS make an application reachable from the internet, but they do not establish the source address that external services see when the application connects out. Use this checklist to find egress dependencies, test whether IP allowlisting is necessary, and plan safe changes.
Start with the right question: inbound reachability is not outbound identity
A stable outbound IP is an internet-routable source IP address that a destination consistently sees when your application initiates a connection. It matters when that destination permits connections only from pre-approved source addresses, commonly called source-IP allowlisting or egress allowlisting.
This is separate from how people reach your application. A custom domain identifies where users send inbound requests. TLS certificates protect those inbound connections and validate control of the names on the certificate. A reverse proxy router, such as Traefik, receives incoming requests, applies configured routing rules, and forwards matched requests to a service. None of those functions, by themselves, prove what source address a third-party API, database, or partner endpoint will see for traffic leaving the application.
For Airbip deployments, applications run as Docker workloads on Airbip cloud servers, while routing and TLS certificates are automated through Traefik and Let’s Encrypt. Those are valuable inbound-access capabilities, but they should not be treated as a promise of fixed outbound addressing. Establish outbound requirements separately and obtain provider-specific evidence before relying on an IP allowlist.
- Inbound question: which domain, port, route, and TLS configuration let users or webhooks reach the application?
- Outbound question: which source IPv4 and IPv6 addresses does each destination observe when the application, a worker, or an administration process connects out?
- Control question: is source-IP allowlisting a mandatory receiving-side policy, or simply one option among stronger or easier-to-maintain controls?
Find every connection that may depend on source-IP allowlisting
Do not limit the review to the application’s primary user-facing function. Egress often occurs in scheduled jobs, queue workers, import/export tools, monitoring integrations, update checks, backup-related workflows, and administrator access paths. A deployment can appear healthy in an interactive test while an asynchronous worker fails later because it uses a different process or network path.
Start with systems that are known to restrict client network addresses. Typical candidates include third-party APIs, managed databases, payment or finance systems, private partner endpoints, internal corporate networks, monitoring systems, management tools, remote-access services, and SSH administration. Regardless of allowlisting, outbound connections handling sensitive or operationally important traffic should use encrypted protocols such as TLS where applicable; OWASP ASVS explicitly includes external APIs, databases, partner systems, monitoring, management tools, remote access, and SSH in its service-to-service communication guidance.
Classify each connection by business consequence, not just by technical protocol. An optional analytics call has a different failure effect from a payment action, finance export, customer-data sync, or connection to a private internal system.
- Interactive application calls made while a user is active
- Scheduled jobs, cron-like tasks, and report generation
- Queue consumers, workers, and automation flows
- Webhooks, callbacks, and API calls to SaaS services
- Database, file-transfer, and private-network connections
- Monitoring, alerting, logging, administrative, and remote-access connections
- Migration, recovery, and failover procedures that may create traffic from a different environment
Create an egress dependency inventory before deployment
Treat egress dependencies as a maintained system inventory, not a one-time spreadsheet. NIST SP 800-53’s component-inventory control emphasizes accurate documentation, accountability information, and regular review. Apply the same discipline to external destinations: an allowlist rule that nobody owns or reviews becomes a predictable outage risk.
Record one row for each destination and traffic path. If an application server and a background worker call the same API through different paths, record them separately until you have evidence that their observed source addresses are the same. Include both address families: an IPv4 result does not establish IPv6 behavior.
Ask the destination owner to state its actual acceptance rule. “Our firewall uses an allowlist” is incomplete. You need to know whether it evaluates IPv4, IPv6, a specific port and protocol, an IP range, a private connection, or a combination of network and application-layer controls.
- Destination: hostname, service name, environment, and receiving organization
- Traffic path: application process, worker, scheduler, administration host, or recovery procedure
- Protocol and port: for example, HTTPS, database TLS, SFTP, or SSH
- Authentication: API credential, signed request, client certificate, user credential, or other documented method
- Data exchanged: classification, direction, and sensitivity
- Observed source identity: confirmed IPv4 and IPv6 addresses, or marked unverified
- Allowlist requirement: mandatory, optional, unknown, or not supported
- Failure effect: degraded feature, delayed workflow, failed transaction, data-sync gap, or operational lockout","Owner and escalation path: who can change the sending side and who can change the receiving-side rule","Change notification: how each side communicates address, network, migration, or policy changes","Evidence date: when the path and observed source identity were last tested"],
Test whether an IP allowlist is truly required
Source-IP allowlisting can be a useful additional restriction, especially where a receiving service has limited access-control options. It is not, however, proof of workload identity. Network translation can cause multiple workloads to appear under one external address, while failover, migration, or changed routing can alter the address a destination sees. NIST’s zero-trust guidance shifts emphasis away from implicit trust based only on network location and toward explicit authentication and authorization of subjects and devices; its cloud-native guidance similarly emphasizes application and service identities while allowing network parameters as additional inputs.
Ask the receiving service which controls it supports and which it considers authoritative. Prefer a layered design: encrypted transport, strong authentication and authorization, narrowly scoped credentials, and an IP restriction only where it adds a meaningful independent barrier or remains a contractual requirement.
Mutual TLS is a particularly strong option when supported and operated well. OWASP ASVS identifies TLS client authentication, backed by public-key infrastructure and replay-resistant mechanisms, as a strong way to verify endpoints in intra-service communication. Other possible patterns depend on the receiving service: short-lived credentials, signed requests, private connectivity, or an identity-aware access model. Do not claim equivalence without checking the destination’s documentation and governance requirements.
- Is the IP rule mandated by the destination, a customer policy, a contract, or merely historical practice?
- Can the destination use mutual TLS, short-lived credentials, signed requests, or private connectivity instead?
- Can credentials be scoped to the minimum actions, data, and environment?
- Is TLS enabled and certificate validation correctly configured for the connection?
- Would an IP rule be an additional safeguard rather than the only control?
- Can the chosen method be rotated, audited, and tested without a long outage window?
Understand the architecture behind outbound identity
Outbound identity is a property of the full traffic path, not of an application URL. In traditional network address translation, a private address can be bound to an external address when an outgoing session starts, and the packet source can be translated to a globally unique address. In Docker bridge networking on Linux, Docker documents NAT and masquerading rules for container traffic. Docker also distinguishes this outbound masquerading from published ports, which are primarily about allowing remote hosts to reach containers through host addresses.
That distinction matters in containerized deployments. The address that accepts inbound traffic on a published port, or the domain that routes through a reverse proxy, may not be the address a remote destination observes for container egress. A provider can only make a meaningful statement about outbound identity by defining the relevant workloads, address family, routes, and failure or migration behavior.
Dual-stack environments need explicit testing. IPv6 source and destination selection has its own rules, and destination selection may prefer IPv6 or IPv4 depending on available source addresses. An IPv4-only allowlist therefore does not establish that a client will use IPv4. If the destination publishes IPv6 connectivity, test what your workload actually does and ensure the destination’s policy covers the selected path.
- NAT and masquerading: which address is translated, and where in the path does translation occur?
- Container-to-host egress: do application containers, workers, and maintenance tasks share a path?
- IPv4 and IPv6: which family is selected for each destination, and is it allowlisted?
- Multiple instances: can replicas, workers, or separate services have different egress identities?
- Failover and migration: what will the destination see after replacement, restoration, or relocation?
- Provider-managed network changes: are potential address changes documented and communicated?
Ask infrastructure providers precise, evidence-based questions
Avoid asking only, “Do you have a static IP?” The answer can be misleading unless it names the traffic direction and scope. Request written answers tied to your intended workload and the destinations that require restrictions. A provider may document an inbound server address without making any commitment about all outbound traffic paths.
Airbip is designed to make self-hosted business and AI applications practical by handling surrounding cloud infrastructure, including Docker-based application workloads, routing, TLS automation, DNS checks, lifecycle management, and configurable backups. If your deployment has a hard stable-egress requirement, confirm that requirement with Airbip before deployment rather than inferring it from a custom domain, a public application address, or inbound proxy behavior. If a fixed, customer-controlled egress design is non-negotiable and cannot be evidenced for the required path, choose an infrastructure model that can meet and document it.
Keep provider responses with your dependency inventory. The useful outcome is not a vague assurance; it is a testable operational statement describing the observed addresses, covered paths, change conditions, and notification process.
- Which outbound IPv4 and IPv6 addresses will each specified workload and process use?
- Are those addresses documented as stable, or may they change? Under what events?
- Which traffic is covered: application container, worker, scheduler, maintenance process, backups, administrative access, and recovery environment?
- Does the statement cover normal operation only, or also failover, migration, rebuild, and restore?
- What notice is given before a relevant egress-address change, and through which channel?
- Can the provider supply a safe test method or evidence for the live path?
- Who owns support and coordination if a destination rejects the observed source address?
Plan allowlist changes as a controlled release
An allowlist update spans two control planes: the sender’s real traffic path and the receiver’s acceptance policy. Coordinate both owners, choose a low-risk change window, and define success using an actual authenticated connection rather than a DNS lookup or browser test. A browser reaching your application only confirms inbound access.
Where the receiving service permits it, temporarily allow both the old and new exact addresses. This overlap gives you a verification window and supports rollback if the new path fails. Remove the old entry promptly after the agreed validation period. Do not compensate for uncertainty by allowlisting overly broad public ranges; that weakens the boundary and makes later review harder.
For every change, capture the tested destination, protocol, address family, observed source address, timestamp, and application function. Verify background work as well as an interactive request. Then update the inventory and ensure each side knows who removes temporary rules.
- Name a change owner, receiving-side owner, approver, and rollback owner.
- Confirm the exact destination hostname or endpoint, protocol, port, and environment.
- Obtain the proposed source IPv4 and IPv6 addresses from evidence, not assumption.
- Add a temporary exact-address overlap if the receiving service supports it.
- Test an authenticated, representative transaction from every relevant process.
- Check logs and destination-side evidence for the source address actually observed.
- Set a deadline to remove the old entry and record confirmation.
- Retain an emergency contact path for a rejected connection or rollback.
Prepare for the failure modes that surprise teams
A destination rejecting a changed source address is the most visible failure, but it is not the only one. The common pattern is incomplete scope: the team validated a web request, while a worker, scheduler, or recovery procedure took another route. Design tests around business workflows and operational events, not one successful curl command.
An IPv6 path can also bypass an IPv4-only rule if the client and destination select IPv6. Conversely, an IPv4-only test can conceal a destination that has no usable IPv6 policy. Include both families in the pre-deployment test plan, and document a deliberate decision if one family is disabled or unsupported for a specific connection.
Migration, rebuild, restoration, and failover deserve the same review as initial deployment. If any of these can create a new egress identity, the receiving-side allowlist must be ready before the event or the service must have a tested emergency update path. If downtime or strict external allowlisting cannot tolerate that uncertainty, a different network architecture or hosting model may be the responsible choice.
- Changed source address: activate the overlap rule or rollback, then confirm the source address at the destination.
- Different worker path: test each worker and scheduled task separately; do not rely on the web process result.
- IPv6 bypass: inspect destination resolution and connection logs; add the correct IPv6 rule or enforce the intended supported path.
- Unexpected migration identity: pause dependent workflows where safe, apply the pre-approved change process, and run representative verification.
- Unowned rule: assign a service owner and a receiving-side contact before the next change window.
- Broad emergency range proposed: treat it as a time-bound exception requiring explicit approval and a removal date.
Frequently asked questions
Does a custom domain give my self-hosted application a stable outbound IP?
No. A custom domain is part of inbound naming and routing. It does not establish the source IP address that external services see when the application initiates outbound connections.
Does a reverse proxy or TLS certificate determine outbound egress identity?
No. Reverse proxies such as Traefik route incoming requests to services, and TLS certificates validate control of domain names and protect connections. Outbound source identity depends on the egress network path, including routing and address translation.
Why might a Docker container have a different outbound identity from the application’s public URL?
Inbound port publishing and outbound masquerading are separate networking functions. Docker documents NAT rules for both port mapping and masquerading, so the address used for inbound access should not be assumed to be the address seen by an outbound destination.
Should we use IP allowlisting instead of strong authentication?
Usually, treat IP allowlisting as an additional restriction rather than the sole trust decision. Where supported, evaluate encrypted transport, scoped credentials, signed requests, mutual TLS, private connectivity, or identity-aware controls. The right choice depends on the receiving service and your governance requirements.
Do we need to review IPv6 for outbound allowlisting?
Yes, in a dual-stack environment. A destination may be reached over IPv6 or IPv4 depending on available addresses and selection behavior. Test the actual connection path and ensure the receiving service’s rules cover the address family in use.
What should we ask Airbip before deploying an application with a strict egress allowlist?
Ask for evidence about the outbound IPv4 and IPv6 addresses for the specific workloads and processes involved, whether they can change, which traffic paths are covered, what happens during migration or recovery, and how relevant changes are communicated. Do not infer fixed egress behavior from an Airbip subdomain, custom domain, routing, or TLS setup.
Sources and further reading
- Packet filtering and firewalls — Docker
- Docker with iptables — Docker
- HTTP Router — Traefik Labs
- Challenge Types — Let’s Encrypt / Internet Security Research Group
- RFC 3022: Traditional IP Network Address Translator — IETF / RFC Editor
- RFC 6724: Default Address Selection for IPv6 — IETF / RFC Editor
- Application Security Verification Standard: General Service-to-Service Communication Security — OWASP
- SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments — NIST
- SP 800-207: Zero Trust Architecture — NIST
- SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations — NIST