• Infrastructure
    • terraform
    • packer
  • Networking
    • consul
  • Security
    • vault
    • boundary
  • Applications
    • nomad
    • waypoint
    • vagrant
  • HashiCorp Cloud Platform

    A fully managed platform to automate infrastructure on any cloud with HashiCorp products.

    • consul
    • terraform
    • vault
    • packerbeta
    Visit cloud.hashicorp.com
  • Overview
  • Tutorials
  • Docs
  • Plugins
  • Community
GitHub
Download
Try HCP Packer
  • About External Plugins

      • 1&1
      • Alicloud ECS
      • Alicloud Import
      • Anka Registry Push
      • VM Clone
      • VM Create
      • Ansible (Remote)
      • Ansible Local
      • Overview
      • chroot
      • EBS
      • EBS Surrogate
      • EBS Volume
      • Instance
      • Overview
      • Amazon AMI
      • Parameter Store
      • Secrets Manager
      • Amazon Import
      • Overview
      • ARM
      • chroot
      • DTL
      • Azure DTL Artifact
      • Chef Client
      • Chef Solo
      • CloudStack
      • Converge
      • digitalocean
      • digitalocean-import
      • Docker
      • Docker Import
      • Docker Push
      • Docker Save
      • Docker Tag
      • Overview
      • Commit
      • Repository
      • Tree
      • Google Cloud Platform
      • googlecompute-export
      • googlecompute-import
      • gridscale
      • Overview
      • Receipt
      • Overview
      • Toppings
      • Overview
      • Coffees
      • Ingredients
      • Overview
      • Order
      • Hetzner Cloud
      • HyperOne
      • Overview
      • ISO
      • VMCX
      • InSpec
      • JDCloud
      • Kamatera
      • Linode
      • Libvirt
      • LXC
      • LXD
      • Naver Cloud
      • OpenStack
      • Overview
      • Classic
      • OCI
      • Overview
      • BSU
      • BSU Surrogate
      • BSU Volume
      • chroot
      • Overview
      • ISO
      • PVM
      • ProfitBricks
      • Overview
      • Clone
      • ISO
      • Puppet Masterless
      • Puppet Server
      • QEMU
      • Salt Masterless
      • Scaleway
      • SSH Key
      • Tencent Cloud
      • Triton
      • UCloud
      • UCloud Import
      • upcloud
      • upcloud-import
      • Vagrant
      • Vagrant
      • Vagrant Cloud
      • Overview
      • ISO
      • OVF
      • VM
      • Overview
      • Clone
      • ISO
      • vSphere
      • vSphere Template
      • Overview
      • ISO
      • VMX
      • Vultr
      • Yandex
      • yandex-export
      • yandex-import
Type '/' to Search

»Packer plugins

Packer Plugins allow new functionality to be added to Packer without modifying the core source code. Packer plugins are able to add new components to Packer, such as builders, provisioners, post-processors, and data sources.

This page documents how to use plugins.

If you're interested in developing plugins, see the developing plugins page.

On the left hand side of this page, you can find the available Packer plugins, not all of them are 'official'.

»How Plugins Work

Packer plugins are completely separate, standalone applications that the core of Packer starts and communicates with. Even the components that ship with the Packer core (core builders, provisioners, and post-processors) are implemented in a similar way and run as though they are standalone plugins.

These plugin applications aren't meant to be run manually. Instead, Packer core launches and communicates with them. The next time you run a Packer build, look at your process list and you should see a handful of packer- prefixed applications running. One of those applications is the core; the rest are plugins -- one plugin process is launched for each component used in a Packer build.

»Tiers and Namespaces

Packer plugins are published and maintained by a variety of sources, including HashiCorp, and the Packer community. This website uses tiers and badges to denote the source of a plugin. Additionally, namespaces are used to help users identify the organization or publisher responsible for the integration, as shown in the table below.

