Data Sovereignty
Central to the design of HEAT is a focus on maintaining control over data. Whether you’re operating in a tightly regulated industry or simply value strong data governance, HEAT is designed from the ground up to support data sovereignty.
Where does your data go?
HEAT is a platform that connects, processes, and visualizes data, but it doesn’t take ownership of your data. All captured data is stored in a location of your choosing. You can configure HEAT to:
- Use a local, in-cluster blobstore managed by the HEAT environment.
- Push data to a cloud-based blobstore that you control.
- Integrate with external databases or blobstores entirely outside of the HEAT platform.
Once ingested, your data remains in the configured storage location and is only accessed when needed by processing components within the HEAT environment, or when displaying dashboards.
In the above example, you can use our internally managed blobstore, or an external blobstore, which can exist in Azure or an S3 compatible service you manage. Our internal blobstore is high-performance and recommended for development.
How is it stored?
When HEAT ingests data, it is placed into a blobstore, which is a highly durable and scalable storage mechanism. You decide whether that blobstore is local, cloud-hosted, or external. Only services within the Kubernetes cluster, specifically, the runners, can access this data.
The storage layer is not exposed publicly. There’s no external S3-compatible access enabled in production environments.
Metadata such as session names or configuration options may be stored in HEAT’s internal services, but this data contains no personal information by default. Session data is decoupled from user identity.
How secure is it?
Security is foundational in HEAT’s architecture:
- All data storage and processing occurs within a secure Kubernetes cluster.
- The internal blobstore and databases are not accessible from outside the cluster.
- Services that require access to your data, like runners, run inside the cluster and only access what is necessary.
- Authentication is externalized, even our built-in provider runs as a separate system. If your identity system is disabled, HEAT cannot access or correlate users to data.
In production deployments, development/debugging endpoints are disabled to ensure minimal attack surface.
How long do we hold your data?
By default HEAT does not delete your blob data automatically: you control external blobstores and lifecycle rules. The Core API can optionally enforce template-driven session retention (Session retention): archive old node outputs or delete whole sessions after an idle threshold. That applies to HEAT-managed session buckets and metadata; it does not replace your policies on external storage you configure separately.
If the blobstore becomes unavailable or is deleted, the system will no longer be able to render dashboards or recover insights, as HEAT does not keep internal copies of session data beyond what remains in your configured storage.
Getting your data out
Data held by HEAT is reachable in open formats through documented interfaces. Nothing has to be requested from the vendor.
| What you want | How you get it |
|---|---|
| The result of any processing step | The HEAT v2 API lists the node outputs of a node and returns the bytes of each one as they were stored. Most outputs are JSON, and each node template page documents its output shape. |
| The data you uploaded | The same routes. An upload is the node output of the input node, returned byte for byte. |
| A whole session in one file | Export session in the Control Centre produces a ZIP archive with the session record, its template, a manifest and one file for each node output. See Session Exports. |
| A summary across many sessions | The Reports API returns CSV or XLSX. The session list returns the metadata of every session as JSON. |
| The meaning of captured data | Data recorded by HEAT Capture uses the HEAT ProtoLib Protocol Buffers schemas. Every message and field is documented. See HEAT ProtoLib and the data dictionary. |
Read data through the API, not from the storage bucket. When a project queues its uploads, HEAT bundles many small uploads into larger stored objects (heatx). The API returns each output on its own, so your software never handles the bundle format.
Separating and removing data
HEAT gives you these controls over where data sits and how it is removed.
- Environments. An environment shares nothing with another environment. When two audiences must not see each other’s data, give each its own environment. See Architecture and boundaries.
- Projects. Every Session belongs to exactly one Project. A project keeps the sessions and templates of one programme together. It does not restrict who can see them, because roles apply to the whole environment.
- Storage by template. A node names the data source it writes to. A session template can therefore keep its data in a store that you registered for that purpose, apart from the platform default.
- Personal details. Names and email addresses are held only in HEAT Auth. Sessions, dimensions and node outputs carry an identifier and never a name. To forget a person, remove them in HEAT Auth.
- Retention. A session template can archive old node outputs or delete whole sessions after an idle period. See Session retention.
- Deletion. Delete session in the Control Centre removes the session record, its node instances, its outputs and its stored objects. It cannot be undone. See Sessions.
- Isolation. HEAT runs fully air-gapped, with no dependency on the public internet. See Deployment.
Summary
HEAT is designed to respect your sovereignty and privacy:
- You choose where your data lives.
- You control access and retention.
- No personal data is stored in the core system.
- Removing access to your blobstore disables access to your data.
- Your data leaves through documented interfaces in open formats.
This gives you full control over your data lifecycle, from ingestion to deletion, in a secure, transparent way.