Packer — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about HashiCorp Packer.
Packer was Mitchell Hashimoto's first open-source project at HashiCorp¶
Packer was released in July 2013, making it one of Mitchell Hashimoto's earliest post-Vagrant projects and HashiCorp's first tool after Vagrant. Hashimoto created it to solve a problem he encountered repeatedly: building identical machine images across multiple platforms (AWS AMIs, VMware images, Docker containers) from a single source configuration.
The "immutable infrastructure" concept drove Packer's creation¶
Packer was built on the philosophy that servers should never be modified after deployment — if you need a change, build a new image and replace the old one. This "immutable infrastructure" pattern, championed by Chad Fowler in a 2013 blog post, made Packer essential because it automated the image-building step that immutable infrastructure requires.
Packer builds are intentionally slow — and that's the point¶
A Packer build that creates an AMI might take 15-30 minutes. This seems slow compared to container builds, but the tradeoff is deliberate: the slow build happens once, and then hundreds or thousands of servers can be launched from the pre-baked image in seconds. The build-once-deploy-many model makes the per-deployment cost near zero.
HCL replaced JSON as Packer's configuration language in 2020¶
Packer originally used JSON for its template files, which was functional but verbose and didn't support comments. In Packer 1.5 (2020), HCL2 support was added alongside JSON. The HCL migration took years because the existing ecosystem of JSON templates was enormous. JSON templates were officially deprecated in Packer 1.7.
Netflix used Packer to bake AMIs for their entire fleet¶
Netflix was one of Packer's earliest and most prominent users, using it to create "baked" AMIs that contained everything an application needed to run. Their "Aminator" tool predated Packer, but many teams adopted Packer for its multi-cloud support. Netflix's approach of pre-baking AMIs instead of configuring servers at boot time became an industry best practice.
Packer builders exist for platforms most people have never heard of¶
While most people use Packer for AWS AMIs and Docker images, Packer has builders for dozens of platforms including Yandex Cloud, Hetzner Cloud, 1&1 IONOS, Nutanix, Outscale, and Naver Cloud. This breadth reflects Packer's community-driven plugin model, where cloud providers contribute their own builders.
Provisioners in Packer are a contentious design choice¶
Packer supports "provisioners" — scripts or tools (shell, Ansible, Chef, Puppet) that configure the image during build time. Some purists argue that provisioners make builds non-reproducible and that all software should come from a package manager. Others argue that provisioners are pragmatically necessary. This debate mirrors the broader "configuration management vs. immutable images" discussion.
The Packer community created the "golden image" pipeline pattern¶
The "golden image" pipeline — where a base OS image is hardened, patched, and validated through a CI/CD pipeline using Packer — became a standard infrastructure pattern. Organizations build golden images weekly or monthly, test them automatically, and promote them through dev/staging/production. This pattern reduced configuration drift and improved security compliance.
Packer's post-processors can chain image transformations¶
Packer's post-processor system can chain operations: build a Docker image, push it to a registry, then create a Vagrant box from it, all in a single build. This composability was unusual for infrastructure tools in 2013 and allowed teams to maintain a single image definition that produced artifacts for multiple platforms.