There are a few configuration settings that affect Packer globally by
configuring the core of Packer. These settings all have reasonable defaults, so
you generally don't have to worry about it until you want to tweak a
configuration.


Core Configuration - Other

Core Configuration

Packer strives to be stable and bug-free, but issues inevitably arise where
certain things may not work entirely correctly, or may not appear to work
correctly.


Debugging - Other

Debugging

Packer uses a variety of environmental variables.

Environment Variables - Other

Environment Variables

Welcome to the Packer documentation! This documentation is more of a reference
guide for all available features and options in Packer. If you're just getting
started with Packer, please start with the introduction and getting started
guide instead.


Documentation

Installing Packer is simple. You can download a precompiled binary or compile
from source. This page details both methods.


Install

Installing Packer

There are a handful of terms used throughout the Packer documentation where the
meaning may not be immediately obvious if you haven't used Packer before.
Luckily, there are relatively few. This page documents all the terminology
required to understand and use Packer. The terminology is in alphabetical order
for quick referencing.


Terminology

Within the template, the builders section contains an array of all the builders
that Packer should use to generate machine images for the template.


Builders - Templates

Builders

Communicators are the mechanism Packer uses to upload files, execute scripts,
etc. with the machine being created.


Communicators - Templates

Communicators

All strings within templates are processed by a common Packer templating
engine, where variables and functions can be used to modify the value of a
configuration parameter at runtime.


Template Engine - Templates

Engine

Templates are JSON files that configure the various components of Packer in
order to create one or more machine images. Templates are portable, static, and
readable and writable by both humans and computers. This has the added benefit
of being able to not only create and modify templates by hand, but also write
scripts to dynamically create or modify templates.


Templates

The post-processor section within a template configures any post-processing
that will be done to images built by the builders. Examples of post-processing
would be compressing files, uploading artifacts, etc.


Post-Processors - Templates

Post-Processors

Within the template, the provisioners section contains an array of all the
provisioners that Packer should use to install and configure software within
running machines prior to turning them into machine images.


Provisioners - Templates

Provisioners

User variables allow your templates to be further configured with variables
from the command-line, environment variables, or files. This lets you
parameterize your templates so that you can keep secret tokens,
environment-specific data, and other types of information out of your
templates. This maximizes the portability and shareability of the template.


User Variables - Templates

User Variables

The ansible-local Packer provisioner will run ansible in ansible's "local" mode on the remote/guest VM using Playbook and Role files that exist on the guest VM. This means ansible must be installed on the remote/guest VM. Playbooks and Roles can be uploaded from your build machine (the one running Packer) to the vm.


Ansible Local - Provisioners

Ansible Local

The ansible Packer provisioner allows Ansible playbooks to be run to provision
the machine.


Ansible - Provisioners

Ansible (Remote)

The breakpoint provisioner will pause until the user presses "enter" to resume
the build. This is intended for debugging purposes, and allows you to halt at a
particular part of the provisioning process.


breakpoint - Provisioners

Breakpoint

The chef-client Packer provisioner installs and configures software on machines
built by Packer using chef-client. Packer configures a Chef client to talk to a
remote Chef Server to provision the machine.


Chef Client - Provisioners

Chef Client

The chef-solo Packer provisioner installs and configures software on machines
built by Packer using chef-solo. Cookbooks can be uploaded from your local
machine to the remote machine or remote paths can be used.


Chef Solo - Provisioners

Chef Solo

Community-maintained provisioners are not part of the core Packer binary, but
can run alongside Packer with minimal extra effort.


Community - Provisioners

Community-Supported

The converge Packer provisioner uses Converge modules to provision the machine.

Converge - Provisioners

Converge

Packer is extensible, allowing you to write new provisioners without having to
modify the core source code of Packer itself. Documentation for creating new
provisioners is covered in the custom provisioners page of the Packer plugin
section.


Custom - Provisioners

Custom

The file Packer provisioner uploads files to machines built by Packer. The
recommended usage of the file provisioner is to use it to upload files, and
then use shell provisioner to move them to the proper place, set permissions,
etc.


File - Provisioners

File

Provisioners use builtin and third-party software to install and configure the
machine image after booting.


The inspec Packer provisioner allows inspec profiles to be run to test the
machine.


