> ## Documentation Index > Fetch the complete documentation index at: https://docs.hiloop.ai/llms.txt > Use this file to discover all available pages before exploring further. # Network requirements > Plan ingress, egress, DNS, TLS, and private connectivity for hiloop deployments. Network requirements vary by deployment model. Use this page to prepare firewall rules, DNS, TLS, private connectivity, and egress policy. ## Public endpoints | Endpoint | Purpose | Protocol | | -------------- | -------------------------- | ---------- | | API host | REST control plane | HTTPS | | Telemetry host | Telemetry ingest and query | HTTPS/gRPC | | Web host | Web console | HTTPS | Hosted deployments use hiloop-managed hostnames. BYOC, hybrid, and on-prem deployments may use custom hostnames. ## Internal dependencies | Dependency | Purpose | | -------------------- | ---------------------------------------------------- | | PostgreSQL | Metadata and organization-scoped control-plane data. | | Object storage | Workspace data, event payloads, and export bundles. | | Container registry | hiloop service images and workload images. | | Identity provider | Session and SSO flows where configured. | | DNS and certificates | Service discovery and TLS. | ## Platform egress (the hiloop services themselves) Separate from what *sandboxes* reach, the hiloop control-plane services have their own outbound dependencies. On-prem these are all destinations **inside your environment**, with one default exception: the supported posture forwards a fixed platform-health metrics contract to hiloop support, and air-gapped deployments turn that off (below). Plan connectivity from the service namespace to: | Destination | Which services need it | Notes | | ----------------------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | | PostgreSQL | Control-plane API, migration job | Metadata and organization-scoped records. | | Object storage | Control-plane API, telemetry gateway, workspace daemon | Workspace data, event payloads, export bundles. | | Identity provider / JWKS | Edge authorization | Session and SSO verification; the JWKS endpoint you configure. | | Container registry | All pods (image pulls) | Your mirror on-prem — see below. | | In-cluster DNS | All services | Service discovery. | | Observability backend | All services | OTLP export to a collector you operate (or console-only if unset). | | `https://telemetry.hiloop.ai` | Platform observability collector | Supported on-prem posture only: the fixed platform-health metrics contract, nothing else. Air-gapped deployments disable it. | hiloop emits its own operational telemetry over OTLP to a collector **you** point it at, and the full platform lane stays in your deployment's local store. In the supported posture that collector also forwards the fixed health-metrics contract to hiloop support — never workload data, event payloads, or customer telemetry. Setting `supportTelemetry.enabled=false` removes the external endpoint, exporter, and pipeline entirely. See [hosted and self-managed](/concepts/architecture#hosted-and-self-managed). ### Air-gapped / none On-prem deployments can run with **no platform outbound internet at all**. When your identity provider, PostgreSQL, object storage, container registry, and observability backend are all reachable inside the environment, the platform services need no egress beyond the cluster. To achieve this: * **Mirror images and charts** into a registry reachable from the cluster before install, and pin the mirrored digests in your values. Images are digest-pinned and signed, so a mirror is verifiable. * **Host the identity provider / JWKS** inside the environment (or a reachable private endpoint). * **Point observability** at an in-cluster or customer-approved collector. * **Disable support telemetry** (`supportTelemetry.enabled=false`) so the platform collector renders with no external endpoint or exporter. In this mode, sandbox egress remains subject to the fixed network floor below. The current sandbox surface does not offer a no-egress or destination-filtered posture. ## Sandbox egress Every sandbox has the same deployment-wide posture: cluster DNS, the public internet, and the API's dedicated proof-authenticated capture listener are reachable, while other sandboxes, all other cluster services, private and link-local ranges, and the cloud metadata endpoint are denied outside the guest. Workload code has no capture proof. There are no create-time network flags, per-sandbox whole modes, or domain/CIDR destination lists. Plan whether workloads may safely reach: * public model APIs; * package registries; * source repositories; * internal services; * customer object storage; * telemetry endpoints. If a workload requires a narrower boundary, enforce it in deployment-owned infrastructure or do not run that workload yet. See [network egress](/sandboxes/network-egress). ## Private connectivity For BYOC, hybrid, and on-prem deployments, plan: * VPC/VNet peering or private links; * DNS forwarding; * proxy and firewall rules; * certificate trust roots; * audit requirements for cross-boundary traffic. ## Verify it yourself * **Platform egress is bounded.** With the platform running air-gapped, confirm no service pod has a route to the public internet: `kubectl exec -n hiloop -- sh -c 'curl -sS --max-time 5 https://example.com'` should fail. Only your configured backing stores, IdP, registry mirror, and collector are reachable. * **The fixed sandbox floor is enforced.** From inside a sandbox, a public HTTPS request should succeed, while requests to another sandbox, a cluster service, a private or link-local address, and the cloud metadata endpoint must fail. See the [threat model](/deployment/threat-model#verification-gates).