Packer Init and offline environments

Apparently we are supposed to upgrade all our templates to include Packer Init, but there again it says here that “if you prefer not to use the required_plugins block you can continue to install plugins manually”

If you are working in an environment where you can’t connect to the Internet and have to install plugins manually, is there any point in upgrading the template with packer init?

Hi @steven,

If you’re offline completely indeed, packer init won’t be able to do anything since it requires an internet connection in order to fetch plugins from

Regarding required_plugins in a case like this, it’s mostly informative, as you will know which plugins are required to build the image, but it is limited practically indeed.

Out of curiosity since we’re on the topic of manually installing plugins, we’re working on changing how plugins work with Packer, especially regarding cases like required_plugins/manual installation, have you read our blog post regarding this?

Our documentation is not up-to-date yet with regards to those changes, but I’d be curious to know if you’re already using some of the commands we’re promoting, or if the upcoming changes won’t impact your workflows.

If you have a chance to test Packer 1.11.0-alpha that’d be great so we can catch/document potential issues with those upcoming changes.

Thanks in advance, hope that helps!

Thanks for that information - no, I hadn’t seen that blog before - it would have helped. I didn’t realize “packer plugins install --path” would have installed the plugins (vsphere-iso, vmware) exactly where they needed to be. As it was I installed in a dev server and worked it out, then copied manually in to prod.
Nevertheless, it was still easier than installing powershell modules offline.
I may or may not add required_plugins in to the code. As you say, it won’t help from an ease-of-installation point of view, but it would make the code more readable/usable, I suppose.
I think the most difficult aspect of all this is that it’s almost assumed that everyone is connected to the Internet still, which isn’t the case.


I’m also a bit confused about how to manually install “private” plugins from v1.11 going forward.

Previously, as the old docs stated, I simply copied the plugins to Packer’s plugin directory, but should we now do packer plugins install –path <path-to-downloaded-extracted-binary> instead?

Has it changed? I’m on 1.10.1 and I just copy them to:


… and on Windows it is installed in:


“packer plugins install /?” results in a message:

“Invalid plugin source string; The ‘source’ attribute must be in the format ‘hosname/namespace/name’”, which implied that plugins install only work on online installations.

Yeah that’s what I still do currently, but I cannot find the according docs anymore.
However, with v1.11 I understand this to be done differently using packer plugins install –path <path-to-downloaded-extracted-binary>, but I might misunderstand.

@lbajolet-hashicorp @nywilken could you please clarify?
Sorry for the confusion.

Hi @ChristoWolf / @steven,

I’ll try to clarify as much as possible sure, let me know if there’s something we need to re-explain.

Please note that the docs are not yet completely updated in preparation for 1.11.0, so right now the docs we have on are still for v1.10.x and will change when 1.11.0 is out the door.
There are preview docs available for 1.11.0, but even at that, we are working on updating them before the release happens.

Copying plugin binaries to $PACKER_CONFIG_DIR/plugins will not work as-is anymore starting with 1.11.0, and instead we do advise you use packer plugins install --path to install your plugins, if you cannot use packer init for this.
packer init is the simplest method, with the main drawback being that the source has to be in order for it to be able to install the plugins. We plan to address this limitation in an upcoming release, please bear with us for now. Being coupled with required_plugins in the template, this also has the merits of documenting the requirements, and pointing to a URI where one can find the binaries.

Now to be fair you could still install plugins the hard way, by moving them into the plugins directory, under a filesystem hierarchy that matches the source defined for the plugin, with a naming convention that Packer requires (already the case for required_plugins), and an accompanying sumfile. Please note though that while technically possible, we don’t support this explicitly and this will be undocumented as an installation method.
If you want to understand this and play with it, feel free to take a look at the implementation for packer plugins install --path, as this is essentially what you will need to manually replicate.

If only to make sure you are comfortable before that hits GA, I would suggest you try out the beta we released almost two weeks ago.

To answer @steven’s comment:

“packer plugins install /?” results in a message:
“Invalid plugin source string; The ‘source’ attribute must be in the format ‘hosname/namespace/name’”, which implied that plugins install only work on online installations.

This happens because the help function for packer commands is --help, anything that isn’t following this convention is considered an argument to the command, and /? is indeed an invalid source for fetching a plugin from.

Hope this helps clarify your questions, feel free to update this thread again if you need more help.