Packer: Reproducible Machine Images as Code

Packer

Servers configured by hand — or by scripts run against long-lived machines — slowly become unique. Each one has a slightly different set of patches, packages, and fixes, and replacing one in an emergency means hoping the configuration script still works. Packer takes the opposite approach: it builds a machine image — an AWS AMI, Azure image, Google Compute image, VMware template, or Docker image — from a template, by launching a temporary machine, configuring it, and capturing the result.

Instances launched from the image start identical, boot fast, and can be replaced rather than repaired. Packer is the build step of immutable infrastructure: the image is a versioned artifact, tested once and promoted through environments like application builds.

TL;DR

Packer builds machine images from HCL2 templates: sources (builders), provisioners, and post-processors.
Declare required plugins and run packer init, packer validate, and packer build.
Configure images with shell, Ansible, or other provisioners — once, at build time.
Version and tag every image with what is inside it, and record build metadata.
Test images before promoting them, then promote the same image from staging to production.
Use Terraform or your platform to launch instances from the image; Packer only builds it.

Quick Example

An Ubuntu 24.04 AMI with the application runtime installed and a self-test at the end of the build:

The build launches a temporary instance, runs the provisioners, creates the AMI, and terminates the instance. The manifest gives the next pipeline step the new image ID.

Core Concepts

Template Building Blocks

Builders and Plugins

Builders are distributed as plugins for each platform — Amazon, Azure, Google Cloud, VMware, QEMU, Docker, and others. One template can define several sources and build images for multiple platforms or regions in parallel from the same provisioning steps.

Provisioners

Shell scripts suit simple setups. For complex configuration, the Ansible provisioner reuses existing roles at build time, combining configuration management with immutable images — see Terraform vs Ansible. Whatever you use, finish by cleaning caches, SSH host keys, and machine IDs so instances do not share identities.

Image Pipelines

Terraform reads the promoted image through a data source or a variable, so a new image reaches an environment through a reviewed plan rather than a manual console change. Registries such as HCP Packer can track image versions and channels across builds.

Best Practices

Rebuild Regularly

Base images receive security patches constantly. Rebuild on a schedule — weekly is common — as well as when your own configuration changes, so instances never run months-old packages.

Pin What Goes In

Pin plugin versions, base image selection rules, and package versions where reproducibility matters. Record the resolved base image ID in the image tags.

Fail the Build on a Broken Image

Run smoke tests inside the build and boot tests after it. A build that produces an image which cannot start the application should fail, not succeed quietly.

Keep Secrets Out of Images

Never bake credentials into an image. Instances should fetch secrets at boot from a secrets manager using their own identity. See Secrets Management.

Common Mistakes

Configuring at Boot Instead of Build

Images Nobody Can Trace

Promoting Untested Images

FAQ

What is Packer used for?

Building machine images — cloud images, virtual machine templates, or container images — from code, so that every server starts from an identical, tested, versioned image.

How does Packer relate to Terraform?

Packer builds images; Terraform provisions infrastructure that uses them. A typical pipeline builds and tests an image with Packer, then updates Terraform configuration to launch instances from the new image ID.

Can Packer use Ansible?

Yes. The Ansible provisioner runs playbooks against the temporary build machine, so existing roles produce images instead of configuring running servers.

How often should images be rebuilt?

At least when base images receive security updates — many teams rebuild weekly or nightly — and whenever the software or configuration inside changes.

Is Packer still relevant with containers?

For container workloads, Dockerfiles and container builds usually replace Packer. Packer remains valuable for virtual machines, Kubernetes node images, edge devices, and anything that runs a full operating system image.