Does Packer automatically invalidate cached ISOs when remote sources change without checksums?

Direct answer

No. In current Packer artifact cache behavior, a cached ISO is reused when the builder URL matches and no invalidation trigger is present. Packer does not automatically revalidate a remote source with HTTP ETag, Last-Modified or a TTL when no checksum is supplied. Freshness is not checked on subsequent builds.

Confirmed facts

• Packer stores downloaded ISO and other artifacts locally, default ~/.packer.d/cache, and reuses a cached file for a given URL across builds.
• Cache reuse is the default. A cached artifact is considered valid for that URL unless an explicit invalidation trigger occurs.
• Confirmed invalidation triggers are:

1. A checksum or checksum_type mismatch for the URL. The build fails on mismatch, which forces a fresh download on the next attempt.
2. Use of the -force flag, which discards cached state beyond the ISO.
3. Manual removal of the cached file from the cache directory.

Likely explanation, not verified in code

There is no built-in automatic revalidation of remote sources via HTTP headers when no checksum is provided. If a vendor publishes a new ISO at the same URL, Packer will continue to serve the cached copy until one of the triggers above occurs. This is consistent with the documented cache-first design for performance.

Recommended workflow for cache performance with guaranteed freshness

1. Supply a checksum for the ISO source in the builder config. Update the checksum when the vendor image changes. This is the only automatic freshness check Packer performs.
2. If you cannot use a checksum, purge the cache before a build where freshness matters:

# Inspect cache
ls ~/.packer.d/cache

# Remove specific ISO or clear cache
rm ~/.packer.d/cache/*iso*

1. Use packer build -force only when you accept broader state invalidation and longer build times.

Verification you can run now:

• Run two consecutive builds with the same ISO URL and no checksum. Logs should show a cache hit and reuse of the local file.
• Inspect cache directory timestamps after a build to confirm the file is stored and reused.
• Add a checksum, then change the expected value and run a build to confirm mismatch failure.

One missing diagnostic detail that changes the recommendation: Packer version and builder name. Core builders and community plugins can differ in artifact cache semantics, and version-sensitive behavior may affect options. Confirming the exact version and builder will let me confirm whether any plugin-specific cache controls apply to your case.