Forem: Odoworitse Afari

# Building a Three-Tier Architecture on Azure

Odoworitse Afari — Sat, 14 Mar 2026 00:10:26 +0000

Introduction

Some assignments teach you tools. This one taught me how to think.

As part of DMI Cohort 2, I was tasked with deploying the Book Review App — a Next.js frontend, Node.js backend, and MySQL database — in a fully production-style three-tier architecture on Azure. No step-by-step guide. Just the requirements, Azure documentation, and whatever problem-solving I could bring.

This post covers what I built, the real challenges I hit, and the mental shift this assignment forced.

What Is a Three-Tier Architecture?

A three-tier architecture separates an application into three distinct layers:

Tier	What it does
Web Tier	Serves the frontend. Handles HTTP requests from users.
App Tier	Business logic. Processes requests, talks to the database.
Database Tier	Where the data lives. Never exposed to the internet.

Each tier lives in its own subnet with its own security rules:

Web tier → can talk to App tier
App tier → can talk to Database tier
Nothing else

This isolation means a breach in one layer doesn't automatically compromise the others.

Step 1: Designing the VNet and Subnets

I created a custom VNet with the CIDR block 10.0.0.0/20. The assignment called for 6 subnets across 2 Availability Zones, but my Azure free subscription had quota limits — so I provisioned 4 subnets and documented the constraint honestly.

Subnet	CIDR	Tier
`web-public`	`10.0.2.0/24`	Web (public)
`app-vm-1`	`10.0.6.0/24`	App (private)
`db-vm-1`	`10.0.10.0/24`	Database (private)
`db-vm-2`	`10.0.12.0/24`	Database (private)

The key principle: only the web subnet is public. Everything else is private and unreachable from the internet directly.

Step 2: NSGs and Load Balancers

I configured chained NSGs to enforce strict traffic rules across tiers:

Web Tier NSG: Allow inbound HTTP on Port 80
App Tier NSG: Allow inbound Port 3001 — only from the Web Tier subnet (10.0.2.0/24)
DB Tier NSG: Allow inbound Port 3306 — only from the App Tier subnet (10.0.6.0/23)

This is a zero-trust internal network. Each layer only trusts traffic from the layer directly above it.

I then deployed two load balancers:

Public Load Balancer — Faces the internet, routes traffic to Web Tier VMs
Internal Load Balancer — Lives inside the VNet, routes traffic from Web Tier to App Tier (frontend IP: 10.0.6.100)

The internal load balancer is the piece most people overlook. It means the App Tier never needs a public IP. The traffic flow looks like this:

Internet → Public LB → Web VM → Internal LB → App VM → Database

At no point does the backend touch the public internet.

Step 3: VM Deployment and the Quota Problem

This is where things got interesting.

I deployed Ubuntu VMs for both tiers:

Web Tier: Next.js behind Nginx on Port 80, in the public subnet
App Tier: Node.js on Port 3001, in private subnets with no public internet access

Midway through, I hit a 0 vCPU quota limit on my Azure free subscription. The portal blocked me from provisioning the next VM.

Fix: Pivot to Standard_B1s instances, which consumed fewer quota units and unblocked me.

Then I hit the next problem. The App Tier VM sits in a private subnet — which is correct by design, but means you can't SSH into it directly from your local machine. The managed Azure Bastion service failed to connect in my environment.

Fix: Build a manual jump-box. I used the Web Tier VM as a stepping stone:

# Step 1 — From local machine into the Web VM (public)
ssh -i web-vm-key.pem azureuser@<web-vm-public-ip>

# Step 2 — From Web VM into the App VM (private IP only)
ssh -i mvn.pem azureuser@10.0.6.4

This is a classic production pattern. You never expose backend servers directly — you always go through a bastion or jump-box. I just had to build mine manually instead of using the managed service.

Step 4: Database — Private, Redundant, and Ready

I provisioned an Azure Database for MySQL Flexible Server entirely within the private database subnets with the following configuration:

Multi-AZ enabled for high availability
Read replica configured for read scaling
VNet integration — no public endpoint, zero internet exposure

