Packer

What it is

Packer is a tool for building identical machine images for multiple platforms from a single source configuration. You define an image once — install packages, run provisioners, bake in your app — and Packer produces outputs for AWS AMIs, Azure images, GCP images, VMware templates, Docker containers, Vagrant boxes, and others. It's the "golden image" pipeline piece that sits upstream of your deployment tooling — Terraform provisions infrastructure, Packer builds what runs on it.

Who builds it and why

HashiCorp built and maintains Packer as part of its infrastructure tooling suite (alongside Terraform, Vault, Consul, Nomad). 1,559 contributors on the repo — a mix of HashiCorp engineers and community contributors — with active development continuing through 2026. It exists because building consistent, reproducible machine images across cloud providers by hand (or with provider-specific scripts) doesn't scale and drifts fast.

Important note on licensing: the license field shows NOASSERTION, which tracks with HashiCorp's 2023 move of Packer (and its other core tools) from MPL 2.0 to the Business Source License (BUSL). BUSL is not OSI-approved open source — it restricts competitive commercial use while allowing free use for most practitioner scenarios. If license compliance matters at your org, don't assume Packer is permissively licensed; read the BUSL terms yourself.

Production readiness signal

15.7k GitHub stars and a commit as recent as mid-2026 indicate this is actively maintained, not abandoned. Latest release v1.15.4 shows a project past its early-version instability — Packer has been production infrastructure at large orgs for close to a decade. The plugin ecosystem (builders for every major cloud/hypervisor) is mature and the core is written in Go, matching the rest of the HashiCorp toolchain for easy CI integration.

CNCF maturity: not publicly available — Packer is not a CNCF project; it's HashiCorp-owned, which affects governance expectations. There's no neutral foundation backstop here; roadmap and licensing decisions are HashiCorp's alone, as the 2023 BUSL move demonstrated.

Who should use this

• Teams building immutable infrastructure who need identical images across dev/staging/prod
• Multi-cloud or hybrid-cloud shops that need one image definition producing consistent outputs across AWS/Azure/GCP/on-prem hypervisors
• Organizations already in the HashiCorp ecosystem (Terraform, Vault) wanting tight integration
• Security/compliance-driven teams that want to bake hardened, scanned images rather than configuring instances at boot time

Who should NOT use this

• Teams building competitive commercial image-building services — BUSL explicitly restricts this use case
• Shops fully committed to container-only workloads with no VM/AMI story — tools like docker build or Buildpacks are simpler and more direct
• Small teams with a single cloud target and low image complexity — cloud-native tools (AWS Image Builder, Azure Image Builder) may mean less tooling overhead
• Organizations that need a CNCF-governed project for procurement or compliance reasons — Packer's governance is vendor-controlled, not foundation-controlled

Alternatives

• AWS Image Builder / Azure Image Builder / GCP-native tooling — cloud-specific, simpler if you're single-cloud, but zero portability.
• Docker/Buildah/Kaniko — the right tools if your deployable unit is a container, not a VM image.
• EIB (Elastic Image Builder) or custom cloud-init/Ansible pipelines — viable if you want to avoid HashiCorp's licensing terms entirely and don't need multi-platform image parity.

Pricing

Packer itself is free to use under the BUSL license for standard practitioner use (not for building competing commercial products). HashiCorp offers HCP Packer, a paid managed service layer on top (image metadata tracking, channel-based promotion, governance) — that's where the commercial model lives. The core binary and CLI remain free.