Which Parts of a Self-Hosted Application Need Internet Access? An Exposure Mapping Checklist

Why “publicly accessible” is not a complete deployment requirement

“The app needs to be public” can mean several very different things. It might mean anyone should be able to load a website, only named employees should be able to sign in from anywhere, a partner system must deliver webhooks, or the application merely needs to call an external API. These requirements result in different network exposure decisions.

Treat inbound reachability and outbound connectivity as separate decisions. In Docker networking, a container can make outgoing connections when its host has Internet access, while a container port is not normally reachable from outside the host unless it is deliberately published or routed. An application can therefore need Internet access without needing a publicly reachable application port.

The goal is not to make every component private or every component public. The goal is to explicitly authorize each data flow, expose only the required entry points, and record why each one exists. This aligns with the NIST Cybersecurity Framework 2.0 outcome for maintaining representations of authorized internal and external network communication and data flows.

• Replace “public” with a specific statement: who connects, from where, to which hostname, using which protocol, and for what purpose.
• Separate browser access, machine-to-machine inbound requests, outbound calls and administrator access.
• Decide whether each flow is public Internet, limited to known IP addresses, private-network-only or not permitted.
• Record the data exchanged on each flow, especially credentials, personal data, customer records, files and API tokens.

Start with an exposure map: users, administrators, integrations and supporting services

An exposure map is a practical inventory of the application’s permitted communication paths. Build it before selecting domains, opening firewall rules or publishing container ports. It should cover more than the application’s main screen: supporting services, administrative tooling, identity systems, email providers and monitoring destinations can all create network dependencies.

Start by listing assets and actors. NIST CSF 2.0 treats software, services, systems, data and supplier services as assets that need to be identified and managed. For a self-hosted deployment, this means documenting both your own components and the external services they contact.

Then draw directional arrows. Every arrow should have an owner and a decision: allowed, restricted, private-only or rejected. This makes hidden assumptions visible early—for example, an automation workflow that must receive a vendor webhook, or an internal dashboard that was assumed to be reachable from every employee network.

• Users: public visitors, customers, staff, contractors, mobile users and service accounts.
• Administrators: application administrators, infrastructure administrators and support personnel.
• Inbound integrations: webhooks, API clients, identity-provider callbacks and partner systems.
• Outbound integrations: email delivery, identity providers, external APIs, software downloads, model downloads and monitoring destinations.
• Supporting services: databases, caches, queues, object storage, search services, reverse proxies and administrative dashboards.
• For every flow, capture source, destination, protocol and port, hostname, direction, authentication method, data classification, owner and business justification.

Classify inbound access: public web interface, authenticated users, partner endpoints and webhook receivers

Inbound access is what most teams mean by exposure, but it should be split into distinct classes. A public marketing or publishing interface has a different risk profile from an employee-only application. A webhook receiver may need to accept requests from an external system even when no human-facing interface should be broadly available.

Use the reverse proxy as the intentional inbound entry point. In Traefik’s model, entry points receive TCP or UDP traffic, routers match incoming requests, and services receive the routed backend traffic. This supports a design in which the proxy accepts only approved traffic while application containers remain behind it.

Where an endpoint is used only by known parties, document whether an IP-based rule is suitable in addition to application-level authentication. Traefik provides an IP allowlist mechanism that accepts or refuses requests before they reach a backend. This can reduce unnecessary exposure, but it depends on stable and correctly identified source addresses and should not be treated as a substitute for appropriate authentication.

• Public web interface: intended for unauthenticated visitors; expose only the required web routes and hostname.
• Authenticated user access: intended for customers or staff; define identity, login, session and access requirements in the application design.
• Partner API endpoint: define the partner, authentication method, expected source network, rate expectations and exact routes.
• Webhook receiver: define sender, signature or authentication validation, the route, expected payload data and failure handling.
• Administrative interface: classify separately from the main application; do not assume it belongs on the public hostname.
• Reject catch-all exposure: an externally reachable port or hostname should have a named purpose and owner.

Identify outbound dependencies before assuming the application can run privately

Private inbound access does not mean an application has no Internet dependency. Many business, automation and AI workloads need to initiate connections to services outside the host. These may include email delivery services, identity providers, third-party APIs, package sources, model downloads or monitoring destinations.

For each dependency, determine whether it is required at installation, at startup, on a schedule, or during normal user activity. This distinction matters for restricted environments. A one-time software or model download can be handled differently from an always-on connection to an identity provider or external business API.

Do not describe outbound access as a single blanket permission. Identify the destination hostname or service, the protocol, the operational purpose, the data sent and received, the credential used, and the fallback behavior when the destination is unavailable. Review the official documentation for the particular application and integration because dependencies vary by product and configuration.

• Email delivery: identify the provider, connection method, sender identity and whether the application needs to send password resets, notifications or workflow messages.
• Identity provider: identify authentication endpoints, token endpoints, issuer details and whether login stops working when the provider cannot be reached.
• External APIs: list each provider separately, the data exchanged, credential storage approach and whether calls are user-triggered or automated.
• Package, plugin or model downloads: establish whether Internet access is needed only during setup or updates, or routinely at runtime.
• Monitoring and error reporting: establish what telemetry or event data leaves the environment and who approves that transfer.
• Update checks and license-related calls: verify these directly in official vendor documentation rather than assuming they are required or absent.

Keep data services private by default

A database, cache, queue, object store or search service is usually a supporting component, not an Internet-facing product. Start from private-only access and add a route only when there is a documented operational reason. In a Docker bridge configuration, services connected to the host or the same network can communicate as configured, while container ports are not accessible from outside the host by default unless published or otherwise deliberately routed.

