Dockerfile & Docker-Compose Builder
What is a Dockerfile Builder?
A good Dockerfile produces small, secure and fast-building images; a careless one produces huge images that run as root and rebuild everything on each code change. This builder generates a Dockerfile and matching docker-compose.yml from a few choices, following current best practices.
How to use it
- Choose the runtime and version, such as Node.js 20 or Python 3.12.
- Set the working directory, exposed port, start command and build steps.
- Enable options such as multi-stage build, non-root user and health check.
- Copy both files into your project.
Example: Node.js multi-stage Dockerfile
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]Best practices built in
- Layer caching: copy dependency manifests and install before copying source, so code changes do not reinstall dependencies.
- Multi-stage builds: compilers and dev dependencies stay in the build stage, keeping the final image small.
- Non-root user: limits damage if the application is compromised.
- Pinned base images: use a specific version tag instead of
latest. - .dockerignore: exclude
node_modules,.gitand.envfrom the build context.
Checking the result
Build with docker build -t myapp ., check the size with docker images, and scan for vulnerabilities with docker scout cves myapp or Trivy.
Frequently Asked Questions
What is a multi-stage Docker build?
A Dockerfile with several FROM stages. Build tools live in early stages, and only the finished output is copied into the small final image.
Why should containers not run as root?
If an attacker exploits the application, a non-root user limits what they can do inside the container and on the host.
Why copy package.json before the source code?
Docker caches each layer. Installing dependencies first means they are only reinstalled when the manifest changes.
Should I use Alpine base images?
Alpine images are small, but use musl instead of glibc, which can break some native modules. Slim Debian images are a safe alternative.