# Separate image naming, pushing and worker storage in Buildx exports > Review the image exporter’s push and store options without assuming that an image name proves delivery to a registry or local runtime. - Canonical URL: https://update.dsesecurity.com/updates/separate-image-naming-pushing-and-worker-storage-in-buildx-exports/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:04:19+00:00 - Modified: 2026-10-30T06:05:14+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Review the image exporter’s push and store options without assuming that an image name proves delivery to a registry or local runtime. ## Potentially affected Docker Buildx image and registry exporter configurations. ## DSE recommendation Specify and verify the intended registry delivery and worker-store behavior separately from the exported image name. ## Article Bottom line: Name the required delivery destination before selecting exporter options. Review image naming, registry pushing and worker storage as separate fields, then verify the destination through its own approved inspection path. ## Source fact: documented behavior The [Image and registry exporters](https://docs.docker.com/build/exporters/image-registry/) documentation is the primary reference. The image exporter produces a container-image result; the registry exporter is the same exporter with push=true applied automatically. For the image exporter, name assigns an image name while push controls pushing after creation and defaults to false. The store option defaults to true and stores result images in the worker image store, but is ignored when the worker has no image store, such as an OCI worker. ## What the source does not establish This article follows the documented image and registry exporter parameters. It does not promise that a result appears in every local Docker runtime, approve insecure registry transport or define worker-driver compatibility. Keep filesystem exports, build-cache exports and application release acceptance outside this destination check. ## Applicability questions - Is the required result a named image, a pushed registry artifact or a worker-store result? - Which exporter and explicit options does the managed invocation select? - Does that worker actually have the relevant image store? - Which artifact identity and destination observation will demonstrate the intended delivery? ## DSE recommendation: review a destination contract for the result DSE recommends a short export contract naming the intended image reference, registry destination when required, selected exporter and worker identity. Have the build owner state where another operator must be able to retrieve the result. Keep that operational requirement separate from the tag used to label it. Inspect the exact managed output options. Review the effective push choice alongside the exporter type, and confirm any worker-store requirement against the actual builder arrangement. Do not infer successful delivery from an image name in a configuration file or from the existence of a finished build step. Use distinct inspection paths for distinct destinations. Have the registry owner define how the approved artifact will be observed remotely, and the builder owner define any applicable worker-store observation. Retain a missing result as a destination or configuration finding until those owners reconcile it. Avoid changing registry verification or broadening credentials simply to make an exploratory push succeed. Keep the image identity attached to the evidence. Record the reviewed invocation and resulting artifact identifier using the permitted tools, with credential material excluded. Require the normal release process to establish application suitability after delivery is confirmed. Keep cache objects, supplemental attestations and filesystem artifacts under their own inventory rules rather than treating every build output as the same result. ## Verification and evidence Proposed verification, not performed: use a disposable builder and an approved test repository with a harmless image. Prepare one reviewed image-export configuration and a separately identified registry-export or explicit-push configuration. Write the expected destination of each before running it. Inspect the actual result at the destination named by the test contract. If worker storage is required, establish that worker’s supported store and preserve the corresponding observation separately from registry retrieval. Retain exporter type, output options, builder identity, artifact reference and actual findings. Clean up test artifacts through the approved repository procedure. Report the destinations observed without claiming universal local loading, runtime compatibility or a completed application release. ## Official references - [Image and registry exporters](https://docs.docker.com/build/exporters/image-registry/) — Docker Docs. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Docker Docs — Image and registry exporters - Authority: docs.docker.com - URL: https://docs.docker.com/build/exporters/image-registry/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Separate image naming, pushing and worker storage in Buildx exports,” DSE Security, https://update.dsesecurity.com/updates/separate-image-naming-pushing-and-worker-storage-in-buildx-exports/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.