# Customer-managed egress Customer-managed egress gives Confluence admins control over which external domains the app can contact on their behalf. Instead of the app reaching out to any internet destination, admins explicitly allow trusted domains. This creates a clearer security boundary while still enabling useful integrations and richer page experiences. ℹ️ **In simple terms:** admins decide which domains are trusted, and the app only uses those approved destinations for supported external content and features. # Why this exists Many Confluence use cases depend on content that lives outside Confluence itself: videos, internal tools, image libraries, dashboards, raw files, diagram assets, and other embeddable or fetchable resources. Customer-managed egress makes those connections intentional and reviewable. This model is especially useful for organizations that want tighter control over outbound connections without giving up functionality. # What admins can do with it By allowing specific domains, Confluence admins can unlock several capabilities in a controlled way. * **Allow iframes to be embedded from approved domains** Admins can permit trusted sites to be used in embeds, such as videos, internal tools, dashboards, forms, prototypes, and other embeddable web content. * **Speed up loading of externally hosted images and related operations** When the app is allowed to fetch assets from trusted domains, pages can render external images and similar resources more efficiently than relying on manual workarounds or indirect access patterns. * **Enable advanced features that depend on external resources** This can include capabilities like custom diagram rendering, where the app needs to retrieve supported source files, assets, or related content from approved locations. ℹ️ **Best practice:** allow only domains you trust and actually need. Use the narrowest scope possible so access remains easy to audit and maintain. # How it works 1. An admin identifies a domain that should be trusted. 2. The admin adds that domain to the app’s approved list. 3. The app can then use that domain for supported operations, such as embedding, fetching assets, or powering external-content features. 4. If a domain is not approved, those operations remain blocked or unavailable. This approach keeps control with the customer rather than hard-coding broad internet access into the app. ![image-20260723-083936.png](https://help.gocapable.com/images/7833cc92-33db-40ac-82dc-5e0139981a35.webp) # Common examples | **Use case** | **What the approved domain enables** | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Embedded training video** | Lets authors place iframe-based video content directly in a Confluence page from a trusted video host. | | **External image host or CDN** | Allows the app to retrieve images faster and support image-dependent page rendering or transformations.If you commonly use a specific domain to load images or other resources, adding the domain to the allowlist can speed loading up substancially. | | **Internal diagram or source endpoint** | Supports enhanced features such as custom diagram rendering based on approved external sources. | # Important limitations Approving a domain allows the app to attempt supported operations against that destination, but it does not override the source system’s own security rules. * If a website blocks iframe embedding through browser security headers, it still will not render in an iframe. * If the source requires authentication, viewers may still need permission to access it. * If the remote service is slow or unavailable, the Confluence experience may also be affected. 📝 **Important:** allowlisting a domain does not guarantee every URL on that domain will work. The source must also support the specific operation, such as iframe display or remote asset retrieval. # Security and governance benefits * **Least-privilege access:** only approved domains are reachable for supported features. * **Better reviewability:** admins can see and manage which external services are in use. * **Reduced risk:** teams avoid broad, uncontrolled outbound access. * **Operational flexibility:** admins can add new trusted domains as needs evolve. # When to use it Customer-managed egress is a good fit when your teams want rich external integrations in Confluence, but your organization also wants admins to stay in control of which external domains the app can use. It is particularly helpful for organizations embedding internal tools, referencing externally hosted assets, or enabling advanced capabilities that depend on approved third-party or company-managed endpoints. FAQ: Does approving a domain mean any content from that domain will always work? No. The domain may be approved, but the remote site must still permit the requested behavior. For example, iframe embeds can still fail if the site sends frame-blocking headers, and protected resources may still require authentication. FAQ: Should admins approve broad domains or specific trusted ones? Specific trusted domains are better. A narrower allowlist is easier to govern, reduces unnecessary exposure, and better aligns with security best practices. FAQ: What kinds of features commonly depend on approved external domains? Typical examples include iframe embeds, externally hosted images or assets, and advanced app features such as custom diagram rendering that rely on remote sources. # References * [Embed macro](https://innovator.atlassian.net/wiki/spaces/MFC/pages/1303347256)