Building machine images with Packer: builders, provisioners, validate and build

Goal

Write, validate and build a Packer template that produces a machine image without embedding credentials in the template file itself.

Prerequisites

The packer CLI installed on the machine or CI runner that will run the build; credentials for the target platform (cloud API keys, hypervisor access) available as environment variables or a secrets manager, not as literal values in the template.

Steps

1. Understand the two core building blocks before writing anything. HashiCorp's terminology reference describes builders as components "that are able to create a machine image for a single platform," reading configuration and producing the artifact, while provisioners "install and configure software within a running machine prior to that machine being turned into a static artifact" — shell scripts and third-party configuration tools are named as example provisioners.
2. Declare credentials and other environment-specific values as input variables rather than literals: a variable "api_token" block with type = string and sensitive = true on separate lines (HCL does not accept comma-separated arguments inside a block). HCL templates support a sensitive argument on a variable block, which causes "string-values from that variable to be obfuscated from Packer's output" in logs and console output.
3. Supply the actual secret value at build time from the environment (PKR_VAR_api_token) or a -var / -var-file argument backed by a secrets manager, never checked into the template repository.
4. Install the plugins declared in the template's packer { required_plugins { ... } } block: packer init . (HCL2 templates only; since Packer 1.10 official plugins are no longer bundled). Then run packer validate . (or a single .pkr.hcl file). The command "is used to validate the syntax and configuration of a template" and exits non-zero on failure; run it in CI on every change. -syntax-only skips the configuration check.
5. Run the build: packer build .. The command "takes a template and runs all the builds within it" to generate artifacts, in parallel unless limited with -parallel-builds=N, and -only=/-except= select builds.
6. Store the resulting artifact identifier (AMI ID, image name, etc.) as build output for the next stage of the pipeline, and avoid re-running provisioners against an already-built artifact — treat each build as producing an immutable image.

Expected result

packer validate exits 0 with no template errors before a real build is attempted; packer build produces a versioned image artifact with no credential value visible in its own console output or logs.

Limits and test basis

Marking a variable sensitive prevents Packer from printing its value; it does not encrypt the value in memory, in a state/cache file some plugins may write, or in a provisioner's own script output if that script echoes the value itself — provisioner scripts must handle secrets carefully on their own. packer validate catches syntax and schema-level configuration errors, not runtime failures such as an unreachable builder platform or a provisioner script that fails on the target OS; only packer build exercises those. If a provisioner fails, the default -on-error=cleanup deletes the temporary machine and files. -on-error=abort (or choosing abort at the ask prompt) leaves them for debugging, and you then have to remove them yourself, including cloud instances that are still billed. In a multi-build run, builds that succeeded still produce artifacts, so check which ones exist.