Loading page content
Paste a Dockerfile and get the problems in it, most serious first: containers that run as root, secrets written into image layers, base images that are not pinned, and instructions that make the image larger or the build slower than it needs to be.
SponsorThis spot is open to one DevOps or AI tooling company at a time. Ask about sponsoring
116 of 118 run entirely in your browser (Weather Widget uses Open-Meteo; What's My IP asks this site's server).
Share on XShare on LinkedInA Dockerfile that builds is not the same as a Dockerfile that is safe to run. The three findings that matter most are quiet ones. With no USER instruction the process runs as root, so a bug in the application becomes root inside the container. An ENV or ARG that holds a token is stored in the image layers, where anyone who can pull the image can read it with docker history. And RUN curl ... | sh executes whatever that URL serves on the day of the build, as root.
The rest is about builds you can repeat and images that stay small. FROM node:latest means two builds of the same commit can produce different images. apt-get update in its own RUN is cached, so a later install uses a stale index. Copying the whole source tree before installing dependencies throws away the dependency layer on every code change. A single-stage build ships the compiler and dev dependencies to production. The linter checks the final stage for runtime problems, since that is the one that ships.
Paste a Dockerfile. It is checked for security problems (running as root, baked-in secrets, unverified downloads), unrepeatable builds, and layers that make the image bigger or the build slower. Nothing leaves your browser.
There is no USER instruction in the final stage, so the process runs as root. Create an unprivileged user and switch to it before CMD.
line 3API_TOKEN is stored in the image layers and visible to anyone who can pull the image or read its history. Pass it at run time, or use a build secret (RUN --mount=type=secret).
line 9Whatever that URL serves at build time runs as root in your image. Download the script, verify its checksum, then run it.
line 1node:latest resolves to whatever was published most recently, so two builds of the same commit can differ. Pin a version tag such as node:22-slim, or a digest.
line 7The update layer is cached, so a later install can use a stale package index and fail or install old versions. Put update and install in the same RUN.
line 8Add --no-install-recommends to keep packages you did not ask for out of the image.
line 8End the same RUN with rm -rf /var/lib/apt/lists/* so the index is not stored in the layer.
line 10npm ci installs exactly what the lockfile says and fails if it is out of date, which is what a build should do.
line 6The whole source tree is copied before dependencies are installed, so any file change discards the cached install layer. Copy the manifest and lockfile first, install, then COPY the rest.
line 14The process runs under /bin/sh -c, so it does not receive SIGTERM and the container is killed after the stop timeout. Use the JSON form: CMD ["executable", "arg"].
The image is built and run in one stage, so compilers and dev dependencies end up in production. Use a multi-stage build and copy only the built output into a slim final stage.
Docker and Compose cannot tell a hung process from a healthy one. Skip this if the image only runs on Kubernetes, which uses its own probes.