TierDescriptionNamespace
Official
Official plugins are owned and maintained by HashiCorp.hashicorp
Verified
Verified plugins are owned and maintained by third-party technology partners. Plugins in this tier indicate HashiCorp has verified the authenticity of the Plugin’s publisher, and that the partner is a member of the HashiCorp Technology Partner Program.Third-party organization
Community
Community providers are published by individual maintainers, groups of maintainers, or other members of the Packer community.Third-party organization or maintainer's individual account
Archived
Archived plugins are plugins that are no longer maintained by HashiCorp, a partner, or the community. This may occur if an API is deprecated or interest was low.hashicorp or third-party

»HCP Packer Badge

HCP Packer Ready
is present for plugins that HashiCorp has verified to communicate build status to the HCP Packer registry.

»Installing Plugins

Currently, you do not need to install plugins for builder, provisioner, or post-processor components documented on the Packer website; these components ship with the Packer core and Packer automatically knows how to find and launch them. These instructions are for installing custom components that are not bundled with the Packer core.

The below tabs reference "multi-component" and "single-component" plugins. If you are not sure what kind of plugin you are trying to install, the easiest way to find out is to check the name. If the name starts with packer-plugin-, then it is a multi-component plugin. If the name starts with a prefix that actually says the component type (e.g. packer-provisioner- or packer-builder), then it is a single-component plugin.

Note: Only multi-component plugin binaries -- that is plugins named packer-plugin-*, like the packer-plugin-amazon -- are expected to work with Packer init. The legacy builder, post-processor and provisioner plugin types will keep on being detected but Packer cannot install them automatically. If a plugin you use has not been upgraded to use the multi-component plugin architecture, contact your maintainer to request an upgrade.

»Create a required_plugins block

  1. Add a required_plugins block to your packer block. Each block will tell Packer what version(s) of a particular plugin can be installed. Make sure to set a valid version constraint string.

Here is an example required_plugins block:

packer {
  required_plugins {
    myawesomecloud = {
      version = ">= 2.7.0"
      source = "github.com/azr/myawesomecloud"
    }
    happycloud = {
      version = ">= 1.1.3"
      source = "github.com/azr/happycloud"
    }
  }
}
packer {
  required_plugins {
    myawesomecloud = {
      version = ">= 2.7.0"
      source = "github.com/azr/myawesomecloud"
    }
    happycloud = {
      version = ">= 1.1.3"
      source = "github.com/azr/happycloud"
    }
  }
}
  1. Run packer init from your project directory (the directory containing your Packer templates) to install all missing plugin binaries. Given the above example, Packer will try to look for a GitHub repository owned by user or organization azr named packer-plugin-myawesomecloud and packer-plugin-happycloud.

»Names and Addresses

Each plugin has two identifiers:

  • A source address, which is only necessary when requiring a plugin outside the HashiCorp domain.
  • A unique local name, which is used everywhere else in a Packer configuration.

»Local Names

Local names allow you to access the components of a plugin and must be unique per configuration.

This is best explained using an example. In the above required_plugins block, we declared the local name "myawesomecloud" for the plugin azr/myawesomecloud. If the "myawesomecloud" plugin contains both an "ebs" builder and an "import" post-processor, then the builder will be accessed in a source block by using:

source "myawesomecloud-ebs" "example" {
  // builder configuration...
}
source "myawesomecloud-ebs" "example" {
  // builder configuration...
}

similarly, the import post-processor would be accessed by declaring the post-processor block:

post-processor "myawesomecloud-import" {
  // post-processor configuration...
}
post-processor "myawesomecloud-import" {
  // post-processor configuration...
}

If we change the required_plugins block to use a different local name "foo":

  required_plugins {
    foo = {
      version = ">= 2.7.0"
      source = "github.com/azr/myawesomecloud"
    }
  }
  required_plugins {
    foo = {
      version = ">= 2.7.0"
      source = "github.com/azr/myawesomecloud"
    }
  }

Then we'd instead access that builder using the source:

source "foo-ebs" "example" {
  // builder configuration...
}
source "foo-ebs" "example" {
  // builder configuration...
}

