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:

Default internal admin user

On first-time setup, the auth service seeds a default internal management admin user:

  • Username: vrai.admin
  • Password: HeatHeat!! (no forced change on first login)
  • Email: admin@heat.internal

This user’s email cannot be changed (it is the fixed internal management identity). In production, change the password after first login.

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

SessionsDatabases