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):
| Path | Service |
|---|---|
/ | Analytics dashboard (Next SPA) |
/main | Cluster Manager |
/login | Authentication |
/ingest/... | Data ingest endpoints |
/api/v2/... | External v2 API |
/v1/... | Legacy facade (where enabled) |
/docs | This documentation site |
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 Cluster Manager for your project.
- Session templates and ingests created for your integration.
Prerequisites (operators)
- Cluster Manager 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).