At Minimus, we’ve historically talked about how simple it is to swap out your existing base images and immediately replace them with Minimus images to achieve continuously hardened, near-zero CVE container images.
With the release of our AI Migration skills, that migration path becomes even easier. Teams using AI tooling can now take even complex Dockerfiles, analyze them against Minimus images, and get both practical migration guidance and a converted Dockerfile that preserves application compatibility while improving the security baseline.
To see this in action, I’ve taken a sample application with a multi-stage Dockerfile using a mix of Node and Python-based images to build multiple components of an application.
This is the kind of migration that often looks simple at first, but can quickly involve hidden assumptions around package managers, shell access, user permissions, health checks, and runtime dependencies.
Starting Dockerfile:
FROM node:20-alpine AS frontend
WORKDIR /frontend
COPY frontend/package*.json ./
RUN npm install
COPY frontend/ .
RUN npm run build
FROM python:3.11-alpine
WORKDIR /app
RUN apk add --no-cache \
gcc \
musl-dev \
libpq-dev \
curl \
bash
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY api/ .
COPY --from=frontend /frontend/build ./static
ENV FLASK_ENV=production
ENV PORT=5000
EXPOSE 5000
HEALTHCHECK --interval=30s --timeout=5s \
CMD curl -f http://localhost:5000/health || exit 1
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "4", "app:app"]
Every Minimus Image card comes attached with a sample prompt that can be immediately pasted into your local AI agent of choice, providing specific instructions for analyzing and converting Dockerfiles to use Minimus images.
After pasting in the prompt to your session, the agent (as instructed) will ask you for the Dockerfile(s) you’d like analyzed and which respective Minimus images you’d like included. After informing my agent to keep the same types and providing the Dockerfile location, the agent went to work (and quickly did more to provide immediate value than provide just general swaps of the base images).
The AI agent pulled and inspected the relevant images, then validated several important things:
After providing an executive summary and explaining why all of these changes mattered and the impact, the AI Agent provided a new Dockerfile with these recommendations included. It also reported that it had successfully built and tested the updated file.
Read on for a full breakdown of the actual results.
FROM reg.mini.dev/node:20-dev AS frontend
...
FROM reg.mini.dev/python:3.11-dev AS builder
...
FROM reg.mini.dev/python:3.11
COPY --from=builder /app/venv /app/venv
COPY --from=frontend /frontend/build ./static
Why this matters: The three multi-stage build recommendation format gives you dev images used to build your application with the same minimal vulnerability footprint and the ability to copy them over into a final runtime hardened production image with only the necessary artifacts needed to run the application.
Why this matters: This is an important benefit of the AI migration flow: it does not just replace images. It can identify old build assumptions and remove unnecessary packages that increase image size and attack surface.
FROM reg.mini.dev/python:3.11-dev AS builder
USER root
WORKDIR /app
RUN chown -R 1000:1000 /app
USER 1000
RUN python -m venv venv
ENV PATH="/app/venv/bin:$PATH"
COPY --chown=1000:1000 requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
Why this matters: This is an important benefit of the AI migration flow: it does not just replace images. It can identify old build assumptions and remove unnecessary packages that increase image size and attack surface.
[1/3] STEP 4/6: RUN npm install
npm error code EACCES
npm error path /frontend/node_modules
npm error errno -13
Why this matters: The agent recommended using the documented pattern: temporarily escalate to root, create or change ownership of the required directories, then switch back to the non-root user.
This allows the migrated image to preserve Minimus’ hardened non-root defaults without breaking the application build.
FROM reg.mini.dev/node:20-dev AS frontend
USER root
WORKDIR /frontend
RUN chown -R 1000:1000 /frontend
USER 1000
COPY --chown=1000:1000 frontend/package*.json ./
RUN npm install
COPY --chown=1000:1000 frontend/ .
RUN npm run build
After adding this, the build proceeded and produced a working build/ output — verified by serving it through the final container and confirming GET / returned the compiled React index.html.
# api/healthcheck.py
import sys, urllib.request
try:
with urllib.request.urlopen("http://localhost:5000/health", timeout=3) as r:
sys.exit(0 if r.status == 200 else 1)
except Exception:
sys.exit(1)
Sample stdlib-only health probe
HEALTHCHECK --interval=30s --timeout=5s \
CMD ["python", "healthcheck.py"]
Launching the health probe with the python CMD as part of execution at end of Dockerfile
Why this matters: Where this application runs impacts changes made, as there are benefits to implementing running in standalone VMs versus orchestrators like Kubernetes. The agent has added value here in bringing this awareness up on the chance it was not previously taken into account.
That format is compatible with Minimus distroless images and follows the required entrypoint pattern.
FROM reg.mini.dev/node:20-dev AS frontend
USER root
WORKDIR /frontend
RUN chown -R 1000:1000 /frontend
USER 1000
COPY --chown=1000:1000 frontend/package*.json ./
RUN npm install
COPY --chown=1000:1000 frontend/ .
RUN npm run build
FROM reg.mini.dev/python:3.11-dev AS builder
USER root
WORKDIR /app
RUN chown -R 1000:1000 /app
USER 1000
RUN python -m venv venv
ENV PATH="/app/venv/bin:$PATH"
COPY --chown=1000:1000 requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
FROM reg.mini.dev/python:3.11
WORKDIR /app
COPY --from=builder /app/venv /app/venv
ENV PATH="/app/venv/bin:$PATH"
COPY api/ .
COPY --from=frontend /frontend/build ./static
ENV FLASK_ENV=production
ENV PORT=5000
EXPOSE 5000
HEALTHCHECK --interval=30s --timeout=5s \
CMD ["python", "healthcheck.py"]
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "4", "app:app"]
This migration showed several important benefits of using AI Migration Skills with Minimus:
The most important takeaway is that AI Migration Skills make the migration process both faster and smarter. They do not simply suggest a new FROM line. They help evaluate the Dockerfile, validate image compatibility, identify requirements for hardening, and recommend practical changes that reduce unnecessary complexity.
As the consumer of this information, I do not need to accept every recommendation. I can ask the AI agent to account for additional infrastructure or deployment considerations specific to my environment. For example, if I need to keep a shell, run as root, or support a specific operational pattern, I can guide the agent accordingly.
However, if my goal is to achieve a more secure outcome in addition to moving to near-zero CVE images, the AI Migration Skills process helps me get there faster.
AI Migration is more than a workflow for migrating your existing applications to Minimus. It provides a way to validate existing build structures, update Dockerfiles, and quickly transition to hardened images.
Want to know more or try this out? AI Migration Skills are available on Minimus image skill cards as part of Minimus Community Edition. Start migrating Dockerfiles to free hardened container images from the Minimus gallery, without registration or procurement friction. Try out the python AI skills migration here.
.svg)
.svg)
.svg)
.svg)