The database is invisible to the outside world. The only machines that can reach it are App Tier VMs within the designated subnet (10.0.10.0/24 and 10.0.12.0/24).

The Moment It Worked

After the quota limits, the Bastion failure, and the jump-box setup — I opened a browser and navigated to the Web Tier's public IP: 20.227.32.150.

The Book Review App loaded. The Pragmatic Programmer. Clean Code. JavaScript: The Good Parts. All pulling live data from a database sitting in a private subnet that the internet cannot touch.

That moment made all the friction worth it.

What I Learned

Troubleshooting is the job.
The 0 vCPU quota limit and the Bastion failure weren't obstacles to the assignment — they were the assignment. Real infrastructure work is 40% planning and 60% adapting to what actually happens.

Constraints force better decisions.
Not having 6 subnets didn't make my architecture wrong. It made me document the tradeoff and move forward. That's a professional skill.

Private networking is a mindset, not a feature.
Once you understand why each tier is isolated, the subnets and NSGs stop feeling like configuration work. They become decisions about trust — and trust is what security is built on.

What's Next

The AWS portion of this project is coming up next.

After that, I'll be moving into Agentic AI for DevOps — exploring how AI agents are starting to reshape how infrastructure is managed, automated, and reasoned about. It's the next frontier for this field, and I want to understand it deeply before it becomes the standard.

Follow along: linkedin.com/in/odoworitse-afari

This post is part of my DMI Cohort 2 learning journey with Pravin Mishra — CloudAdvisory.

Deploying a Full-Stack App on Azure: What I Learned Connecting a VM to a Private MySQL Database

Odoworitse Afari — Sat, 14 Mar 2026 00:10:10 +0000

Introduction

There's a difference between reading about cloud architecture and actually building it.

This week, as part of my DevOps Micro Internship (DMI Cohort 2), I deployed the EpicBook web application on Microsoft Azure — a full-stack app with a React frontend, Node.js backend, and a MySQL database. What made this assignment different from previous ones wasn't just the tools. It was the deliberate security decisions I had to make at every step.

This post walks through what I built, the decisions I made, and what actually clicked for me along the way.

What I Built

A two-tier deployment on Azure:

Compute layer: Ubuntu 22.04 VM (Standard B1s) running the EpicBook app with Nginx as a reverse proxy
Database layer: Azure Database for MySQL Flexible Server, placed in a private subnet with no public internet access

The goal was to get the app live and accessible via the VM's public IP, while keeping the database completely hidden from the outside world.

Step 1: Designing the Network

Before provisioning anything, I set up the network foundation.

I created a Virtual Network (VNet) with the address space 10.0.0.0/16, then carved it into two subnets:

10.0.1.0/24 — Public subnet for the VM
10.0.2.0/24 — Private subnet for the MySQL database

This separation is the core of secure cloud architecture. The public subnet is where traffic enters. The private subnet is where sensitive data lives — and it should never be directly reachable from the internet.

I then attached Network Security Groups (NSGs) to enforce the rules:

Public subnet NSG: Allow HTTP (Port 80) and SSH (Port 22)
Private subnet NSG: Allow MySQL (Port 3306) only from the VM's subnet

That last rule is important. It means even if someone somehow reached the private subnet, they couldn't connect to MySQL unless they were coming from the application VM itself.

Step 2: Provisioning the VM and Installing Dependencies

I deployed the Ubuntu VM into the public subnet, assigned a public IP, and SSHed in.

Then I installed everything the app needed:

sudo apt update && sudo apt upgrade -y
sudo apt install nodejs npm nginx git mysql-client -y

I verified the installations before moving forward:

node -v
npm -v
git --version

A small habit that saves a lot of debugging later.

Step 3: Deploying the EpicBook Application

I cloned the repository and installed dependencies:

git clone https://github.com/pravinmishraaws/theepicbook.git
cd theepicbook
npm install

Then I configured Nginx as a reverse proxy. The key configuration line that matters for React apps is inside the Nginx server block:

server {
    listen 80;
    server_name _;

    root /home/azureuser/theepicbook/build;
    index index.html;

    location / {
        try_files $uri /index.html;
    }
}

