LayerLens

Inspiration

Dockerfiles quietly accumulate bad habits. A team can go months without revisiting one, and by then the image is bloated, builds are slower than they should be, security basics like non-root users are missing, and nobody notices until CI drags or a scan fails. We wanted to build something that makes container hygiene visible early, understandable to humans, and actionable inside the workflows developers already use.

What it does

LayerLens analyzes Dockerfiles and container images across four surfaces:

• A web app where users can submit an image name and Dockerfile, run live image-layer analysis, and get an AI-generated explanation with an improved Dockerfile.
• A fast CLI, layerlens, that statically scans a single Dockerfile or an entire repository without building images or requiring Docker.
• An optional --explain mode that turns findings into plain-English fixes and a patched Dockerfile using an LLM.
• CI automation that detects when a pull request makes a Dockerfile worse, posts a comment directly on the PR, and can fail the build on regression.

In practice, LayerLens catches issues like oversized base images, missing multi-stage builds, root users, broad COPY . . usage, stale package caches, missing health checks, and accidentally copied sensitive files such as .env.

How we built it

We built LayerLens as a full-stack project with a shared analysis story across multiple interfaces:

• The web frontend is deployed on Vercel and gives users a simple interface to launch scans and review results.
• The backend is a Flask service that can shell out to Dive for real image-layer analysis when an image name is provided.
• The static scanning engine powers the CLI and CI workflow, letting us analyze Dockerfiles directly from source text with no image build required.
• The AI explanation layer uses Featherless.ai through an OpenAI-compatible API to convert raw findings into readable explanations, exact fixes, and a rewritten Dockerfile.
• GitHub Actions ties the scanner into pull requests so regressions show up where developers already review code.

That combination let us keep the core scanner fast and deterministic while using AI only as an optional explanation layer on top.

Challenges we ran into

One challenge was balancing live image analysis with developer ergonomics. Running Dive against real images produces richer insight, but it introduces infrastructure complexity and network/runtime variability. We also had to make sure the product still delivered value when Docker was unavailable, which is why the static scanner became a first-class part of the system rather than a fallback.

Another challenge was making the AI useful without making it mandatory. We did not want the whole product to depend on an external model call, so we separated deterministic scanning from optional explanation. That meant designing outputs that are helpful on their own, while still giving the model enough context to generate fixes that feel concrete instead of generic.

Accomplishments that we're proud of

• We turned one container-analysis idea into a real multi-surface product: website, CLI, CI integration, and machine-readable output.
• We built a scanner that works instantly on raw Dockerfiles and whole repositories, without requiring a Docker daemon.
• We got automated PR regression comments working end to end, so problems show up directly in code review instead of buried in logs.
• We kept the AI layer optional, which makes the core product fast, cheap, and usable offline for local scanning and CI gating.
• We shipped something demoable with real live behavior instead of mockups: real scans, real PR comments, and real model-generated rewrites.

What we learned

We learned that the most compelling part of the project was not just “AI for Docker,” but meeting developers where they already work. A polished website is great for demos, but the highest-value workflow is catching issues locally and in pull requests before an image is ever built.

We also learned that trust matters. Developers are much more willing to use AI assistance when the underlying findings come from a deterministic engine, and the model is used to explain and accelerate fixes rather than to invent the diagnosis from scratch.

What's next for LayerLens

Next, we want to expand the rule engine, improve scoring, and make the CI integration even more useful with stronger diff-aware reporting and configurable policy thresholds. We also want to improve the web experience with more robust hosted analysis, richer visualization of layer waste, and saved scan history for teams tracking improvement over time.

Longer term, we see LayerLens becoming a full Dockerfile quality assistant: part linter, part regression guardrail, and part teaching tool for container best practices.

Built With

• docker
• featherless.ai
• flask
• mern
• python