---
page_title: packer - Blocks
description: |-
  The "packer" configuration section is used to configure some behaviors
  of Packer itself.
---

# Packer Settings

`@include 'from-1.5/beta-hcl2-note.mdx'`

-> **Note:** The `packer` block is only available in Packer v1.6.5 and later.

The `packer` configuration block type is used to configure some
behaviors of Packer itself, such as the minimum required Packer version needed to
apply your configuration.

## Packer Block Syntax

Packer settings are gathered together into `packer` blocks:

```hcl
packer {
  # ...
}
```

Each `packer` block can contain a number of settings related to Packer's
behavior. Within a `packer` block, only constant values can be used;
arguments may not refer to named objects such as resources, input variables,
etc, and may not use any of the Packer language built-in functions.

The various options supported within a `packer` block are described in the
following sections.

## Specifying a Required Packer Version

The `required_version` setting accepts a [version constraint
string,](#version-constraints) which specifies which versions of Packer
can be used with your configuration.

If the running version of Packer doesn't match the constraints specified,
Packer will produce an error and exit without taking any further actions.

Use Packer version constraints in a collaborative environment to
ensure that everyone is using a specific Packer version, or using at least
a minimum Packer version that has behavior expected by the configuration.

## Specifying Plugin Requirements

-> **Note:** The `required_plugins` block is only available in Packer v1.7.0 and
later.

The `required_plugins` block specifies all of the plugins required by the
current template, mapping each local plugin name to a source address and a
version constraint.

```hcl
packer {
  required_plugins {
    happycloud = {
      version = ">= 2.7.0"
      source = "github.com/hashicorp/happycloud"
    }
  }
}
```

Using the `required_plugins` block to codify the plugins required for invoking a 
`packer build` on your template(s) is a great way to ensure consistent builds across
different platforms or hosts.

The block codifies two pieces of information that we've found critical to ensure reproducible builds:
1. **The source of a required plugin** indicates to users where a plugin where a plugin was downloaded from
and where to reach out if there are issues with the plugin. 
1. **The version of a required plugin** indicates to users the exact or minimum version needed for the build. 
This is a great way to pin approved versions of a plugin that can be installed across your environment or team.

For more information on plugins, refer to [Plugins](/packer/docs/plugins).

## Source Addresses

A plugin's source address is conceptually where a plugin binary can be downloaded from. Packer also uses this source as a global unique identifier. 
When used in conjunction with the `packer init` command a plugin's source address tells Packer where to download it. 

At minimum source addresses consist of three parts delimited by slashes (`/`), as
follows:

-> **Note:** In Packer 1.11 and later source addresses support one or more sub-folder paths
after the hostname to support users who require source addresses with more than three parts. 
While `packer init` only supports remote installation of GitHub source addresses, running `packer init` on 
plugins with custom source addresses allows users to take advantages of version pinning features offered by the 
`required_plugins` block. For details on installing plugins using custom source addresses refer to [packer plugins install](/packer/docs/commands/plugins/install).

`<HOSTNAME>/<NAMESPACE>/<TYPE>`

- **Hostname:** The hostname of the location/service that
  distributes the plugin.

- **Namespace:** An organizational namespace within the specified host.
  This often is the organization that publishes the plugin.

- **Type:** A short name for the platform or system the plugin manages. The
  type is usually the plugin's preferred local name.

For example, the fictional `myawesomecloud` plugin could belong to the
`hashicorp` namespace on `github.com`, so its `source` could be
`github.com/hashicorp/myawesomecloud`,

-> Note: the actual _repository_ that myawesomecloud comes from must always have
the name format `github.com/hashicorp/packer-plugin-myawesomecloud`, but the
`required_plugins` block omits the redundant `packer-plugin-` repository prefix
for brevity.

The source address with all components given explicitly is called the
plugin's _fully-qualified address_. You will see fully-qualified address in
various outputs, like error messages.

### Non-GitHub Source Addresses
As mentioned above a plugin's source address is its global identifier that provides users codified information on where a plugin is sourced and can be obtained. 
In cases where a plugin source does not originate from a GitHub repository, such as a plugin binary store, custom source addresses can help
users taken advantage of plugin version pinning via required_plugins block and forego the use of `packer init` in favor of `packer plugins install --path`.

For example if your organization has a need for pre-downloading approved Packer plugins into an internal artifact store (e.g mycompany.com/mirror/hashicorp/happycloud)
you can use the `packer plugins install --path` command to install the binary with the custom source address and add an entry for it as a required plugin in your template. 

```shellsession
packer plugins install --path path/to/binary mycompany.com/mirror/hashicorp/happycloud
```

The provided source address will translate directly to the file hierarchy in which the plugin binaries will be installed.
After a successful installation the custom source address can be added to your template to take advantage of version pinning for the `mycompany.com/mirror/hashicorp/happycloud` plugin. 
Invoking `packer init` on the template will respond without error and ensure that the correct version of the plugin is loaded. 

If however, the plugin is not installed at the time you run `packer init` Packer will error indicating that only GitHub source addresses are supported for remote installation. 

## Version Constraints

Anywhere that Packer lets you specify a range of acceptable versions for
something, it expects a specially formatted string known as a version
constraint.

### Version Constraint Syntax

Packer's syntax for version constraints is very similar to the syntax used by
other dependency management systems like Bundler and NPM.

```hcl
required_version = ">= 1.2.0, < 2.0.0"
```

A version constraint is a [string literal](/packer/docs/templates/hcl_templates/expressions#string-literals)
containing one or more conditions, which are separated by commas.

Each condition consists of an operator and a version number.

Version numbers should be a series of numbers separated by periods (like
`1.2.0`), optionally with a suffix to indicate a beta release.

The following operators are valid:

- `=` (or no operator): Allows only one exact version number. Cannot be combined
  with other conditions.

- `!=`: Excludes an exact version number.

- `>`, `>=`, `<`, `<=`: Comparisons against a specified version, allowing
  versions for which the comparison is true. "Greater-than" requests newer
  versions, and "less-than" requests older versions.

- `~>`: Allows the specified version, plus newer versions that only
  increase the _most specific_ segment of the specified version number. For
  example, `~> 0.9` is equivalent to `>= 0.9, < 1.0`, and `~> 0.8.4`, is
  equivalent to `>= 0.8.4, < 0.9`. This is usually called the pessimistic
  constraint operator.

### Version Constraint Behavior

A version number that meets every applicable constraint is considered acceptable.

Packer consults version constraints to determine whether it has acceptable
versions of itself.

A prerelease version is a version number that contains a suffix introduced by
a dash, like `1.2.0-beta`. A prerelease version can be selected only by an
_exact_ version constraint (the `=` operator or no operator). Prerelease
versions do not match inexact operators such as `>=`, `~>`, etc.
