From Local Git Commits to a Live EC2 Website: Real DevOps Deployment

#aws #devops #git #tutorial

DevOps stopped being abstract for me the moment my website went live on the internet.

As part of a hands-on DevOps assignment, I deployed a static portfolio website to an AWS EC2 Ubuntu server using Nginx, following production-style workflows instead of shortcuts. This wasn’t just about “making it work”; it was about doing it the right way.

In this post, I’ll walk through what I built, what broke, and what I learned while moving from local Git commits to a publicly accessible server.

Step 1: Laying the Foundation with Git
I started by creating a project called CodeTrack and initializing it as a Git repository.
Before writing any code, I focused on getting the basics right:

Initializing the repo correctly (git init)
Verifying repository state with git status
Understanding the role of the hidden .git directory
Configuring Git identity (local vs global)
This step taught me something important early on:
If your Git foundation is wrong, everything built on top of it becomes messy.

Step 2: Clean Commits, Not Just “Any Commit”
Instead of committing everything at once, I followed a real-world commit strategy:

First commit: UI scaffold (index.html, style.css)
Second commit: Small controlled content change (name, group, page text)
This mirrors how professional teams work. Small, focused commits make it easier to:

Review changes
Debug issues
Roll back safely if something goes wrong
Git stopped feeling like a requirement and started feeling like a safety net.

Step 3: Deploying to AWS EC2 with Nginx
Once the project was ready locally, it was time to deploy.

I connected to an Ubuntu EC2 instance using SSH key authentication and set up Nginx as the web server. The deployment flow looked like this:

Secure SSH access using a .pem key
Install and start Nginx
Copy project files from the local machine to EC2 using scp
Move files into Nginx’s web root
Verify deployment using:
curl -I http://localhost
Browser access via the EC2 public IP
Seeing my site load from a public IP was a big moment, that’s when it felt real.

Real DevOps Moment: Breaking and Fixing Things Safely
One part of the assignment required simulating a production failure.
I intentionally introduced a small syntax error into the Nginx configuration file and then:

Verified the failure using nginx -t
Diagnosed the issue
Fixed the configuration
Restarted Nginx safely
Confirmed recovery using curl
This exercise taught me a core DevOps lesson:

Breaking production is easy. Recovering safely is the real skill.

Challenges I Faced (And What They Taught Me)
I ran into multiple issues along the way, including:

Permission denied (publickey) errors during deployment
Incorrect SSH key paths
Missing file locations on the EC2 server
Each problem forced me to slow down, read errors properly, and understand why something failed instead of copying commands blindly. That process, not the deployment itself, was where the real learning happened.

Key DevOps Lessons I’m Taking Forward
Always verify before and after changes
Git discipline matters more than speed
SSH security is non-negotiable
Nginx validation (nginx -t) prevents outages
DevOps is about responsibility, not just automation
Final Outcome

✔ Website deployed and publicly accessible

✔ Nginx running and validated

✔ Clean Git commit history

✔ Real troubleshooting experience

This project strengthened my confidence in Linux, Git, AWS, and DevOps fundamentals, and it’s only the beginning.

live website

http://

Closing Thought