What causes "Error destroying builder artifact: %s; bad artifact: %#v" in hashicorp/packer?

Inspect the destroy error and the listed artifact files to identify the resource that failed cleanup

Error destroying builder artifact: %s; bad artifact: %#v

Error message

Error destroying builder artifact: %s; bad artifact: %#v

What it means

At the end of CoreBuild.Run, when on-error is configured to clean up (not keep) the builder's original artifact, builderArtifact.Destroy() is invoked. If that fails, Run records "Error destroying builder artifact: %s; bad artifact: %#v", embedding the destroy error and the artifact's Files() list for debugging, and the run returns a packersdk.MultiError containing it.

Source

Thrown at packer/build.go:468

			}

			priorArtifact = artifact
		}

		// Add on the last artifact to the results
		if priorArtifact != nil {
			artifacts = append(artifacts, priorArtifact)
		}
	}

	if keepOriginalArtifact {
		artifacts = append(artifacts, nil)
		copy(artifacts[1:], artifacts)
		artifacts[0] = builderArtifact
	} else {
		log.Printf("Deleting original artifact for build '%s'", b.Type)
		if err := builderArtifact.Destroy(); err != nil {
			errors = append(errors, fmt.Errorf("Error destroying builder artifact: %s; bad artifact: %#v", err, builderArtifact.Files()))
		}
	}

	if len(errors) > 0 {
		err = &packersdk.MultiError{Errors: errors}
		return artifacts, err
	}

	return artifacts, nil
}

func (b *CoreBuild) SetDebug(val bool) {
	if b.prepareCalled {
		panic("prepare has already been called")
	}

	b.debug = val
}

View on GitHub (pinned to eb36e3c3e4)

Solutions

Inspect the destroy error and the listed artifact files to identify the resource that failed cleanup
Manually delete the leftover resource (AMI, image, container) to avoid orphaned/billed resources
Check IAM/cloud permissions for delete/deregister operations and retry the build
Enable PACKER_LOG=1 for the builder's destroy logs; if the builder's cleanup is buggy, report it to the plugin repo

Example fix

// before (HCL2)
build { on_error = "cleanup" }
// after - keep the artifact on error so failed destroys don't mask the real error
build { on_error = "ask" } // or "abort"/"keep", then clean up manually

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight: verify the builder's credentials can delete its resources
// (e.g. ec2:DeregisterImage + ec2:DeleteSnapshot for the amazon-ebs builder).

Try / catch

artifacts, err := build.Run(ctx, ui)
if err != nil {
    var multi *packersdk.MultiError
    if errors.As(err, &multi) {
        for _, e := range multi.Errors {
            if strings.Contains(e.Error(), "Error destroying builder artifact") {
                log.Printf("builder artifact cleanup failed — delete manually to avoid billing: %v", e)
            }
        }
    }
    return err
}

Prevention

Choose on_error values consciously: cleanup destroys artifacts (and can fail); keep/ask preserve them for manual handling
Ensure builder credentials include delete rights, not just create
Clean up orphaned resources from failed runs with tagged-resource sweeps
Report builder plugins whose Destroy fails on partially-created resources

When it happens

Trigger: A build finishes (or is cancelled/aborts) with cleanup enabled and the builder's artifact cannot be destroyed — e.g. EC2 AMI deregistration fails, a docker container/image removal fails, or the remote VM cannot be torn down due to API errors.

Common situations: Cloud-side permission errors on delete; resources locked or in a transitional state; artifact already destroyed by a concurrent process; network failures during the destroy API call; builders with incomplete Destroy implementations for partially-created resources.

Related errors

AI-assisted analysis of hashicorp/packer@eb36e3c3e4 (2026-09-05). Data as JSON: /api/errors/c1f038f86d4ad4ae. Report an issue: GitHub.