I’ve been building every single day, but this one hit differently. I went deep into Docker multi-stage builds, and I finally understand why every production team relies on them.
What I Built
I took a React application and containerized it in two different ways:
Single-Stage Build
Node.js installs everything, builds the app, and serves it from one image.
Final image size: 778 MBMulti-Stage Build
Stage 1: Node.js builds the app
Stage 2: Nginx serves only the compiled output
Final image size: 94.1 MB
I used to think Docker was just about running apps in containers. Now I see the deeper engineering principles:
• Build environment ≠ runtime environment.
Node.js, npm, and build tools have no place in a production container serving static files.
• Layer caching is a discipline.
Copying package.json before source code means Docker reuses cached npm installs unless dependencies change, saving real time and real money in CI/CD.
• Smaller images matter.
Less storage, fewer CVEs, faster pushes/pulls, quicker startup times—it all compounds in production.
• Nginx config is not optional for React.
Without a proper try_files fallback, client-side routing breaks on refresh. I tested it. I saw it. I fixed it.
What I’ve Built and Deployed So Far
• Launched and configured AWS EC2 instances
• Automated Docker installation using cloud-init User Data
• Deployed a static website inside a Docker container on port 80
• Built and compared single-stage vs multi-stage Docker images
• Configured Nginx to serve a React app with routing and cache headers
• Debugged real-world issues: port conflicts, container name clashes, missing keys, permission errors
Every one of these was built live, broken at least once, fixed, and shipped.
That’s the only way I know how to learn.
I want to sincerely thank my mentors, Pravin Mishra, Praveen Pandey, Abhishek Makwana, Mobarak Hosen, Onuche Paul and Nkechi Anna Ahanonye
Top comments (0)