The try_files $uri /index.html; line ensures React Router works correctly. Without it, refreshing any route other than / returns a 404 — because Nginx looks for a physical file that doesn't exist instead of handing control back to React.

I also used environment variables to pass the database credentials to the Node.js backend. No hardcoded passwords in the codebase.

Step 4: Setting Up the Private Database

I provisioned an Azure Database for MySQL Flexible Server using Private Access (VNet Integration), placing it directly inside the private subnet.

This means the database has no public endpoint. The only way to reach it is from within the VNet — specifically from the application VM.

I imported the SQL dump to initialize the schema, then tested the connection from the VM:

mysql -h epicbook-db1.mysql.database.azure.com \
      -u admin123 \
      -p bookstore \
      -e "SELECT * FROM author LIMIT 5;"

Seeing the author records return in the terminal confirmed the entire chain was working:

VM → private subnet → MySQL → data ✓

Step 5: Final Security Hardening

One last step beyond the basics: I restricted SSH access in the NSG to my specific local IP address only. This means Port 22 is no longer open to the entire internet — only my machine can SSH into the VM.

I also verified the internal Linux firewall (ufw) was not interfering with web traffic:

sudo ufw status
# Status: inactive

What I Learned

1. Network design happens before deployment, not during.
VNets and subnets are not setup steps to rush through. They are the architecture. Everything else builds on top of them.

2. Private access is not optional for databases.
Putting a database in a public subnet with a public endpoint is a real risk that real companies have paid for. VNet integration and NSG rules are how you protect data properly.

3. Environment variables are a non-negotiable habit.
Hardcoding credentials — even temporarily — is a risk. Using .env files from the start costs nothing and prevents a lot.

What's Next

Next up: the AWS portion of this project, and then I'm moving into Agentic AI for DevOps — specifically how AI agents are changing the way infrastructure is managed and automated.

If you're also on the DevOps learning path, feel free to connect: linkedin.com/in/odoworitse-afari

This post is part of my DMI Cohort 2 learning journey with Pravin Mishra — CloudAdvisory.

I Ran My First Real Agile Sprint and Shipped to Production Every Day for 5 Days

Odoworitse Afari — Thu, 12 Mar 2026 16:42:11 +0000

Here's what happened when I stopped reading about DevOps and actually did it

I've read dozens of articles about Agile sprints. Watched YouTube tutorials on Jira. Taken notes on CI/CD workflows.

But until last week, I'd never actually run a sprint from start to finish.

My internship at CloudAdvisory changed that. The assignment: build and deploy a footer to a portfolio website. Simple feature, right? Add version number, deployment date, author name. Done.

Except the real assignment wasn't the footer. It was running a proper 5-day sprint, planning in Jira, committing daily, deploying to EC2, and documenting everything like a production team would.

Here's what I learned shipping code every single day.

Day 0: Planning (The Part Everyone Skips)

Most developers jump straight to coding. I used to do that too. Open VS Code, start typing, figure it out as I go.

That's not how real teams work.

I opened Jira and created a story: "Add footer with version and deploy date." Then I wrote acceptance criteria in Gherkin format—basically a checklist that defines "done":

