Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
What is the primary benefit of a multi-stage Docker build for a Node.js application, compared to a single-stage build?
💻 Code Challenge | +75 XP
Write a multi-stage Dockerfile with a build stage compiling TypeScript and installing all dependencies, and a minimal runtime stage using node:20-slim that copies only the compiled output and production dependencies, running as a non-root user.
A security scan of a production container image flagged it as unnecessarily large and running as root, with the TypeScript compiler and devDependencies still present in the final image. Reorder the steps to fix this using multi-stage builds.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Using a single-stage Dockerfile that ships build tools and devDependencies to production
// Wrong: single stage, everything ships to production
FROM node:20
RUN npm install // includes devDependencies
RUN npm run build
// Correct: multi-stage, only compiled output + prod deps ship
FROM node:20 AS builder
// ...build steps...
FROM node:20-slim
COPY --from=builder /app/dist ./distThe Solution //
Everything installed and used during the build process — the TypeScript compiler, testing frameworks, other devDependencies — ships in the final image unnecessarily, increasing image size, slowing deploys, and expanding the container's attack surface with packages the running application never actually needs.
The Error //
Running the containerized application process as the default root user
// Wrong: runs as root by default
FROM node:20-slim
CMD ["node", "dist/server.js"]
// Correct: runs as a dedicated non-root user
RUN addgroup --system app && adduser --system --ingroup app app
USER app
CMD ["node", "dist/server.js"]The Solution //
A container running as root, combined with any container escape vulnerability, gives an attacker root-level access on the underlying host system — creating and switching to a dedicated non-root user in the runtime stage is a standard, important security hardening step with essentially no downside.