𝗙𝗿𝗼𝗺 𝗮 𝗟𝗼𝗰𝗮𝗹 𝗥𝗲𝗮𝗰𝘁 𝗔𝗽𝗽 𝘁𝗼 𝗮 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻-𝗥𝗲𝗮𝗱𝘆 𝗗𝗲𝘃𝗢𝗽𝘀 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁

A Weekly Milestone in Learning How Production Actually Works

Deploying a React application is easy.

Deploying it the right way, with validation, monitoring, and recovery, is where DevOps really begins.

This week marked a major milestone in my DevOps journey. I intentionally progressed from deploying a basic React application to deploying a fully professional, production-ready portfolio website on an AWS Ubuntu server, served with Nginx and validated through real production maintenance drills.

This wasn’t just about getting an app online.

It was about learning how to think like a production engineer: anticipating failures, validating configurations, and ensuring reliability before users are impacted.

Project Overview

This milestone was completed in two progressive stages, each building on the previous one.

Stage 1: Initial Deployment

I deployed a basic React application to understand the full lifecycle, from source code to a live server.

Stage 2: Professional Portfolio Deployment

I then deployed a polished portfolio website using the same production principles, validating that the setup was reusable, reliable, and scalable.

Stack Used

• AWS EC2 (Ubuntu)
• Nginx (Web Server)
• React (Frontend)
• Linux CLI & systemd

Live Applications

• React App: http://18.191.168.154
• Professional Portfolio: http://3.15.11.80

What I Did (Step by Step)

1. Deploying the React Application from Source

I installed Node.js on the server, built the React app for production, and deployed the optimized build files.

This step helped me clearly understand the difference between development builds and production-ready builds, and why serving static assets efficiently matters in real-world deployments.

2. Configuring Nginx for Production

I configured Nginx to serve the React build on port 80, ensuring:

• Correct root and index configuration
• Proper handling of SPA routing
• Public accessibility via the server’s IP address

Before restarting Nginx, I validated every configuration change using:

nginx -t

This single command reinforced an important lesson:
most production outages are caused by skipping validation.

3. Ownership Proof and Integrity Checks

I added ownership proof files and verified that the deployed content matched the intended React build.

Get Stephcollection’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This highlighted the importance of:

• Clear ownership tracking
• Content integrity verification
• Confidence during audits, reviews, or troubleshooting

4. Production Maintenance Drill (OPS Checklist)

To simulate real production responsibility, I completed a hands-on Production Maintenance Drill covering multiple operational areas.

Networking & Access Checks

• Verified IP addresses and network interfaces
• Checked default routes and DNS resolution
• Confirmed open ports (Nginx on 80, SSH on 22)
• Ensured the server was reachable from the public internet

Service Health & Validation

• Confirmed Nginx service status
• Verified boot persistence
• Checked master and worker processes
• Ensured Nginx was correctly bound to port 80

Logs & Request Tracing

• Monitored Nginx access and error logs
• Reviewed systemd logs for hidden service-level issues

One key realization here:
a website can appear healthy while logs silently report critical problems.

5. System Resource Health Monitoring

I checked:

• CPU and memory usage
• Disk utilization
• /var directory consumption

A major takeaway:
disk space is one of the highest-risk resources in production.
A full disk can break logging, crash services, or cause silent failures that are hard to diagnose.

6. Incident Simulation and Recovery

To build real on-call confidence, I intentionally introduced a small Nginx configuration error.

I then:

• Validated the failure using nginx -t
• Corrected the configuration
• Safely restarted Nginx
• Confirmed recovery using curl and browser checks (HTTP 200/304 responses)

This made one thing very clear:

Incident recovery is a skill that must be practiced, not just understood

Key Lessons Learned

• Pre-deployment validation prevents avoidable downtime
• nginx -t is non-negotiable in production
• Logs often reveal issues before users notice them
• Disk usage monitoring is critical for stability
• Practicing failure and recovery builds real DevOps confidence
• Security and reliability checks are not optional

Why This Milestone Matters

This week pushed me beyond theory into real production thinking.

I’m now more confident in:

• Linux server administration
• Nginx production configuration
• Deployment validation
• Incident response and recovery

These are the skills that separate deploying an app from operating a system.

Final Note

This milestone was completed as part of the DevOps Micro Internship (DMI) — Cohort 2, guided by Pravin Mishra.

If you’re starting your DevOps journey, hands-on projects like this make all the difference.

Thanks for reading, more production stories coming soon!