Environment requirements
HEAT ships as a Kubernetes application. Behaviour is consistent across profiles. Capacity, high availability and network paths differ.
Deployment profiles
| Profile | Typical use |
|---|---|
| Azure | Managed cloud, scale on demand |
| On-premises | Private cluster, data sovereignty, air-gapped options |
| Local / lab | Demos, integration testing, smaller clusters |
Non-Azure installs usually need Kubernetes provisioned by your team or vendor. Licensing and upgrades are managed per contract.
Entry URLs
A single hostname fronts HEAT services (exact paths may vary slightly by release). The operator portal is HEAT Control Centre (formerly Cluster Manager). Its /main and /admin paths predate the rename and are unchanged.
| Path | Service |
|---|---|
/ | Analytics dashboard (Next SPA) |
/main | Control Centre |
/login | Authentication |
/ingest/... | Data ingest endpoints |
/api/v2/... | External v2 API |
/v1/... | Legacy facade (where enabled) |
docs.<host>/ | This documentation site (its own hostname, not a path under the main host) |
See Deployment introduction for a diagram of how traffic reaches components.
Prerequisites (integrators)
- Network access from clients to the HEAT hostname (and VPN if required).
- HEAT Auth credentials or offline token for API automation.
- Blob or database data sources configured in Control Centre for your project.
- Session templates and ingests created for your integration.
Prerequisites (operators)
- Control Centre admin access.
- Kubernetes cluster admin for the HEAT namespace (for on-prem troubleshooting).
- Monitoring hooks (optional): Grafana, platform metrics.
Not covered here
- Green-field installation of HEAT (contact your deployment team).
- Direct access to internal platform databases (see On-prem databases).
Related
Opens your browser's print dialog. Choose "Save as PDF" as the destination.