Packer caches downloaded ISOs and plugins to speed up subsequent builds.
Here’s how Packer’s caching mechanism works and how you can manage it.
Let’s say you’re building a new AMI for your application. Your Packer template specifies a base ISO, like ubuntu-20.04-desktop-amd64.iso. The first time you run packer build your-template.pkr.hcl, Packer needs to download this ISO. It will fetch it from the specified URL and store it locally.
packer build your-template.pkr.hcl
When you run the build again, Packer checks its cache. If the ISO is found and its checksum matches, Packer will reuse the downloaded file instead of downloading it again. This dramatically speeds up build times, especially for large ISOs or when working with slow network connections. The same principle applies to Packer plugins. If your template requires a specific plugin, Packer downloads and caches it on the first run.
Where Packer Stores Cache
By default, Packer stores its cache in a directory named .packer.d in your user’s home directory. On Linux and macOS, this is typically ~/.packer.d. On Windows, it’s usually C:\Users\<YourUsername>\.packer.d.
Inside .packer.d, you’ll find subdirectories:
packer/for downloaded ISOs and other build artifacts.plugins/for downloaded Packer plugins.
You can also override the cache directory using the PACKER_CACHE_DIR environment variable. This is useful if you want to keep your cache on a different drive or in a specific project directory.
export PACKER_CACHE_DIR=/path/to/my/packer_cache
packer build your-template.pkr.hcl
Managing the Cache
Clearing the Cache
Sometimes, you might need to clear the cache. This can happen if:
- An ISO download was corrupted.
- You want to force Packer to re-download a specific file.
- You’re troubleshooting build issues.
To clear the cache, simply delete the contents of the .packer.d directory (or your custom PACKER_CACHE_DIR).
rm -rf ~/.packer.d
Warning: This will remove all cached ISOs and plugins. Subsequent builds will need to re-download everything.
Excluding Specific Files from Cache
Packer doesn’t offer a direct way to exclude specific ISOs or plugins from being cached. The caching is generally automatic for anything downloaded via a URL or a plugin registry. If you need to prevent a specific download from being cached, you’d typically manage that outside of Packer, perhaps by pre-downloading it and then using a local path if the Packer builder supports it.
Using Local Files Instead of Remote URLs
For ISOs, if you don’t want Packer to download it at all, you can often provide a local path to the ISO file directly in your Packer template.
For example, instead of:
source "amazon-ebs" "example" {
ami_name = "example-ami"
instance_type = "t2.micro"
source_ami_filter {
filters = {
name = "ubuntu-20.04-server-amd64*"
root-device-type = "ebs"
virtualization-type = "hvm"
}
owners = ["099720109477"] # Canonical
}
ssh_username = "ubuntu"
}
You might have a local ISO:
source "virtualbox-iso" "example" {
iso_url = "file:///path/to/your/local/ubuntu-20.04-desktop-amd64.iso"
iso_checksum = "sha256:..." # Optional but recommended
vm_name = "ubuntu-test"
// ... other settings
}
When iso_url starts with file://, Packer will use the local file directly and will not attempt to download or cache it from a remote URL.
Caching Plugins
Packer plugins are managed separately from ISOs. When you run a build that requires a plugin not already installed, Packer will download it from the official Packer plugin registry or a specified custom registry. These plugins are stored in ~/.packer.d/plugins/.
You can explicitly install or update plugins using the packer init command, which also respects the PACKER_PLUGIN_CACHE_DIR environment variable (though often PACKER_CACHE_DIR covers this too).
packer init .
This command will check your template for required plugins and download them if they are missing or if a newer compatible version is available.
The caching of plugins is crucial for build consistency and speed. Without it, every build requiring a specific plugin would have to download it first, adding significant overhead.
A Counterintuitive Aspect of Caching
While Packer’s cache is generally beneficial, it can sometimes mask issues with the original source files. If an ISO or plugin download is subtly corrupted but still passes basic integrity checks (like a weak checksum), Packer will happily use the corrupted version from its cache, leading to baffling build failures that disappear if you manually clear the cache and force a re-download. This is why, during troubleshooting, the first step is almost always rm -rf ~/.packer.d.
The next thing you’ll likely encounter is managing remote state for collaborative Packer builds.