🚀 From “It Works on My Machine” to Real DevOps: My First End-to-End Deployment

After spending more time than I’d like to admit fighting SSH, VS Code, WSL, EC2 permissions, and GitHub Actions, I finally reached a working deployment pipeline.

This post is a real journey, not a polished tutorial — because DevOps in the real world is messy, opinionated, and unforgiving.

Here’s what I learned and why EC2 alone is not DevOps.

🧩 What I Built

By the end of this exercise, I had:

• An Apache web server running on AWS EC2

• Website files deployed to /var/www/html

• SSH access working from:

  • WSL
  • PowerShell
  • VS Code (Remote-SSH)

• A GitHub repository containing my website

• A GitHub Actions pipeline that automatically deploys code to EC2

❌ Why EC2 Alone Is Not Enough

Launching an EC2 instance and SSHing into it feels productive — but it’s not DevOps.

If your workflow looks like this:

Edit code → SSH → scp → restart server

You have problems:

• ❌ Manual steps = human error

• ❌ No audit trail

• ❌ No reproducibility

• ❌ No automation

• ❌ No rollback

If the server dies, everything dies with it.

DevOps is not about servers.
It’s about systems.

🔑 The First Real Lesson: Ownership & Permissions

One of the first blockers I hit was file permissions.

Apache serves files from:

/var/www/html

By default, this directory is owned by root.
That means no easy editing or deployment.

sudo chown -R ec2-user:ec2-user /var/www/html
sudo chmod -R 755 /var/www/html

🧠 Why SSH Configuration Matters

I could SSH successfully from WSL but not from VS Code or PowerShell.

The issue wasn’t AWS.
It was which SSH binary and config file VS Code was using.

Key takeaways:

• Windows uses C:\Users\<user>\.ssh\config

• WSL uses /home/<user>/.ssh/config

• The file must be named exactly config, _not _config.txt

• VS Code Remote-SSH defaults to Windows SSH unless explicitly configured

Once SSH worked everywhere, everything else became easier.

⚙️ Introducing GitHub Actions

At this point, I had working infrastructure — but deployment was still manual.

That’s where GitHub Actions comes in.

GitHub Actions allows you to run workflows when something happens — like a push to main.

Those workflows are defined in **YAML **files.

Why YAML?

• Easy to read

• Structured

-- Used by:

-- GitHub Actions

-- Kubernetes

-- Docker Compose

-- CI/CD systems

YAML describes what should happen, not how you type commands.

🏗 Why We Need a deploy.yml File

This file tells GitHub Actions:

• When to run

• What machine to run on

• What steps to execute

-- Without it:

-- GitHub does nothing

-- Your repo is just files

-- With it:

  Your repo becomes a deployment system