Skip to main content
Every outbound destination the platform can generate, on one page, so a firewall or proxy allowlist can be written from this page alone rather than assembled from prose. The policy that governs this traffic, deny by default behind a hostname allowlist, is in Security assurance; how each route is set up is in Connectivity implementation. Two reading notes:
  • “Install-time” versus “runtime” is the column that matters for review. A self-hosted install needs the install-time rows only while installing or upgrading; at runtime the only Galtea-side traffic is the registry token refresh, and everything else goes to endpoints you own or chose. This is checkable: grep the values files of the package you receive for outbound hostnames, and the registry endpoint is the only Galtea-side address in them.
  • Hostnames written as <placeholder> are values specific to your deployment: Galtea issues the registry account and the <tenant> name, and the provider, product, storage and SMTP hosts are yours.

The tables

Where each destination is

What each destination carries

What is deliberately absent

  • No telemetry endpoint. There is no analytics, usage or tracing destination pointing at Galtea. Tracing, if you enable it, targets a collector inside your own cluster. See Model 5: Self-hosted.
  • No license or activation callback. The deployment needs no online activation and no continuous connectivity to Galtea.
  • The database is not in these tables because it is reached inside your network, not over the internet: allow the cluster’s node subnet through its firewall per Prerequisites checklist.
Air-gapped installs remove the registry and chart rows by mirroring images and charts into your internal registry, by agreement: see Installation and lifecycle.