Skip to Content
This documentation is provided with the HEAT environment and is relevant for this HEAT instance only.
DeploymentIntroduction

Introduction to HEAT Deployments

HEAT is a platform that runs on Kubernetes-based infrastructure. Whether hosted in Azure or deployed on-premises using local compute resources, HEAT operates in a largely identical manner. In an on-premises scenario, a Kubernetes cluster is created where HEAT is installed, leveraging local databases instead of Azure commodity resources.

The management of the HEAT application is consistent between cloud and on-premises versions. On-premises deployments may sometimes require access to cloud services for advanced ML/AI operations, or additional local hardware to support high-end features.

Hostname Binding:
HEAT requires a hostname to bind to. As long as clients can resolve this hostname to reach the Kubernetes cluster, routing to HEAT services will work as expected. For on-premises instances, we typically use heat.local for single-machine or LAN setups. For WAN setups where you intend to access HEAT over the internet, you will need to configure a suitable domain name.

All resources related to HEAT reside in the heat namespace within the Kubernetes cluster. Users access HEAT via a single URL endpoint that provides entry to various services:

  • API Ingestion: available at /ingest (REST API)
  • Public Dashboard: available at / (Web Application)
  • Cluster Manager: available at /main (Web Application)
  • Authentication: available at /login (REST API)
  • External APIs: available at /v1, /v2 (REST APIs)
  • Documentation: available at /docs (Web Application)

The diagram below visualises these relationships, all accessible under a single URL:

For detailed deployment instructions, please refer to our specific guides:

SessionsDatabases