OpenStack Heat

License	FOSS problems	Maintenance	SSO	Users	Tested
Apache-2.0Permissive license. Like MIT, but each contributor grants users a patent licence covering their contribution, preventing later suits.	—	Active	—	Unlimited	❌

Description

Heat is OpenStack's own orchestration service — part of OpenStack core, not a third-party tool bolted on. A template (HOT format — Heat Orchestration Template, YAML) describes a "stack" of resources; the Heat engine runs server-side, as an OpenStack service alongside Nova, Cinder, and Neutron, and reconciles the stack against the template using those same APIs directly.

Features

• No separate tool or state backend — state lives in OpenStack itself, tracked by the Heat engine as part of the platform. Nothing to install locally, no bucket to provision and secure for state, no separate credential story beyond what's already used for everything else on that cloud.
• HOT templates — YAML-based, with nesting and reuse via nested stacks and template resources — though reported as more verbose than HCL modules for parameterizing the same stack across environments.
• Native autoscaling — OS::Heat::AutoScalingGroup ties directly into OpenStack's own telemetry/alarm services, no external tool needed for that specific case.
• Update and rollback semantics built into stack updates, tracked server-side by the same engine that created the stack.

Example usage

The same instance and boot volume, in HOT:

heat_template_version: 2021-04-16

resources:
  main_key:
    type: OS::Nova::KeyPair
    properties:
      name: main
      public_key: { get_param: ssh_public_key }

  boot_volume:
    type: OS::Cinder::Volume
    properties:
      name: personal-services-boot
      size: 20
      volume_type: CEPH_1_perf1

  instance:
    type: OS::Nova::Server
    properties:
      flavor: a4-ram16-disk0
      key_name: { get_resource: main_key }
      block_device_mapping_v2:
        - volume_id: { get_resource: boot_volume }
          boot_index: 0

openstack stack create (or update) reconciles this against the cloud directly — no plan/apply split, no local state file to keep in sync with anything.

Usage patterns

• Only where the cloud enables it — Heat has to actually be running as a service on the OpenStack deployment in question. Infomaniak's cloud exposes it; not every OpenStack provider does.
• No state-backend story at all — a genuine simplification against Terraform/OpenTofu/Pulumi's entire state-backend/credential setup, since the cloud already is the source of truth.
• Single-cloud, by construction — there's no provider abstraction here; a Heat template only ever targets the one OpenStack cloud it's written against.

License and governance

Apache 2.0, an OpenStack project governed the same way the rest of OpenStack is — under the OpenInfra Foundation, multi-vendor, no single company able to relicense it. No relicensing risk of the Terraform/IBM shape at all here; if anything, a cleaner governance story than any of the other three options in this category.

Conclusion

Why you would — it looks immediately limited to OpenStack, and it is — but for infrastructure that's committed to OpenStack specifically anyway, that limitation buys real simplicity: no separate tool, no state backend to secure, no credential story beyond what's already in use.

Why you wouldn't — that same limitation is the whole story: a Heat template is worthless outside the one OpenStack cloud it targets, with none of Terraform/OpenTofu's portable provider model if this project (or its provider) ever needed to move. Smaller community than Terraform's ecosystem, and template reuse is reportedly more awkward than HCL modules once a stack needs to vary across more than one environment.