InSpec - Provisioners

InSpec

The PowerShell Packer provisioner runs PowerShell scripts on Windows machines.
It assumes that the communicator in use is WinRM.


PowerShell - Provisioners

PowerShell

The masterless Puppet Packer provisioner configures Puppet to run on the
machines by Packer from local modules and manifest files. Modules and manifests
can be uploaded from your local machine to the remote machine or can simply use
remote paths. Puppet is run in masterless mode, meaning it never communicates
to a Puppet master.


Puppet Masterless - Provisioners

Puppet Masterless

The puppet-server Packer provisioner provisions Packer machines with Puppet by
connecting to a Puppet master.


Puppet Server - Provisioners

Puppet Server

The salt-masterless Packer provisioner provisions machines built by Packer
using Salt states, without connecting to a Salt master.


Salt Masterless - Provisioners

Salt Masterless

shell-local will run a shell script of your choosing on the machine where
Packer is being run - in other words, shell-local will run the shell script on
your build server, or your desktop, etc., rather than the remote/guest machine
being provisioned by Packer.


Shell (Local) - Provisioners

Shell (Local)

The shell Packer provisioner provisions machines built by Packer using shell
scripts. Shell provisioning is the easiest way to get software installed and
configured on a machine.


Shell - Provisioners

Shell

The Windows restart provisioner restarts a Windows machine and waits for it to
come back up.


Windows Restart - Provisioners

Windows Restart

The windows-shell Packer provisioner runs commands on Windows using the cmd
shell.


Windows Shell - Provisioners

Windows Shell

The Packer Alicloud Import post-processor takes a RAW or VHD artifact from
various builders and imports it to an Alicloud customized image list.


Alicloud Import Post-Processor

Alicloud Import

The Packer Amazon Import post-processor takes an OVA artifact from various
builders and imports it to an AMI available to Amazon Web Services EC2.


Amazon Import - Post-Processors

Amazon Import

The artifice post-processor overrides the artifact list from an upstream
builder or post-processor. All downstream post-processors will see the new
artifacts you specify. The primary use-case is to build artifacts inside a
packer builder -- for example, spinning up an EC2 instance to build a docker
container -- and then extracting the docker container and throwing away the EC2
instance.


Artifice - Post-Processors

Artifice

The checksum post-processor computes specified checksum for the artifact list from an upstream builder or post-processor. All downstream post-processors will see the new artifacts. The primary use-case is compute checksum for artifacts allows to verify it later. So firstly this post-processor get artifact, compute it checksum and pass to next post-processor original artifacts and checksum files.


Checksum - Post-Processors

Checksum

Community-maintained post-processors are not part of the core Packer binary, but
can run alongside Packer with minimal extra effort.


Community - Post-Processors

The Packer compress post-processor takes an artifact with files (such as from
VMware or VirtualBox) and compresses the artifact into a single archive.


Compress - Post-Processors

Compress

The Packer DigitalOcean Import post-processor takes an image artifact
from various builders and imports it to DigitalOcean.


DigitalOcean Import - Post-Processors

DigitalOcean Import

The Packer Docker import post-processor takes an artifact from the docker
builder and imports it with Docker locally. This allows you to apply a
repository and tag to the image and lets you use the other Docker
post-processors such as docker-push to push the image to a registry.


Docker Import - Post-Processors

Docker Import

The Packer Docker push post-processor takes an artifact from the docker-import
post-processor and pushes it to a Docker registry.


Docker Push - Post-Processors

Docker Push

The Packer Docker Save post-processor takes an artifact from the docker builder
that was committed and saves it to a file. This is similar to exporting the
Docker image directly from the builder, except that it preserves the hierarchy
of images and metadata.


Docker Save - Post-Processors

Docker Save

The Packer Docker Tag post-processor takes an artifact from the docker builder
that was committed and tags it into a repository. This allows you to use the
other Docker post-processors such as docker-push to push the image to a
registry.


Docker Tag - Post-Processors

Docker Tag

The Packer Exoscale Import post-processor takes an image artifact
from various builders and imports it to Exoscale.


Exoscale Import - Post-Processors

Exoscale Import

The Google Compute Image Exporter post-processor exports an image from a Packer googlecompute builder run and uploads it to Google Cloud Storage. The exported images can be easily shared and uploaded to other Google Cloud Projects.


