DEV Community: Anany Dubey

How I Deployed My First Project on AWS (And Didn't Break Everything)

Anany Dubey — Sat, 30 May 2026 17:12:32 +0000

The First Time "Localhost" Isn't Enough

There's a moment every developer hits.

Your project works. It runs perfectly on your machine. You're proud of it. And then someone asks — "Cool, can I see it?"

And you realize... you have no answer. Because it only lives on your laptop.

That was me not too long ago. I had a working Node.js/Express app, a GitHub repo, and zero idea how to put it on the actual internet. AWS kept coming up everywhere — tutorials, job descriptions, YouTube videos — but it felt enormous and intimidating.

So I decided to just try it. Break things. Figure it out.

This blog is exactly what I wish I had that day. A plain, honest, step-by-step guide to deploying your first Node.js app on AWS — from local machine to live URL.

Let's go.

What We're Working With

Before we start, here's what this guide assumes:

You have a Node.js/Express app that runs locally with npm start
Your project is (or will be) on GitHub
You have an AWS account (free tier works perfectly for this)

That's it. No prior cloud experience needed.

Here's the full journey we'll take:

Local machine → GitHub → AWS EC2 → Live on the internet

Step 1: Test Your App Locally First

This sounds obvious, but it matters more than you think.

Before touching AWS, make sure your app runs cleanly on your machine:

npm install
npm start

Open http://localhost:3000 (or whatever port you're using) and confirm everything works. Check your routes, test your endpoints, make sure there are no crashes.

Why this matters: Debugging on a remote server is ten times harder than debugging locally. Fix all issues here first — it'll save you hours later.

Also make sure your package.json has a proper start script:

"scripts": {
  "start": "node index.js"
}

Step 2: Push Your Project to GitHub

Your EC2 server will pull your code directly from GitHub, so this step is essential.

If you haven't already:

git init
git add .
git commit -m "initial commit"
git remote add origin https://github.com/yourusername/your-repo.git
git push -u origin main

⚠️ Important: Make sure your .env file is in .gitignore before pushing. You never want secret keys, database passwords, or API credentials on GitHub — even in a private repo.

# .gitignore
node_modules/
.env

Push your code, verify it's visible on GitHub, and move to the next step.

Step 3: Create Your AWS EC2 Instance

This is where the cloud part begins. EC2 is essentially a virtual computer that lives in AWS's data center — and you're about to rent one.

Log into AWS Console
Search for EC2 and click Launch Instance
Fill in the details:
- Name: give it something meaningful like my-first-app
- AMI: choose Ubuntu Server 22.04 LTS (free tier eligible)
- Instance type: t2.micro (free tier — perfect for this)
Key pair: Create a new key pair, name it, and download the .pem file. Don't lose this — it's the only way to SSH into your server.
Leave everything else as default for now and click Launch Instance

Your server will be up and running in about a minute.

Step 4: SSH Into Your Server

Now we're going to remotely connect to your EC2 instance — like opening a terminal on a computer that lives in Amazon's data center.

First, find your server's Public IPv4 address from the EC2 dashboard.

Then in your local terminal:

chmod 400 your-key-file.pem
ssh -i your-key-file.pem ubuntu@your-public-ip

Replace your-key-file.pem with your actual key file name and your-public-ip with your EC2's IP address.

If everything is set up correctly, you'll see a welcome screen from Ubuntu. You're now inside your server. 🎉

Step 5: Update the Server

First things first — always update a fresh server before installing anything:

sudo apt update && sudo apt upgrade -y

This pulls the latest package lists and upgrades any outdated packages. It takes a minute or two. Let it finish.

Step 6: Install Node.js and npm

Your server is a fresh Ubuntu machine — it has nothing installed. Let's add Node.js:

sudo apt install -y nodejs npm

Verify the installation:

node -v
npm -v

You should see version numbers for both. If you do, you're ready to move on.

Step 7: Clone Your Project from GitHub

Now let's bring your code onto the server:

git clone https://github.com/yourusername/your-repo.git
cd your-repo

Then install your project's dependencies:

npm install

This recreates your node_modules folder on the server using your package.json.

Step 8: Create Your `.env` File

Remember how we kept .env out of GitHub? Now we need to recreate it manually on the server.

nano .env

Type out your environment variables:

PORT=3000
DATABASE_URL=your_database_url
API_KEY=your_api_key

Save and exit: Ctrl + X, then Y, then Enter.

This is the correct way to handle secrets on a server — never in your repo, always added manually.

Step 9: Start Your App

The moment of truth:

npm start

If everything is configured correctly, you'll see your server start up — the same output you see locally, but now it's running on AWS.

Open your browser and visit:

http://your-public-ip:3000

Your app is live on the internet. 🚀

Step 10: App Running but Still Not Visible? Fix Your Security Group

This is the most common gotcha for first-time deployments.

Your app is running fine on the server — npm start shows no errors — but when you open http://your-public-ip:3000 in the browser, it just times out or refuses to connect.

The fix: open port 3000 in your EC2 Security Group.

AWS blocks all incoming traffic by default. You have to explicitly allow it:

Go to your EC2 Dashboard → click your instance
Go to the Security tab → click the Security Group link
Click Edit Inbound Rules and add:

Type	Protocol	Port	Source
SSH	TCP	22	My IP
HTTP	TCP	80	Anywhere (0.0.0.0/0)
Custom TCP	TCP	3000	Anywhere (0.0.0.0/0)

Click Save rules

Now refresh your browser — your app should load instantly.

Port 22 lets you SSH in. Port 3000 lets the world reach your app. Port 80 is for standard HTTP — useful when you later point a domain to your server.

💡 If your app uses a different port (like 5000 or 8080), open that port instead of 3000.

One More Thing: Keep It Running

There's one problem with npm start — the moment you close your terminal, the app stops.

To keep it running even after you disconnect, install pm2:

sudo npm install -g pm2
pm2 start index.js
pm2 startup
pm2 save

Now your app will keep running in the background — even if the server restarts.

The Full Deployment Checklist

✅ App tested locally with npm start
✅ .env added to .gitignore
✅ Code pushed to GitHub
✅ EC2 instance launched (Ubuntu, t2.micro)
✅ Key pair downloaded safely
✅ SSH into server
✅ Server updated (apt update && upgrade)
✅ Node.js and npm installed
✅ Repo cloned and npm install run
✅ .env file created manually on server
✅ npm start — app is running on server
✅ Security group inbound rules configured (ports 22, 80, 3000)
✅ App visible at public-ip:3000
✅ pm2 set up to keep it running

Closing Thoughts

The first deployment always feels like climbing a mountain. There are a dozen steps, a few moments of panic, and at least one "why isn't this working" that turns out to be a typo.

But when that URL opens in your browser and your app loads — on a real server, accessible to anyone in the world — it's a completely different feeling from seeing it on localhost.

That gap between "it works on my machine" and "it works on the internet" is where a lot of beginners get stuck. Hopefully this guide helps you cross it a little faster than I did.

Deploy something. Break it. Fix it. That's how it works. ☁️

Have questions or got stuck at a specific step? Drop a comment and I'll do my best to help! 👇

I'm Anany Dubey — a student documenting my learning journey one deployment at a time. Follow along for more.

Git Time Machine — How Version Control Can Save Your Project

Anany Dubey — Sat, 23 May 2026 17:07:19 +0000

The Moment Every Developer Dreads

Imagine this.

It's 11 PM. You've been heads-down on a feature for hours. Everything was working — and then you make one small change. Just a tweak. Nothing major.

And suddenly, everything breaks.

The app won't run. The code looks foreign. You can't even remember what it looked like ten minutes ago. You start frantically pressing Ctrl+Z, but it's not enough.

You think: "If only I could just go back in time."

Here's the thing — you can. That's not an exaggeration. That's literally what Git is built for.

Most beginners think Git is just a way to upload code to GitHub. It's so much more than that. Git is a time machine living inside your project — one that tracks every change, stores every version, and lets you jump back to any moment in your project's history.

Once you start thinking about it that way, version control stops being confusing and starts feeling like a superpower.

In this blog, I'll walk you through the Git commands that unlock that superpower — one time-travel metaphor at a time.

First: The Mental Model That Makes Everything Click

Before we touch a single command, let's talk about how Git actually thinks.

Most tutorials skip this part. They throw 20 commands at you and wonder why you're still confused. Here's what they don't tell you:

Every time you run git commit, Git takes a complete snapshot of your entire project at that exact moment — every file, every line of code — and stores it permanently in a hidden timeline inside your project folder.

That timeline never disappears. It just keeps growing with every commit you make.

And because every snapshot is saved forever, you can:

Jump back to any earlier version
Compare two different points in time
Undo something that happened three commits ago
Recover work you thought was gone forever That's the time machine. Now let's learn how to fly it.

1. `git log` — Reading the Timeline

You can't navigate time if you can't read the map.

git log

This command shows you the full history of your project — every commit ever made, who made it, when, and what message they left. Each commit has a unique fingerprint called a hash — a string like a3f9c12b... — that you'll use to jump to specific points in time.

The default output can feel overwhelming. Use this instead:

git log --oneline

Clean, compact, one commit per line. Much easier to scan when you're looking for something specific.

⏱ Time travel use case: Something broke, and you have no idea when. Run git log --oneline and scan the commit messages. Find the last one that says something like "everything working" — that's your destination.

2. `git diff` — Spotting What Changed

Before jumping back in time, it helps to understand exactly what changed and when things went wrong.

git diff

This shows the difference between your current files and the last commit — line by line. Removed lines appear in red, added lines in green.

Want to compare two specific commits?

git diff a3f9c12 e7b2d45

Paste in two hashes from git log and Git will show you everything that changed between those two points in time.

⏱ Time travel use case: Your feature was working yesterday but isn't today. Run git diff to see exactly which lines changed since your last commit. The bug is almost always right there.

3. `git checkout` — Stepping Into the Past

This is where the real time travel happens.

git checkout a3f9c12

Replace a3f9c12 with any commit hash, and Git will transform your entire project back to exactly what it looked like at that moment. You can open files, run the code, poke around — as if you're standing in the past.

And here's the best part: it doesn't touch your current work. It's read-only time travel.

⚠️ You'll see a warning about being in a "detached HEAD" state. Don't panic — it just means you're visiting the past, not changing it. When you're done exploring, come back to the present with:

git checkout main

⏱ Time travel use case: You want to see what your project looked like before a major refactor — to copy a function, compare logic, or just remind yourself how something used to work.

4. `git stash` — Hitting the Pause Button

Here's a scenario you'll run into constantly as a developer.

You're halfway through building something. Your code is messy, half-broken, definitely not ready to commit. And then — your team asks you to urgently fix a bug on a different branch.

You can't commit half-finished work. But you also can't just abandon it.

Enter git stash:

git stash

Git takes all your unfinished changes, bundles them up, tucks them away safely, and gives you a clean working directory — like the mess never existed. Go fix your bug, handle your emergency, do whatever you need to do.

When you're ready to pick up exactly where you left off:

git stash pop

Your changes come back exactly as you left them.

⏱ Time travel use case: Think of stash as a personal pause button. You're not committing to the timeline — you're just stepping out of it temporarily, with a guaranteed way back in.

5. `git revert` — Undoing Without Destroying

You pushed a commit. It broke things. You need to undo it — but you've already shared the code with others, so rewriting history isn't an option.

git revert is the answer:

git revert a3f9c12

Instead of deleting the bad commit, Git creates a brand new commit that does the exact opposite of it. The mistake is neutralized. Your history stays clean and intact. Nobody's workflow gets disrupted.

This is the professional, team-safe way to undo mistakes.

⏱ Time travel use case: You accidentally committed a bug fix that introduced a worse bug. git revert lets you undo that specific commit cleanly — without touching anything else in the timeline.

6. `git reflog` — The Secret Safety Net

This is the command most beginners never hear about — until the day they desperately need it.

git reflog is Git's private diary. While git log shows you the official commit history, git reflog records every single movement of HEAD — every checkout, reset, merge, rebase — even actions that seem to have vanished from history.

git reflog

Accidentally deleted a branch? Did a hard reset and lost commits? Made a mistake and can't find your way back?

Check git reflog. Your work is almost certainly still there.

git checkout HEAD@{3}

This jumps back to where HEAD was exactly 3 moves ago — even if those moves left no trace in git log.

⏱ Time travel use case: This is your last resort. When everything else fails and you think the work is gone forever — run git reflog first. It has saved countless developers from rewriting code they thought was lost.

Putting It All Together

Here's the full time travel workflow when something goes wrong:

🔴 Something breaks
        ↓
git log --oneline     →  Find when it last worked
        ↓
git diff <hash>       →  See exactly what changed
        ↓
git checkout <hash>   →  Step into that working version
        ↓
git revert <hash>     →  Safely undo the bad commit
        ↓
git reflog            →  If all else fails, recover lost work

Each command is a tool in your time machine. Learn them one at a time, and together they make you genuinely hard to break.

Closing Thoughts

Here's the mindset shift that made Git finally make sense to me:

Git doesn't punish you for making mistakes. It protects you from them.

Every commit is a save point. Every branch is an alternate timeline. And with reflog watching your back, almost nothing is ever truly lost.

The developers who seem fearless — who refactor boldly, experiment freely, push without panic — aren't the ones who never break things. They're the ones who know they can always go back.

So commit often. Write clear messages. Break things without fear.

Your time machine has your back. 🕰️

Found this useful? Drop a comment — I'd love to know which Git command has saved you the most! 👇

And if you're just getting comfortable with the terminal, my previous blog might help:
📝 10 Linux Commands That Made the Terminal Less Scary for Me

I'm Anany Dubey — a student who learns best by breaking things and writing about what I find. If that sounds like you, follow along for more.

10 Linux Commands That Made the Terminal Less Scary for Me

Anany Dubey — Thu, 21 May 2026 16:16:58 +0000

I still remember the exact moment I opened the Linux terminal for the first time.

Black screen. Blinking cursor. Absolute silence.

No icons, no buttons, no "click here to continue." Just this tiny blinking thing waiting for me to type something — anything — and I had absolutely no idea what to say to it.

My first reaction, honestly? I closed it.

Then I opened it again because I felt embarrassed closing it, even though I was alone.

I ended up doing what every beginner does: copying random commands from Stack Overflow without really understanding what they did. Sometimes things worked. Sometimes I'd accidentally delete a file I needed. Once I somehow broke my entire home directory setup and had to reinstall things.

But here's what I eventually figured out — Linux wasn't hard because it was complicated. It was hard because it was unfamiliar. Once a few commands started making sense, the whole thing clicked differently.

If you're a CS student, a beginner dev, or someone just getting into backend or DevOps, here are the 10 commands that genuinely made the terminal less terrifying for me.

First, Why Does Linux Even Matter?

Honestly, for a while I thought Linux was one of those "nice to have" skills that senior devs recommend but you can probably skip.

You can't really skip it.

Servers run Linux. Cloud infrastructure runs Linux. Docker, DevOps pipelines, most backend environments — Linux is just quietly everywhere. At some point it stops being optional and becomes part of your actual workflow.

The good news is you don't need to learn hundreds of commands to feel comfortable. You just need a solid handful to start.

1. `pwd` — "Wait, Where Am I?"

The terminal doesn't show you where you are by default. That's confusing at first.

pwd

This prints your current working directory — basically your location in the file system. It stands for print working directory.

I used this constantly when I was learning. Still use it more than I'd like to admit.

2. `ls` — See What's Around You

Want to see what files and folders are in your current location?

ls

Want more details like file sizes and permissions?

ls -l

Want to also see hidden files (files that start with a dot)?

ls -la

ls becomes muscle memory pretty fast. You'll type it without thinking after a week.

3. `cd` — Actually Move Around

Navigation. This one's essential.

cd Documents

Go back one level:

cd ..

Jump straight to your home directory:

cd ~

Once you get used to cd, clicking through folders in a file manager starts feeling weirdly slow. It's one of those small things that makes the terminal feel worth it.

4. `mkdir` — Create a Folder Without the Right-Click

mkdir my-project

That's it. New folder, done.

No right-clicking, no naming dialog box, no confirmation window. Just instant. Linux really does value speed and efficiency, and mkdir is a small example of that.

5. `touch` — Create an Empty File

Need a new file quickly?

touch index.html

touch app.py

It creates an empty file with that name. Nothing fancy, but when you're setting up a project structure, this saves you a surprising amount of time.

6. `cp` and `mv` — Copy, Move, and Rename

Copy a file:

cp notes.txt notes-backup.txt

Move a file to a different folder:

mv notes.txt ~/Documents/notes.txt

Rename a file (it's the same command, just staying in the same place):

mv old-name.txt new-name.txt

The rename thing tripped me up for a bit — I kept looking for a separate rename command. Turns out mv just does it.

7. `rm` — Delete Things (Carefully)

Delete a file:

rm file.txt

Delete a folder and everything inside it:

rm -r foldername

Important heads-up: Linux usually won't ask if you're sure. It just deletes. No trash bin, no undo.

This is how beginners learn to be careful. Usually after losing something they needed.

If you want it to prompt you before deleting, you can use rm -i, but honestly most people just learn the habit of double-checking before they run it.

8. `cat` — Read a File Without Opening an Editor

cat notes.txt

This just prints the file contents straight into your terminal. Super useful for quickly checking configs, reading log files, or just seeing what's in something without bothering to open a text editor.

It's one of those commands that seems almost too simple at first, then you realize you're using it constantly.

9. `grep` — Search Inside Files

This one felt like a superpower once I actually understood it.

grep "error" logs.txt

This searches through logs.txt and shows you every line that contains the word "error."

Once you start debugging real applications or reading through server logs, grep becomes one of your most-used tools. You can search through hundreds of lines instantly instead of scrolling through everything manually.

You can also combine it with other commands using pipes, but that's a rabbit hole for another day.

10. `history` — Your Terminal Remembers Everything

Forgot a command you typed earlier?

history

This shows your command history. Every command you've run, listed out.

You can also press the Up arrow to cycle through recent commands one by one, which I use constantly.

history has saved me more times than I can count — especially when I've run some complex command that worked, and then immediately forgot what I typed.

🎁 Bonus: `man` — The Manual That's Actually Built Into the Terminal

This one I wish someone had told me about on day one.

Every time I didn't understand what a command did or what flags were available, I'd go Google it. That works fine, but there's a faster option that's always right there:

man ls

man grep

man stands for manual. It opens the official documentation for whatever command you pass it — right inside the terminal, no browser needed.

So instead of searching "ls command options linux," you can just type man ls and get the full breakdown: what the command does, every available flag, examples, all of it.

Use the arrow keys to scroll, and press q to quit and go back to your terminal.

Fair warning: man pages are pretty dense and not exactly written for beginners. But once you get used to the format, it's genuinely useful — especially when you're working on a remote server with no internet access and need to look something up.

It's also just a good habit. Gets you comfortable reading documentation instead of always reaching for a tutorial.

What the Terminal Actually Teaches You

When I started, I thought learning Linux was about memorizing commands. The more time I spent in the terminal, the more I realized it's teaching you something else.

It teaches you how computers actually work. Files, permissions, processes, how things are structured under the hood. GUI applications hide all of this. The terminal just shows it to you directly.

You don't need to become an expert overnight. Just open the terminal, use it a little every day, and experiment. Break things, fix them, look stuff up. It gets less intimidating pretty quickly.

Everyone who looks comfortable in the terminal today was once staring at that same blinking cursor thinking, "I have no idea what I'm doing."

The cursor was just waiting for a first command.

What was your first terminal experience like? Was there a command that finally made things click for you? Drop it in the comments — I'd love to know.

DEV Community: Anany Dubey

How I Deployed My First Project on AWS (And Didn't Break Everything)

The First Time "Localhost" Isn't Enough

What We're Working With

Step 1: Test Your App Locally First

Step 2: Push Your Project to GitHub

Step 3: Create Your AWS EC2 Instance

Step 4: SSH Into Your Server

Step 5: Update the Server

Step 6: Install Node.js and npm

Step 7: Clone Your Project from GitHub

Step 8: Create Your .env File

Step 9: Start Your App

Step 10: App Running but Still Not Visible? Fix Your Security Group

One More Thing: Keep It Running

The Full Deployment Checklist

Closing Thoughts

Git Time Machine — How Version Control Can Save Your Project

The Moment Every Developer Dreads

First: The Mental Model That Makes Everything Click

1. git log — Reading the Timeline

2. git diff — Spotting What Changed

3. git checkout — Stepping Into the Past

4. git stash — Hitting the Pause Button

5. git revert — Undoing Without Destroying

6. git reflog — The Secret Safety Net

Putting It All Together

Closing Thoughts

10 Linux Commands That Made the Terminal Less Scary for Me

First, Why Does Linux Even Matter?

1. pwd — "Wait, Where Am I?"

2. ls — See What's Around You

3. cd — Actually Move Around

4. mkdir — Create a Folder Without the Right-Click

5. touch — Create an Empty File

6. cp and mv — Copy, Move, and Rename

7. rm — Delete Things (Carefully)

8. cat — Read a File Without Opening an Editor

9. grep — Search Inside Files

10. history — Your Terminal Remembers Everything

🎁 Bonus: man — The Manual That's Actually Built Into the Terminal

What the Terminal Actually Teaches You

Step 8: Create Your `.env` File

1. `git log` — Reading the Timeline

2. `git diff` — Spotting What Changed

3. `git checkout` — Stepping Into the Past

4. `git stash` — Hitting the Pause Button

5. `git revert` — Undoing Without Destroying

6. `git reflog` — The Secret Safety Net

1. `pwd` — "Wait, Where Am I?"

2. `ls` — See What's Around You

3. `cd` — Actually Move Around

4. `mkdir` — Create a Folder Without the Right-Click

5. `touch` — Create an Empty File

6. `cp` and `mv` — Copy, Move, and Rename

7. `rm` — Delete Things (Carefully)

8. `cat` — Read a File Without Opening an Editor

9. `grep` — Search Inside Files

10. `history` — Your Terminal Remembers Everything

🎁 Bonus: `man` — The Manual That's Actually Built Into the Terminal