»Source Addresses

A plugin's source address is its global identifier. It also tells Packer where to download it.

Source addresses consist of three parts delimited by slashes (/), as follows:

<HOSTNAME>/<NAMESPACE>/<TYPE>

  • Hostname: The hostname of the location/service that distributes the plugin. Currently, the only valid "hostname" is github.com, but we plan to eventually support plugins downloaded from other domains.

  • 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 three components given explicitly is called the plugin's fully-qualified address. You will see fully-qualified address in various outputs, like error messages.

»Plugin location

Plugins will usually be located in the PACKER_HOME_DIR.

  • packer init will install plugins in the last directory in the following numbered list.

  • During the initialization of Packer, any plugin required in the required_plugins section will be looked up in all entries of the following list. First plugin found takes precedence. Two binaries of the same plugin with two different version will be considered as two different plugins. Highest found version matching required_plugins will be taken into consideration.

  1. The directory where packer is, or the executable directory.
  2. The current working directory. (".")
  3. The PACKER_HOME_DIR/plugins directory. PACKER_HOME_DIR refers to Packer's home directory, if it could be found.
  4. The director(y/ies) under the PACKER_PLUGIN_PATH env var, if PACKER_PLUGIN_PATH is set.

Note: There can be more than one directory in the PACKER_PLUGIN_PATH env var, it will be seperated by a semicolon (;) on Windows systems and a colon (:) on other systems. The order priority will be kept.

Using the following example :

    required_plugins {
      happycloud = {
        version = ">= 2.7.0"
        source = "github.com/azr/happycloud"
      }
    }
    required_plugins {
      happycloud = {
        version = ">= 2.7.0"
        source = "github.com/azr/happycloud"
      }
    }

The plugin getter will then install the binaries in the following location for a system with no PACKER_PLUGIN_PATH env var set.

  • PACKER_HOME_DIR/plugins/github.com/hashicorp/happycloud/

During initialization, on a darwin_amd64 system, Packer will look-up for the following files:

  • PACKER_EXEC_DIR/github.com/azr/happycloud/packer-plugin-happycloud_*_x5.0_darwin_amd64
  • ./github.com/azr/happycloud/packer-plugin-happycloud_*_x5.0_darwin_amd64
  • PACKER_HOME_DIR/plugins/github.com/azr/happycloud/packer-plugin-happycloud_*_x5.0_darwin_amd64
  • PACKER_PLUGIN_PATH/github.com/azr/happycloud/packer-plugin-happycloud_*_x5.0_darwin_amd64
  • ./packer-plugin-happycloud

The first plugin-name/version files found will take precedence.

For plugins located under the github.com/azr/happycloud/ directory structure an accompanying SHA256SUM file will be required in order for packer init to ensure the plugin being loaded has not been tampered with. The SHA256SUM file will be automatically generated when a plugin is installed via packer init if the plugin was installed manually into PACKER_HOME_DIR/plugins/github.com/azr/happycloud/ then the file PACKER_HOME_DIR/plugins/github.com/azr/happycloud/packer-plugin-happycloud_*_x5.0_darwin_amd64_SHA256SUM must be generated manually as well.

Note: PACKER_HOME_DIR is not an actual env var and refers to Packer's home directory. PACKER_EXEC_DIR is not an actual env var and refers to the directory where packer is, or the executable directory.

»Implicit Github urls

Using the following example :

    required_plugins {
      happycloud = {
        version = ">= 2.7.0"
        source = "github.com/azr/happycloud"
      }
    }
    required_plugins {
      happycloud = {
        version = ">= 2.7.0"
        source = "github.com/azr/happycloud"
      }
    }

The plugin getter will look for plugins located at:

  • github.com/azr/packer-plugin-happycloud

Packer will error if you set the packer-plugin- prefix in a source. This will avoid conflicting with other plugins for other tools, like Terraform.

github logoEdit this page
IntroGuidesDocsCommunityPrivacySecurityPress KitConsent Manager