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

# Deployment models

> Compare hosted, hybrid, BYOC, and on-prem / air-gapped — what each one owns and when to choose it.

hiloop runs the same product across four deployment models. What changes is infrastructure
ownership, where data lives, who operates the stack, and the network boundary. Start from the
[decision matrix](/deployment/overview), then use the per-model detail below.

| Model                                           | Operated by                   | Data plane                                               | Best fit                                                |
| ----------------------------------------------- | ----------------------------- | -------------------------------------------------------- | ------------------------------------------------------- |
| [Hosted SaaS](#hosted-saas)                     | hiloop                        | hiloop-managed                                           | Fast evaluation and managed operations.                 |
| [Hybrid](#hybrid)                               | Shared                        | Customer-owned payload storage for selected data classes | Managed operations with stricter data placement.        |
| [BYOC](#byoc)                                   | hiloop-operated control plane | Customer cloud account                                   | Data plane in your account without full self-operation. |
| [On-prem / air-gapped](#on-prem-and-air-gapped) | Customer                      | Customer environment                                     | Strict locality, air-gap, or full operational control.  |

Whichever you choose, the product contract is the same: API keys or sessions authenticate requests,
the edge resolves identity before backend services handle the request, APIs are organization-scoped,
telemetry uses trusted run identity, and runtime capabilities are discovered through the API rather
than assumed from the deployment model.

## Hosted SaaS

The managed hiloop deployment, operated by hiloop. Use it for the fastest path to telemetry capture,
query, branch comparison, and runtime workflows without operating Kubernetes, databases, object
storage, or the web/API control plane.

| Layer                       | Responsibility |
| --------------------------- | -------------- |
| API edge and authorization  | hiloop         |
| Control-plane API           | hiloop         |
| Telemetry gateway           | hiloop         |
| Web console                 | hiloop         |
| Database and object storage | hiloop         |
| Upgrades and maintenance    | hiloop         |

You remain responsible for managing API keys and user access, choosing what agent commands to run,
deciding which payloads are appropriate to capture, securing your own source repositories and
external services, and rotating any credentials you pass to workloads.

Requests enter through the hiloop edge: the edge resolves identity, backend services enforce organization
scope, and telemetry is stored under the resolved project and organization.

## Hybrid

Managed hiloop services combined with customer-owned storage for selected payloads. Use it when you
want managed operations but need event or workspace payloads to stay under
customer-controlled object storage and keys.

| Component                            | Location                              |
| ------------------------------------ | ------------------------------------- |
| Control-plane API                    | hiloop-operated                       |
| Web console and authorization        | hiloop-operated                       |
| Control-plane metadata               | hiloop-operated                       |
| Selected event or workspace payloads | Customer-owned object storage         |
| Object storage keys                  | Customer-owned or customer-controlled |

Choose hybrid when operational simplicity matters, payload locality is a requirement, and the control
plane can remain managed. Exact payload classes and key ownership are part of the deployment
agreement. Choose on-prem instead when metadata, identity, control plane, runtime, and payloads all
need to stay inside your environment.

## BYOC

A hiloop-operated control plane over a data plane in your own cloud account. Identity, projects,
admission, and orchestration stay managed; sandbox compute, workspace and event payload storage,
and telemetry run inside your account. The data plane in your account holds one outbound, mutually
authenticated control connection to the managed control plane; content-bearing traffic — workspace
bytes, event payloads, sandbox egress — stays inside your boundary and never transits
hiloop-operated infrastructure.

| Layer                                              | Responsibility                                   |
| -------------------------------------------------- | ------------------------------------------------ |
| Cloud account, network, and capacity               | Customer-owned                                   |
| Sandbox runtime and data plane                     | Run in the customer account, delivered by hiloop |
| Workspace, payload, and telemetry storage          | Customer account                                 |
| Control plane (identity, admission, orchestration) | hiloop-operated                                  |
| Keys                                               | Customer-managed                                 |
| Upgrades                                           | Coordinated through deployment change windows    |

Choose BYOC when payloads and compute must stay in your account but you want the control plane
operated for you. The exact scope is part of the deployment agreement.

## On-prem and air-gapped

hiloop running entirely inside customer infrastructure. The customer controls the cluster, database,
object storage, registry, TLS certificates, identity provider, network policy, and local
observability. Use it when data and metadata must remain inside the customer environment.

On-prem has two support postures. The default, supported posture sends a fixed platform-health
metrics contract — never workload data, event payloads, or customer telemetry — to hiloop support.
Fully air-gapped deployments disable it (`supportTelemetry.enabled=false`), which removes the
external exporter and pipeline entirely; local platform observability keeps working either way.

| Component          | Responsibility                                       |
| ------------------ | ---------------------------------------------------- |
| Kubernetes         | Cluster provisioning and base operations.            |
| Identity provider  | SSO/session issuer and access policy integration.    |
| PostgreSQL         | Database hosting, backup, restore, and upgrades.     |
| Object storage     | Workspace, telemetry, and export storage.            |
| Container registry | Mirrored hiloop images and workload images.          |
| TLS certificates   | Issuance, rotation, and trust roots.                 |
| Network policy     | Ingress, egress, DNS, firewall, and proxies.         |
| Observability      | In-cluster logging, metrics, and tracing backend.    |
| Secrets            | Customer-owned secret manager or Kubernetes secrets. |

On-prem installs use Helm charts — the generated [Helm reference](/reference/helm/hiloop) lists chart
values and defaults. For an air-gapped install, mirror images and charts into a registry reachable
from the cluster first. A typical rollout:

* Provision the cluster and namespaces.
* Configure identity, session issuer, and audience consistently.
* Provide database and object storage credentials.
* Mirror images and chart artifacts.
* Configure DNS, TLS, and routes.
* Configure local observability.
* Validate backup and restore.
* Smoke-test identity, telemetry ingest, query, and a bounded sandbox create, exec, and delete.

## Next

* [Helm deployment](/deployment/helm) — chart wiring and values.
* [Security model](/deployment/security-model) — the trust boundary across models.
* [Network requirements](/deployment/network-requirements) — connectivity and egress.
* [Backup and restore](/deployment/backup-restore) — recovery procedures.