Be especially careful with convenience publishing. Docker documents that publishing a port without specifying a host address binds it to all host addresses by default, which can make the service reachable externally. If a service is intended only for the local host in the documented NAT-mode scenario, binding to loopback is a way to prevent remote hosts from accessing that published port.

Administrative control planes deserve the same private-by-default treatment. Traefik warns that its production API and dashboard can expose configuration elements, including sensitive data, and recommends restricting its API port to internal networks. Apply this principle to application administration interfaces, container management interfaces and observability tools as well.

• Databases: permit access only from the application components and approved maintenance paths.
• Caches and queues: keep them on private networks; do not expose them merely to simplify troubleshooting.
• Object storage and internal file services: define which application components require access and how backups interact with them.
• Search, vector and AI support services: document whether they are internal backends or deliberate APIs for other systems.
• Proxy dashboards, application admin panels and infrastructure control planes: use separate, restricted access paths.
• Before launch, review every published port and confirm its host binding, intended clients and owner.

Check common edge cases that change the access design

Several deployment details are easy to discover late, after a hostname or firewall policy has already been chosen. Address them early because they can determine whether a public hostname, stable callback path or particular network source is required.

OAuth is a key example. Redirect and callback URLs are deployment requirements, not cosmetic settings. RFC 9700 requires authorization servers to use exact string matching against pre-registered redirect URIs, apart from the specified localhost handling for native apps. A changed scheme, hostname, path or trailing slash can therefore break login.

Secure the callback path itself. RFC 9700 warns that redirect-URI endpoints must not act as open redirectors. It also identifies a risk when OAuth response-handling pages link to attacker-controlled pages or load third-party content that could disclose the authorization response URL through the Referer header. Keep callback handling intentionally narrow and avoid unnecessary embedded third-party content on that page.

• OAuth and SSO: confirm the exact external URL, protocol, hostname and callback path that must be registered with the identity provider.
• Embedded content: identify iframes, scripts, images or widgets that connect to third parties, particularly on authentication response pages.
• Mobile and desktop clients: confirm whether they require a public endpoint, a fixed hostname, localhost handling or a private-network path.
• IP allowlists: validate the real source addresses after intermediaries, NAT, content delivery networks or partner infrastructure are considered.
• Inbound email or file transfers: determine whether they are delivered directly to the application or retrieved outbound from another service.
• WebSockets, streaming and long-lived connections: verify proxy and application requirements in official documentation rather than assuming ordinary HTTP defaults are sufficient.

Questions to verify in official application documentation before deployment

Application documentation is the authority for product-specific requirements. Do not infer that an application supports a private deployment, a particular proxy behavior, an SSO provider or a webhook pattern solely because another application does. Confirm requirements against the official documentation for the version and configuration you plan to use.

The answers should be captured in the exposure map and revisited when integrations change. If documentation leaves a question unresolved, treat it as an implementation risk rather than filling the gap with an assumption.

This verification is especially important for applications that combine a web interface with background workers, automation engines, AI model services or multiple supporting containers. The visible browser interface is often only one part of the operational design.

• Which inbound ports and protocols are required, if any, and which component terminates TLS?
• Can the application operate behind a reverse proxy, and does it require trusted-proxy or external-URL settings?
• What canonical or base URL does the application require?
• Which routes must receive webhooks, OAuth callbacks, SSO assertions or partner API requests?
• Which outbound hostnames or service categories are required for normal operation, setup, updates, email, identity, monitoring or optional integrations?
• Which data services are required, and should their ports remain private?
• Are separate worker processes or containers required, and what do they need to reach?
• What backup data, storage locations and restoration steps are required? Airbip provides configurable daily, weekly and monthly backups, but the application owner still needs to decide what data belongs in scope and test restoration procedures appropriate to their environment.

Fit domains, TLS and reverse proxies into the design without exposing unnecessary services

Choose domains after identifying the intended entry points. A hostname should represent a deliberate access purpose, such as a user-facing application, a narrowly scoped webhook endpoint or an administration path with additional restrictions. Avoid creating public DNS names for internal services simply because they are convenient to remember.

TLS certificate validation is also part of the exposure design. With Let’s Encrypt HTTP-01 validation, the certificate authority retrieves a challenge file at the hostname, and the HTTP-01 challenge is limited to port 80. That can be appropriate for a public web endpoint, but it is a concrete reachability requirement to plan for. Let’s Encrypt DNS-01 validation can validate names whose web servers are not exposed to the public Internet, because validation occurs through a DNS TXT record.

A reverse proxy lets a team make the proxy—not each application component—the selected public edge. It can route approved hostnames and paths to backend services while backend ports remain private. This does not automatically make an architecture secure; the team still needs correct application configuration, access controls, DNS ownership, certificate renewal and change control.

Airbip deploys catalog applications as Docker workloads on Airbip cloud servers and automates routing and TLS certificates through Traefik and Let’s Encrypt. Customers can use an Airbip subdomain or a compatible custom domain. These capabilities are useful when the documented design calls for a managed public application endpoint, but they do not remove the need to decide which routes and data flows are approved.

• Assign one owner for each DNS zone and hostname.
• Document whether certificate validation uses a public HTTP path or DNS validation, based on the access design.
• Expose the reverse proxy entry points required by the approved public services; keep backend service ports private.
• Use separate hostnames or carefully scoped routes when public and restricted functions cannot be cleanly separated inside the application.
• Test the externally visible result from outside the server network, not only from the host itself.
• Review certificate renewal and DNS-change responsibilities as part of operational ownership.