Skip to main content
Network requirements vary by deployment model. Use this page to prepare firewall rules, DNS, TLS, private connectivity, and egress policy.

​
Public endpoints

Hosted deployments use hiloop-managed hostnames. BYOC, hybrid, and on-prem deployments may use custom hostnames.

​
Internal dependencies

​
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: 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.

​
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.

​
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 <api-pod> -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.