Dockerfile Linter

No — this is a lightweight, browser-only subset of the kind of checks a tool like Hadolint performs. It's useful as a quick first pass while editing, but for CI-grade Dockerfile linting with the full shellcheck-backed rule set, a dedicated tool like Hadolint is more thorough.

A major-version-only tag like "node:18" will silently pick up new minor/patch releases (and different underlying OS package versions) on every fresh pull, which can make a passing build fail later with no code changes on your end. Pinning to something like "node:18.19-bookworm-slim" or a specific digest makes builds reproducible.

Docker caches each RUN instruction as its own layer. If "apt-get update" is cached from an old layer but "apt-get install" runs later (in a different or rebuilt layer), you can install packages against a stale, no-longer-available package index. Combining them into one RUN with && avoids this class of bug entirely.

If a Dockerfile has only one FROM stage but clearly installs build tooling (like a compiler, npm/pip, or a build command), that tooling typically isn't needed at runtime. A multi-stage build lets you compile in one stage and copy only the final artifact into a slim runtime stage, often shrinking the final image substantially.

No — it only performs static text/line pattern analysis in your browser. It doesn't invoke Docker, doesn't validate that the Dockerfile actually builds successfully, and doesn't scan the resulting image for vulnerabilities.