Given I'm on the portfolio homepage
When I scroll to the footer
Then I should see:
  - Version number (v1.0)
  - Dynamic deploy date (today's date)
  - Author name (Odoworitse Afari)

Then I broke it into 5 daily subtasks:

Day 1: Build the footer, commit, deploy
Day 2: Make the date dynamic (no hardcoding)
Day 3: Polish the UI, test on mobile
Day 4: Update homepage tagline
Day 5: Demo and retrospective

📸

I set a sprint goal: "Ship a visible footer to EC2 with daily progress documented in Jira."

Then I clicked "Start Sprint."

The clock started ticking.

Day 1: First Deployment (It's Not Just `git push`)

I cloned the repo and created a feature branch:

git clone https://github.com/pravinmishraaws/Pravin-Mishra-Portfolio
cd Pravin-Mishra-Portfolio
git checkout -b feature/footer-v1

Added the footer to index.html:

<footer>
  <p>Pravin Mishra Portfolio v1.0 — Deployed on 6 Feb 2026 — By Odoworitse Afari</p>
</footer>

Committed:

git add .
git commit -m "feat(footer): add version, deploy date, and author"

Then came the reality check: deploying to EC2 isn't git push. It's manual work.

I had to:

Copy files to the server using SCP
SSH into the EC2 instance
Move files to Nginx's web root
Reload Nginx
Verify the site is live

scp -i my-key.pem -r . ubuntu@44.193.203.233:/tmp/portfolio
ssh -i my-key.pem ubuntu@44.193.203.233
sudo cp -r /tmp/portfolio/* /var/www/html/
sudo nginx -t && sudo systemctl reload nginx

📸

When I opened the site and saw my footer live on a public IP address, it hit different. This wasn't localhost. Real people could see this.

I went back to Jira and moved Day 1 to "Done." Added a scrum comment: "Shipped footer v1 to production. Live at http://44.193.203.233"

📸

What I learned: Shipping to production on Day 1 changes everything. It's not theory anymore. You have to verify it works, test it in a browser, make sure nothing broke. That's the difference between coding and DevOps.

Day 2: Making It Actually Dynamic

The footer from Day 1 had a problem: the date was hardcoded. "Deployed on 1 Feb 2026."

That's fine if you never deploy again. But in real DevOps, you deploy multiple times a day. You can't manually update the date every time. That defeats the whole point of automation.

I replaced the static date with JavaScript that generates today's date automatically:

<footer>
  <p>
    Pravin Mishra Portfolio v1.0 — 
    Deployed on <span id="deploy-date"></span> — 
    By Odoworitse Afari
  </p>
</footer>

<script>
  const today = new Date();
  const options = { day: 'numeric', month: 'short', year: 'numeric' };
  const formattedDate = today.toLocaleDateString('en-GB', options);
  document.getElementById('deploy-date').textContent = formattedDate;
</script>

Now every page load shows the current date. No manual updates.

📸

I also updated the README to document how it works. Future developers (or future me) shouldn't have to reverse-engineer this.

Committed, deployed, verified.

What I learned: Automation isn't just CI/CD pipelines. Sometimes it's replacing one hardcoded value with three lines of JavaScript. Every manual step you eliminate is one less thing that can break.

Day 3: Polish (Because "It Works" Isn't Enough)

The footer worked, but it looked terrible. Text was cramped, contrast was weak, and I hadn't tested it on mobile yet.

I updated the CSS:

footer {
  padding: 2rem 1rem;
  background-color: #1a1a1a;
  color: #f0f0f0;
  text-align: center;
  font-size: 0.9rem;
  border-top: 1px solid #333;
}

Then I opened Chrome DevTools and tested on:

Desktop (1920x1080)
Tablet (768px)
Mobile (375px)

The footer was responsive and readable on all screen sizes.

📸
![Portfolio website footer displaying version 1.0, deploy date, and author name on live EC2 server]](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t09vqg2z5cema109i044.jpg)

📸

Committed, deployed, verified.

What I learned: "It works on my laptop" is not production-ready. Real software needs to work for everyone, on every device. Polish matters.

Day 4: Bonus Feature (Small Wins Add Up)

While I was at it, I updated the homepage tagline. Instead of static text, I added a Discord invite link to the DMI community:

<p>
  <a href="https://discord.gg/dmi-cohort3" 
     target="_blank" 
     rel="noopener noreferrer">
    Join the DMI Community on Discord
  </a>
</p>

📸

Small change, but now the homepage has a call-to-action instead of passive text.

Committed, deployed, verified.

What I learned: Every sprint should leave the product better than it was. Small improvements compound.

Day 5: Demo, Retro, Burndown (Closing the Loop)

I recorded a Loom video walking through everything I shipped:

Footer with dynamic date
Mobile responsiveness
Homepage CTA
Live deployment verification

Then I ran a retrospective:

What went well:

Clear acceptance criteria made implementation straightforward
Daily commits kept progress visible
Incremental deployments caught issues early

What could improve:

Should have tested mobile view on Day 1, not Day 3
Manual deployments are slow—need automation

Finally, I opened the Jira Burndown Chart. It showed steady progress from Day 1 to Day 5. No scope creep, no blocked work, just consistent daily execution.

📸

Sprint goal achieved.

What Running a Real Sprint Taught Me

1. Sprint Goals Keep You Focused

"Ship visible footer improvements" isn't just admin overhead. It's a filter. Every time I thought about adding extra features, I asked: "Does this help achieve the sprint goal?" If not, it goes in the backlog.

2. Daily Commits Build Discipline

Shipping something every single day, even if it's small, creates momentum. By Day 5, I'd deployed 5 times. That's 5 reps of the deployment process, 5 times verifying the site was live, 5 times documenting work in Jira.

3. Agile Is About Shipping, Not Tickets

Moving a Jira ticket to "Done" feels good, but it's meaningless if the code isn't live. Real Agile is about shipping working software. Every day I asked: "Is this live? Can users see it?" That's the standard.

4. Documentation Is Part of the Work

Updating the README, writing acceptance criteria, logging daily scrum notes this isn't busywork. It's how teams stay aligned. Without documentation, the next person wastes time figuring out what you built.

5. Retrospectives Drive Growth

On Day 5, I didn't just celebrate finishing. I asked: "What slowed me down? What would I do differently?" That's how you improve.

What's Next

This sprint taught me that Agile isn't a process you follow. It's a mindset. Ship small, ship often, improve continuously.

My next steps:

Automate deployments write a script to eliminate manual SCP/SSH
Add CI/CD set up GitHub Actions to deploy on every push
Implement rollback what if a deployment breaks production?

If you're learning DevOps, try this: pick a small project, break it into daily tasks, and ship something every day for a week. You'll learn more in 5 days of shipping than in 5 weeks of tutorials.

Tools I Used

Jira (Sprint planning, backlog, burndown)
Git + GitHub (Version control)
AWS EC2 (Production server)
Nginx (Web server)
VS Code (Code editor)
Chrome DevTools (Testing)
Loom (Sprint demo)

Connect

I'm Odoworitse Afari, a junior DevOps engineer building in public. If you're on a similar path, let's connect:

LinkedIn: linkedin.com/in/odoworitse-afari
GitHub: github.com/0dow0ri7s3

How to Deploy a React App on Ubuntu with Nginx: A Complete Guide

Odoworitse Afari — Tue, 20 Jan 2026 14:15:38 +0000

Author: Odoworitse Afari
Date: 20/1/2026

Introduction
Deploying a React application to production involves more than just running npm start. In this guide, I'll walk you through the complete process of deploying a React app on an Ubuntu server and serving it with Nginx—from initial setup to making it publicly accessible.
This isn't theory. This is a real deployment with real challenges and real solutions.

About me: I'm Odoworitse Afari, a DevOps Engineer documenting my journey building production infrastructure. Follow me on LinkedIn and GitHub for more DevOps content.

What we'll cover:

Setting up Node.js and Nginx on Ubuntu
Building a React app for production
Configuring Nginx for Single Page Application (SPA) routing
Troubleshooting common deployment issues

By the end of this guide, you'll have a live React application accessible via your server's public IP.

Prerequisites
Before starting, you'll need:

An Ubuntu server (VM, EC2, or any cloud provider)
SSH access to your server
Basic Linux command line knowledge
A React application (I'll use a sample repo from GitHub)

The Technology Stack

Server OS: Ubuntu 20.04/22.04
Runtime: Node.js & npm
Web Server: Nginx
Application: React (production build)

Step 1: Installing Node.js and npm

First, we need to install Node.js and npm on the Ubuntu server. These tools are essential for building the React application.

sudo apt update
sudo apt install -y nodejs npm

Verify the installation:

node -v && npm -v

You should see version numbers for both Node.js and npm.

Why this matters:

Node.js provides the JavaScript runtime needed to build React applications outside the browser. npm manages the project dependencies and build scripts. Without these, we can't create a production-ready build.

Node.js and npm successfully installed

Step 2: Installing and Configuring Nginx
Nginx will serve our React application's static files to users.

sudo apt install -y nginx
sudo systemctl start nginx
sudo systemctl enable nginx

Verify Nginx is running:

sudo systemctl status nginx

You should see active (running) in the output.

Why this matters:

The enable command ensures Nginx starts automatically after server reboots, preventing manual intervention during maintenance or unexpected restarts. This is critical for production reliability.

Nginx service active and enabled

Step 3: Getting the React Application
Clone the React app repository to your server:

git clone https://github.com/pravinmishraaws/my-react-app.git
cd my-react-app

Why use Git for deployment?

In professional environments, code is always pulled from version control systems. This ensures consistency across environments and provides a clear audit trail of what's deployed.

React app repository cloned successfully

Step 4: Customizing the Application
Before building, let's customize the app to prove ownership. Navigate to the source directory:

cd my-react-app/src
nano App.js

Update the relevant section with your details:

jsx
<h2>Deployed by: <strong>Your Full Name</strong></h2>
<p>Date: <strong>DD/MM/YYYY</strong></p>

Save and exit (Ctrl+O, Enter, Ctrl+X in nano).

Why this step matters:

In real deployments, applications often need environment-specific configurations. While this example uses direct code editing, production systems typically handle this through environment variables or config files.

Application customized with deployment details

Step 5: Building for Production
React applications need to be built differently for production versus development.

Install dependencies:

npm install

Create the production build:

npm run build

This creates an optimized build/ directory with minified, compressed files ready for production.

Development vs Production builds:

Development: Large file sizes, readable code, slower performance

Production: Minified code, compressed assets, optimized performance, no source maps

Production builds can be 10x smaller and significantly faster.

Production build completed successfully

Step 6: Deploying to Nginx
Now we deploy the built application to Nginx's web root directory.

Clear the default Nginx content:

sudo rm -rf /var/www/html/*

Copy the production build:

sudo cp -r build/* /var/www/html/

Set proper ownership and permissions:

sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html

Understanding permissions:

Nginx runs as the www-data user on Ubuntu. Files must be owned by this user for Nginx to read them. The 755 permission allows the owner to read/write/execute, while others can only read/execute.

Common mistake: Incorrect permissions lead to "403 Forbidden" errors—one of the most frequent deployment issues.

Application files successfully deployed to /var/www/html

Step 7: Configuring Nginx for React (Critical Step)
React is a Single Page Application (SPA). All routing happens on the client side. Without proper Nginx configuration, refreshing any route besides / results in a 404 error.

Replace the default Nginx configuration:

echo 'server {
  listen 80;
  server_name _;
  root /var/www/html;
  index index.html;

  location / {
    try_files $uri /index.html;
  }

  error_page 404 /index.html;
}' | sudo tee /etc/nginx/sites-available/default > /dev/null

Breaking down this configuration:

listen 80; - Nginx listens on port 80 (HTTP)
root /var/www/html; - Where to find files
try_files $uri /index.html; - This is the key line

The try_files directive tells Nginx:

First, try to serve the requested file directly
If the file doesn't exist, serve index.html instead

This allows React Router to handle navigation.

Restart Nginx to apply changes:

sudo systemctl restart nginx

Why this matters:

Most tutorials skip proper SPA configuration. Without it:

Direct URL access fails (404 error)
Page refreshes break (404 error)
Only the home page works

This is the #1 issue developers face when deploying React apps.

Nginx configured for SPA routing and restarted

Step 8: Testing the Deployment
Get your server's public IP:

curl ifconfig.me

Open your browser and navigate to:

http://[your-public-ip]

Your React application should now be live!

React app successfully deployed and accessible via public IP

Common Issues and Solutions

Issue 1: 404 Errors on Page Refresh
Symptom: Home page works, but refreshing /about shows 404.
Cause: Nginx isn't configured for SPA routing.
Solution: Ensure the try_files directive is in your Nginx config (Step 7).

Issue 2: 403 Forbidden Error
Symptom: Browser shows "403 Forbidden" when accessing the site.
Cause: Incorrect file permissions or ownership.
Solution:

sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html

Issue 3: Connection Refused
Symptom: Browser can't connect to the server.
Cause: Nginx isn't running, or firewall is blocking port 80.

Solution:

sudo systemctl status nginx # Check if running
sudo ufw allow 80/tcp # If using UFW firewall

What I Learned
Configuration is everything - One missing semicolon or wrong directive can break an entire deployment.

Production builds matter - Development builds are 10x larger and significantly slower. Always use npm run build for production.

SPA routing is non-obvious - Most deployment guides don't cover this properly, leading to broken apps in production.

Permissions are critical - Understanding Linux file ownership prevents hours of debugging.

Testing is mandatory - Never assume deployment worked. Always verify in a browser.

Security Considerations (For Production)
While this guide gets your app running, production deployments need additional hardening:

Use HTTPS: Set up SSL/TLS certificates (Let's Encrypt is free)
Configure firewall: Only open necessary ports
Keep software updated: Regular security patches
Use environment variables: Never hardcode secrets
Set up monitoring: Track uptime and errors

Next Steps
Now that you have a working deployment, consider:

Setting up a CI/CD pipeline to automate deployments
Configuring a custom domain instead of using IP addresses
Implementing HTTPS with Let's Encrypt
Adding monitoring and logging (PM2, CloudWatch, or similar)
Using a reverse proxy for multiple applications

Conclusion
Deploying a React app to production involves more than just copying files to a server. You need to understand:

How to build for production
How web servers serve static files
How client-side routing works
How permissions and ownership affect accessibility

This guide walked you through a complete, working deployment. The challenges you'll face in real production environments will be similar—but now you have the foundation to troubleshoot and solve them.

Key takeaway: Most deployment issues come from misconfiguration, not broken code. Understanding your infrastructure is just as important as understanding your application.

About the Author

I'm Odoworitse Afari, a DevOps Engineer focused on building scalable cloud infrastructure and automating deployment pipelines. I'm currently part of the DevOps Micro Internship (DMI) program, where I'm building real-world projects and documenting my journey.

Connect with me:

LinkedIn: linkedin.com/in/odoworitse-afari
GitHub: github.com/0dow0ri7s3
Upwork: upwork.com/freelancers/~0121603c4d11c8e4e3

I write about DevOps, cloud infrastructure, and automation. Follow me for more hands-on tutorials and project breakdowns.

If you found this guide helpful:

⭐ Star my GitHub repos
💬 Connect with me on LinkedIn
🔄 Share this article with others learning DevOps

Forem: Odoworitse Afari

# Building a Three-Tier Architecture on Azure

Introduction

What Is a Three-Tier Architecture?

Step 1: Designing the VNet and Subnets

Step 2: NSGs and Load Balancers

Step 3: VM Deployment and the Quota Problem

Step 4: Database — Private, Redundant, and Ready

The Moment It Worked

What I Learned

What's Next

Deploying a Full-Stack App on Azure: What I Learned Connecting a VM to a Private MySQL Database

Introduction

What I Built

Step 1: Designing the Network

Step 2: Provisioning the VM and Installing Dependencies

Step 3: Deploying the EpicBook Application

Step 4: Setting Up the Private Database

Step 5: Final Security Hardening

What I Learned

What's Next

I Ran My First Real Agile Sprint and Shipped to Production Every Day for 5 Days

Here's what happened when I stopped reading about DevOps and actually did it

Day 0: Planning (The Part Everyone Skips)

Day 1: First Deployment (It's Not Just git push)

Day 2: Making It Actually Dynamic

Day 3: Polish (Because "It Works" Isn't Enough)

Day 4: Bonus Feature (Small Wins Add Up)

Day 5: Demo, Retro, Burndown (Closing the Loop)

What Running a Real Sprint Taught Me

1. Sprint Goals Keep You Focused

2. Daily Commits Build Discipline

3. Agile Is About Shipping, Not Tickets

4. Documentation Is Part of the Work

5. Retrospectives Drive Growth

What's Next

Tools I Used

Connect

How to Deploy a React App on Ubuntu with Nginx: A Complete Guide

Day 1: First Deployment (It's Not Just `git push`)