Google Compute Image Exporter - Post-Processors

Google Compute Export

The Google Compute Image Import post-processor takes a compressed raw disk
image and imports it to a GCE image available to Google Compute Engine.


Google Compute Image Import - Post-Processors

Google Compute Import

Post-processors run after the image is built by the builder and provisioned by
the provisioner(s).


The manifest post-processor writes a JSON file with the build artifacts and IDs from a packer run.


Manifest - Post-Processors

Manifest

The shell-local Packer post processor enables users to do some post processing
after artifacts have been built.


Local Shell - Post-Processors

The Packer UCloud Import post-processor takes the RAW, VHD, VMDK, or qcow2 artifact from various builders and imports it to UCloud customized image list for UHost Instance.


UCloud Import Post-Processors

UCloud Import

The Vagrant Cloud post-processor enables the upload of Vagrant boxes to
Vagrant Cloud.


Vagrant Cloud - Post-Processors

Vagrant Cloud

The Packer Vagrant post-processor takes a build and converts the artifact into
a valid Vagrant box, if it can. This lets you use Packer to automatically
create arbitrarily complex Vagrant boxes, and is in fact how the official boxes
distributed by Vagrant are created.


Vagrant - Post-Processors

Vagrant

The Packer vSphere Template post-processor takes an artifact from the VMware-iso builder, built on ESXi (i.e. remote) or an artifact from the [vSphere](/docs/post-processors/vsphere) post-processor, marks the VM as a template, and leaves it in the path of your choice.


vSphere Template - Post-Processors

vSphere Template

The Packer vSphere post-processor takes an artifact and uploads it to a vSphere endpoint.


vSphere - Post-Processors

vSphere

The Yandex.Cloud Compute Image Exporter post-processor exports an image from a Packer
yandex builder run and uploads it to Yandex Object Storage. The exported
images can be easily shared and uploaded to other Yandex.Cloud Cloud folders.


Yandex.Cloud Compute Image Exporter - Post-Processors

Yandex.Cloud Compute Export

The Yandex.Cloud Compute Image Import post-processor create an image from a qcow2 image (or from provided Storage object in near future). It uploads qcow2 to Yandex Object Storage and create new one Compute Image in target folder.


Yandex.Cloud Compute Image Import - Post-Processors

Yandex.Cloud Compute Import

Special variables provide connection information and basic instance state information.
This page covers all existing special variables.

Contextual Variables - HCL Configuration Language

Contextual Variables

HCL allows the use of expressions to access data exported
by sources and to transform and combine that data to produce other values.

Expressions - Configuration Language

Expressions

Packer uses text files to describe infrastructure and to set variables.
These text files are called Packer _configurations_ and are
written in the HCL language.

Configuration Language

v1.5 Configuration Language

Local values assign a name to an expression that can then be used multiple times within a folder.

Local Values - HCL Configuration Language

Locals

Only and Except can be used as a command line argument to selectively run builds. Only and Except can also be used in a provisioner to not run it for a source.

Only Except - HCL Configuration Language

Only Except

Special variables provide directory information. This page covers all path
variables.

Path Variables - HCL Configuration Language

Path Variables

In addition to the native syntax that is most commonly used with Packer,
the HCL language can also be expressed in a JSON-compatible syntax.

JSON Configuration Syntax - Configuration Language

JSON Syntax

HCL has its own syntax, intended to combine declarative
structure with expressions in a way that is easy for humans to read and
understand.

Syntax - Configuration Language

Syntax

Input variables are parameters for Packer modules.
This page covers configuration syntax for variables.

Input Variables - HCL Configuration Language

Variables

The HCL language has a number of built-in functions that can be called
from within expressions to transform and combine values.

Functions - Configuration Language

Functions

uuid - Functions - Configuration Language

UUID Functions

The uuidv4 function generates a unique id.

v4 - uuid - Functions - Configuration Language

uuidv4

The uuidv5 function generates a uuid v5 string representation of the value in
the specified namespace.

uuidv5 - Functions - Configuration Language

uuidv5

The chomp function removes newline characters at the end of a string.

chomp - Functions - Configuration Language

chomp

The format function produces a string by formatting a number of other values
according to a specification string.