Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers VPS plans with one-click Docker, NVMe storage and a 14-day free trial.
Build a distroless image with a multi-stage Dockerfile, compile the application in a full builder stage, copy only its runtime files into a distroless stage, and let BuildKit produce, cache, attest, and publish the result. The production image should contain no shell or package manager. Use a matching :debug image or a separate debug target when you need a shell, and choose static, base, cc, or a language-specific runtime according to the binary’s real dependencies.
This approach answers the common questions “How do I build a distroless Docker image with BuildKit?”, “How do I debug a distroless container with no shell?”, “How do I make a multi-stage Docker build smaller and safer?”, and “How do I create multi-platform images with buildx?” without treating a smaller image as a substitute for compatibility testing or supply-chain controls.
What a distroless image is—and what BuildKit contributes
A distroless image contains an application and the minimum runtime files it needs, rather than a general-purpose Linux userland. There is normally no interactive shell, package manager, compiler, or diagnostic tool. That reduced contents list limits what an attacker can use after a compromise and makes accidental production changes less likely, but it also removes the familiar shell-based recovery workflow.
The usual design is a multi-stage build. A builder image includes compilers, dependency managers, and test tools. A final stage starts from a distroless runtime and receives only the compiled executable, certificates, configuration, and data files that the application actually requires. The distroless project specifically documents multi-stage Docker builds as the practical way to use distroless images.
#1 Best Overall
- Powerful Turbo Fan:CAGIWIRU Electric Air Duster have reached speed up to 130000RPM,Can efficient remove dust and debris.With LED light and Three Adjustable Speed to meet with different cleaning tasks.
- With Attached USB C Fasting Charging cable.Charing 3 hours,Enjoy up to 240 minutes of use on the lowest setting, For third speed can use for 25mins.with four charging options to meet with your needs.
- Wide Application:Upgraded attached 5 different nozzles,making it suitable for a variety of scenes, such as car,pet, pc, keyboards, and other electronic devices. It also serves for office and home clean duster.
- Handy Design & Portable:Cordless air duster electric nozzle is Light weight and small size, design and comfortable to hold and space saving, convenient to carry around. You can put it in your room or inside the car without taking up space.
- Warranty & Support: Our Electric air duster comes with 5 years warranty and 24/7 customer service. During this period, if you have any questions,pls kindly feel free to contact us.
BuildKit is the builder backend used by modern Docker builds. Its solver can execute independent graph operations concurrently, skip stages that are not needed for the selected target, transfer only changed build-context data, and manage cache entries more precisely than the legacy builder. The result is not merely a different base image: BuildKit changes how the Dockerfile graph is solved, cached, and exported.
Distroless and BuildKit solve different problems. Distroless defines the runtime contents and identity; BuildKit handles the build graph, cache, platforms, outputs, and attestations. A reliable pipeline uses both deliberately.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Prerequisites and design decisions
Install a BuildKit-capable client
docker buildx build starts a BuildKit build through Docker. Verify that Docker is installed and that the selected builder supports the platforms and outputs you need. A local build can use the default builder, while a CI system may use a dedicated container or remote builder.
Define the artifact contract
Before writing the final stage, identify the exact executable path, required shared libraries, certificate bundle, time-zone data, configuration files, writable directories, and expected user identity. A program that is statically linked may need only its executable and certificates. A dynamically linked program may require a compatible C library and loader. Assuming that a scratch-like or static image contains every runtime file is a common cause of failures.
Choose a runtime family
| Runtime choice | Use it when | Important qualification |
|---|---|---|
static |
The application is genuinely statically linked and does not need a dynamic loader or shared libraries. | Confirm static linking for every target architecture; a build that is static on one platform may not be static on another. |
base |
The program needs the general distroless base runtime and compatible shared libraries. | Copy or select all required runtime files and verify the library versions against the builder output. |
cc |
The binary uses a C or C++ runtime and dynamic linking. | The compiler, C library, loader, and final image must be ABI-compatible. |
| Language-specific distroless runtime | The application needs an interpreter or virtual machine at runtime. | Use the runtime tag that matches the language version and confirm the current image and Debian release before pinning. |
:nonroot variant |
The service can run without root privileges. | Check ownership, bind ports, volume permissions, and writable paths before enabling it. |
:debug variant |
You need a temporary shell and basic diagnostic utilities. | Use for diagnosis, not as a reason to add a shell and package manager to production. |
A working multi-stage Dockerfile
The following pattern builds a Go executable in a full image and copies it into a distroless static, non-root runtime. Adapt the language, compiler, output path, and runtime family to your application.
# syntax=docker/dockerfile:1
FROM golang:1.24 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -trimpath -o /out/app ./cmd/app
FROM gcr.io/distroless/static-debian13:nonroot
COPY --from=build /out/app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]Why each stage is present
- Syntax directive: selects the Dockerfile frontend used by BuildKit. Keep it current according to the Dockerfile features your pipeline requires.
- Dependency-only copy: copying
go.modandgo.sumbefore source code allows BuildKit to reuse the module-download layer when application files change but dependencies do not. - Explicit Linux build:
GOOS=linuxmakes the target operating system clear.CGO_ENABLED=0requests a static Go binary; verify the resulting artifact rather than assuming the flag succeeded for every dependency. - Trimmed output:
-trimpathremoves local filesystem paths from the binary, which helps reproducibility. - Final stage: only
/out/appcrosses the stage boundary. Build tools, module caches, source code, and test files stay out of the runtime image. - Non-root identity: the image’s non-root user is selected explicitly. The application must not require root-owned writable paths or privileged operations.
- Exec-form entrypoint: the process receives signals directly. There is no shell to mediate startup or signal handling.
Runtime files that may need deliberate handling
HTTPS clients commonly need a CA certificate bundle. Services that format local times may need time-zone data. Dynamic binaries need their loader and shared libraries. Applications may also require templates, migration files, static assets, or a specific writable directory. Add only the files you can justify, and test them in the final stage rather than in the builder stage.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Rank #2
- Screen Cleaner is Your Screen’s New Bestfriend! - EVEO is proud to present a screen cleaner that’s perfectly suited for your TV. Meet your new screen cleaner, computer screen cleaner, laptop cleaner, iPad cleaner, Macbook,tv cleaner or any other electronic device. Our screen cleaner spray and wipe along with the included plush microfiber cloth, easily removes dust, fingerprints & other smudges on the screen’s surface. Clean effectively for a streak-free screen
- Gentle on your Screens - Our screen cleaner spray and wipes is compatible to be used even for the most sensitive LCD, LED, CRT, and OLED screens in proper use. Be at ease knowing that this product is compatible with all the major brands: LG, SONY, Samsung, Sharp, iPad, iPhone, Android screens, Kindle, PC monitors - we’ve got you covered! Can be used as LCD screen cleaner, tv cleaner, smart tv screen cleaner, and more
- Premium Super Soft Plush Microfiber Cloth - Included in this efficient screen cleaning kit. This screen cleaner spray and wipe has our signature plush microfiber cloth specially designed to comply with screens and monitors and leave them streak-free. Has been shown to effectively absorbs stubborn stains, zero streaks, and no fiber shedding. Always use this together with our screen cleaner for the best results
- Easy-to-Use Screen Cleaner Kit + microfiber cleaning cloth - The EVEO Screen Cleaning Kit will easily be your new favorite tool when it comes to taking care of the things you love most, quick and easy solution for a streak-free screen. Simply screw on the sprayer gun on the screen cleaner bottle. Spray the cleaning liquid onto the microfiber cloth, then wipe the screen until desired cleanliness & shine is achieved.
- Quality Screen Care Kit Worth Purchasing - Enjoy a convenient Screen Cleaner anytime, anywhere you need it. Your satisfaction is our top priority. We stand behind the quality of our products and that’s why, you shouldn’t be worrying at all. We manufacture the Best Screen Cleaner. and can be used for laptop cleaning kit, laptop screen cleaner, tv screen cleaner for smart tv. MacBook screen cleaner, monitor cleaner or screen cleaner spray for electronic devices with microfiber cleaning cloth
Build the image with buildx
Multi-platform publish with cache and attestations
This command builds one manifest for two platforms, stores a reusable cache in a registry, emits maximum-detail provenance, generates an SBOM, and pushes the result:
docker buildx build
--platform linux/amd64,linux/arm64
--tag registry.example.com/acme/app:1.0.0
--cache-from type=registry,ref=registry.example.com/acme/app:buildcache
--cache-to type=registry,ref=registry.example.com/acme/app:buildcache,mode=max
--provenance=mode=max
--sbom=true
--push .--platform requests a multi-platform result. The builder must be able to execute or emulate each requested architecture, and the application must be tested on each one. --tag names the output. The registry cache options allow separate builds—particularly CI jobs—to reuse unchanged layers. mode=max exports more cache records than the minimal mode.
--push sends the manifest and platform images directly to the registry. A multi-platform result generally cannot be loaded into a single-platform local image store as one ordinary image, so use a registry output for integration testing or select one platform for local loading.
--provenance=mode=max requests detailed build provenance. --sbom=true requests an SBOM attestation. Availability and defaults can vary with the Docker and BuildKit versions in your environment, so inspect the build output and registry metadata rather than assuming an attestation was attached.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Local iteration and target selection
For a quick local build, omit --push and choose an output supported by the selected builder. If the Dockerfile defines a debug or test stage, select it with --target:
docker buildx build --target debug --tag acme/app:debug --load .The --load output imports a single-platform result into the local Docker image store when the builder supports that exporter. For a production image, use the final stage and avoid retaining debug tools in the published tag.
Rank #3
- 【Large size】：Measuring 800 x 300 mm/ 31. 5×12 inches, which is wider and taller than others. Large mouse pad can perfectly fit your keyboard and mouse of any size, and there is also ample space for peripherals such as phones, tablets, etc.
- 【LED backlight mouse pad】：Blade Hawks RGB mouse pad provides 7 static modes and 7 dynamic modes will give you the options you are looking for. Power-off memory function remembers the last lighting mode you selected. The super glow fiber Chroma will give you a colorful gaming setup that you want.
- 【Anti-slip rubber base】：Made from Natural rubber, this gaming mousepad will firmly grip your desktop, allowing you to enjoy the ultimate precision in the games you are most passionate about. It also comes with a texture that enhances this ability even further.
- 【Smooth and waterproof surface】: Micro-textured cloth surface, for extremely precise mouse control and a smooth movement. When liquid splashes on the gaming mouse pad, it forms water droplets and slides down. Will not delay your work or gameplay.
- 【Plug and play】: This mouse and keyboard pad is powered by USB, plug and play, no driver required. One button control light modes. Press one time to change the lighting mode, press twice to change the brightness, press and hold about 3 seconds turn ON/OFF.
Separate test and debug stages
A useful Dockerfile can contain a test stage based on the builder image and a debug stage based on the matching distroless :debug variant. The production stage remains tool-free. BuildKit can skip unused stages, so selecting the production target does not require exporting every intermediate stage.
How to create a production stage safely
- Build and test in the full builder: run unit tests, linters, and artifact checks before the final copy. Keep test dependencies in earlier stages.
- Inspect the artifact: determine whether it is static or dynamically linked, which architecture it targets, and whether it embeds or expects external data.
- Select the matching runtime: use
staticonly for a truly static executable; usebase,cc, or a language runtime when compatibility requires it. - Copy required files explicitly: copy the executable first, then certificates, time-zone data, assets, and configuration defaults that the application demonstrably needs.
- Set identity and filesystem behavior: use a
:nonroottag or an explicit non-root user when possible. Create or designate writable directories intentionally; do not make the whole filesystem writable. - Define direct process startup: use JSON-array
ENTRYPOINTorCMDso the application receives termination signals and can shut down gracefully. - Exercise the final image: run health checks, startup, shutdown, TLS connections, time-zone operations, file writes, and migrations from the exact image that will be deployed.
Debugging a distroless container with no shell
A production distroless container is not expected to respond to sh or bash. Trying to install a shell at runtime usually fails because there is no package manager, and adding one permanently defeats the reason for choosing distroless.
Use the matching debug image
Distroless publishes :debug variants. Replace the production image reference with the matching debug tag during diagnosis and launch the shell explicitly:
docker run --rm -it --entrypoint=sh gcr.io/distroless/static-debian13:debugUse the same application files, architecture, and runtime family as the production image wherever possible. A debug image is a diagnostic instrument, not proof that the production image contains a shell or the same extra utilities.
Build a dedicated debug target
When the application itself must be present, define a separate target that copies the same artifact into a debug runtime. Build it with --target debug, inspect processes and files, then rebuild the final production target. Keep the target name and approved diagnostic procedure in your operations documentation.
Diagnose without entering the container
- Read container logs and orchestrator events for the exact exit code and startup error.
- Override the entrypoint locally to run the application with diagnostic flags in a debug target.
- Inspect the image configuration, manifest platforms, user, entrypoint, and environment from registry-aware tooling.
- Run a temporary helper container that shares the network or volumes when the platform allows it, rather than modifying the production image.
- Reproduce the failure in the builder or test stage, where compilers and inspection tools are available, then verify the fix in the minimal final stage.
SBOM and provenance with BuildKit
BuildKit can generate an SBOM as SPDX JSON wrapped in an in-toto attestation. Docker describes SBOM and provenance attestations as metadata attached to build results. Treat these records as part of the release artifact, not as a replacement for runtime testing or vulnerability triage.
Rank #4
- 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
- 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
- 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
- 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
- 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.
Understand SBOM scope
By default, the SBOM scan covers the final build result. If you also need visibility into files copied from the build context or packages present only in intermediate stages, set the documented BuildKit options BUILDKIT_SBOM_SCAN_CONTEXT=true and/or BUILDKIT_SBOM_SCAN_STAGE=true. Intermediate-stage coverage is useful for auditing build dependencies even though those dependencies are absent from the shipped image.
Verify the metadata after publishing
Inspect the pushed manifest and attached attestations with registry-aware tooling. Confirm that the digest, platform list, provenance, and SBOM belong to the release you intend to deploy. A successful build log alone does not establish that a registry retained every requested attestation.
Rootless and daemonless BuildKit in CI
Standalone BuildKit can run without a Docker daemon. In GitLab-style rootless pipelines, a moby/buildkit:rootless image, buildctl-daemonless.sh, and registry output provide a pattern for multi-platform builds when privileged Docker access is not acceptable.
Rootless execution changes the available kernel features, filesystem permissions, and credential setup. Configure registry authentication for the CI job, make sure the builder can access the source context, and test cache export and multi-platform output in the same security profile used by production pipelines. Do not assume a Docker-daemon build and a rootless build have identical performance or snapshot behavior.
Verification checklist before release
- Confirm the final stage contains only the executable, required configuration, certificates, data, and explicitly needed runtime libraries.
- Run as the non-root user when the application supports it. Verify ownership of every writable directory and mounted volume.
- Test every platform in the published manifest, with special attention to dynamically linked binaries and architecture-specific dependencies.
- Exercise health checks, readiness behavior, graceful termination, and timeout handling. There is no shell fallback for a failed command.
- Test outbound TLS and any operation that depends on CA certificates or time-zone data.
- Keep a separate debug image or target and document who may use it, how it is selected, and how it is removed after diagnosis.
- Inspect the manifest digest and attached provenance and SBOM attestations in the destination registry.
- Record the builder, Dockerfile frontend, base-image tags or digests, dependency lockfiles, and build arguments needed to reproduce the result.
Troubleshooting common BuildKit and distroless failures
“How do I build a distroless Docker image with BuildKit?”
Use a multi-stage Dockerfile and invoke docker buildx build. Make the final stage distroless, copy the artifact from the builder with COPY --from=..., set a direct entrypoint, and select an output such as --push or --load. If the command is unexpectedly using legacy behavior, inspect the selected builder and Docker installation rather than adding runtime tools to the image.
“How do I debug a distroless container with no shell?”
Do not expect docker exec ... sh to work. Build or run the matching :debug variant with --entrypoint=sh, or select a dedicated debug target. Use logs, events, image configuration, and helper containers for production-safe diagnosis.
Best Value
- 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
- 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
- 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
- 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
- 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.
The container exits immediately
Check that the entrypoint path exactly matches the copied file, the file has the expected executable format and architecture, and the user can read and execute it. For a dynamic binary, verify that the loader and shared libraries exist in the chosen runtime family. An absent shell is not itself an application failure.
TLS requests fail inside the final image
Check for a CA certificate bundle in the runtime image and confirm that the application is using the expected certificate path. A builder image may have certificates that were never copied into the distroless stage.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsThe application cannot write files
Running as nonroot commonly exposes paths that were writable only because the builder ran as root. Create the required directory in an appropriate stage, set ownership deliberately, or move transient data to a writable mounted volume. Avoid making the entire image writable.
One platform works and another fails
Inspect the manifest and test each platform separately. Verify architecture-specific compilation, dynamic-loader compatibility, native dependencies, certificates, and any build argument that changes per-platform output. A successful amd64 build does not validate an arm64 runtime.
Cache misses make CI builds slow
Keep stable dependency copies before frequently changing source files, use registry-backed --cache-from and --cache-to, and avoid sending unnecessary context. BuildKit can transfer only changed context data, but an oversized or unstable context still reduces cache usefulness.
The SBOM does not list build dependencies
The default scan covers the final result. Enable BUILDKIT_SBOM_SCAN_CONTEXT=true for context coverage and/or BUILDKIT_SBOM_SCAN_STAGE=true for intermediate stages, then verify the resulting attestation in the registry.
Free tools Windows power users keep installed
One-click scans. No signup required.
Trade-offs: when this design is appropriate
| Decision axis | Distroless with BuildKit | General-purpose runtime image |
|---|---|---|
| Runtime compatibility | Requires deliberate selection of libraries, certificates, data, and user permissions. | Usually includes more defaults, so applications may work with less preparation. |
| Attack surface and identity | Fewer tools and a straightforward non-root variant reduce included functionality and post-compromise options. | Extra shells and package managers increase convenience and contents that must be maintained. |
| Debuggability | Production has no shell; debug variants and external diagnostics are required. | Interactive troubleshooting is simpler inside the running container. |
| Reproducibility and evidence | Explicit stage boundaries, cache controls, provenance, and SBOM attestations make the release easier to inspect. | Evidence is still possible, but a larger mutable userland creates more dependencies to track. |
| Build and delivery performance | BuildKit can parallelize independent work, reuse precise cache entries, skip unused stages, and publish platform manifests directly. | Build behavior depends on the same builder, but a larger runtime does not provide those BuildKit capabilities by itself. |
There is no universal image-size, build-time, or vulnerability-count guarantee. The outcome depends on the language, dependency graph, base-image release, target platforms, cache state, and application files. Measure those properties for your own build and keep the production image minimal only when the resulting compatibility and operational checks pass.
Quick Recap
A practical release sequence
- Pin or otherwise record the builder and base-image versions appropriate for your change-control policy.
- Build the artifact and run tests in the builder stage.
- Inspect linking, architecture, certificates, time-zone requirements, and writable paths.
- Build the final distroless target locally for one platform and exercise startup, health, TLS, file access, and shutdown.
- Build all release platforms with
docker buildx build, exporting registry cache and requested attestations. - Push the manifest, inspect its digest and metadata, and test deployments from that immutable digest.
- Retain the debug target and documented diagnostic path without publishing it under the production tag.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
