EC2: Launch Your First Server and Deploy Next.js Manually

Concept

EC2 (Elastic Compute Cloud) is an AWS service that gives you a computer to rent, billed by the second. It is a real Linux machine with a CPU, memory and a disk, in an AWS data centre. You get a login and full control. You can install anything, run anything and break anything. One rented machine is called an instance.

This is the moment the whole course has been leading to. Lesson 1 taught you Linux. Lesson 2 taught you the network. Lesson 5 taught you identity, and Lesson 6 built the room where this server will live. Now you put the first server in that room and run your Next.js app on a machine you control.

Why do it by hand first

Real teams do not log in to servers with SSH to deploy. They use pipelines. A pipeline (CI/CD, short for continuous integration and continuous delivery) is a set of steps that builds, tests and deploys your code automatically. So why learn the manual way?

• You cannot automate what you do not understand. A pipeline is just this lesson's commands written in a YAML file (a simple text format for settings). When the pipeline breaks at 2 a.m., you log in with SSH and run the steps yourself.
• Every production problem ends at a server. You read logs, check a process and find a full disk. This lesson teaches those skills.
• It shows what Vercel hid. Environment variables live in a file. A program must watch your process and restart it. Memory is limited. Disks fill up.

The seven words you must know

Instance types and picking a size

An instance type name is a code. In t3.small, t is the family (general purpose, burstable), 3 is the generation and small is the size. A g in the family (t4g, m7g) means an ARM “Graviton” CPU. ARM is a different CPU design. It is cheaper for the same power, but your software must be built for ARM.

Prices are on-demand (pay as you go) for Mumbai, running all month. Always check the current pricing page.

Launch the server

Go to EC2 → Launch instance. The form is long, but only a few fields matter. Leave everything else at its default.

Then give the server a permanent address: EC2 → Elastic IPs → Allocate → Associate with your instance. Without it, the public IP changes every time the server stops and starts, which breaks your DNS record (the entry that links your domain name to the IP). Every public IPv4 address costs $0.005 per hour, whether it is attached or not. So release the Elastic IP when you delete the server.

Connect with SSH

Tip: add a Host myapp entry to ~/.ssh/config on your laptop. Put the IP, user and key path in it. From then on, ssh myapp is enough.

Prepare the server

A fresh server has nothing on it but Linux. Do these once, in order:

1. Update the system

   Install the security fixes released since the image was built. Also install git and the build tools that some npm packages need. If the kernel (the core of the operating system) is updated, you may need to reboot.

2. Add a swap file — the safety net for small servers

   Swap is a part of the disk that the system uses as emergency memory when RAM is full. It is slow, but it turns “process killed” into “build took a bit longer”. next build is the step that uses the most memory in the life of your app. A 2 GB swap file is enough on a t3.small.

3. Install Node.js

   Install Node 22 LTS from NodeSource (a package source for Node) and enable corepack. Corepack is a Node tool that gives you the pnpm or yarn version your project expects. Node 24 is the newer LTS, so either works. What matters is to use the same Node major version on your laptop, in CI and on the server. Otherwise you will chase “works on my machine” bugs.

4. Give the server read-only access to your repository

   A private repository needs credentials. Do not copy your personal SSH key onto a server. Instead, make a new key on the server. Add its public half in GitHub → repo → Settings → Deploy keys. A deploy key is an SSH key that works for one repository only. Leave “Allow write access” unchecked. If the server is ever broken into, the attacker can read one repository. They cannot push code or touch your other projects. This is least privilege (Lesson 5) applied to Git.

Deploy Next.js by hand

Clone the repository into your home folder. Create a .env file next to it and set its permissions to 600 (only you can read and write it; Lesson 1). On Vercel these values lived in a dashboard. Here they are in a file. For now the file needs only NODE_ENV=production and PORT=3000. The database comes in Lesson 8. AWS credentials are not in the file on purpose, because the IAM role provides them. Then run:

See it in your browser

The app listens on port 3000 (a port is a numbered door on a computer for network traffic), but web-sg does not allow that port. Add a temporary inbound rule for port 3000 with the source My IP. Then http://SERVER_IP:3000 works, but only for you. Delete that rule after Lesson 10, when Nginx takes over ports 80 and 443. Port 3000 must never be public.

Keep it alive with PM2

PM2 is a process manager for Node.js. It starts your app, restarts it if it crashes, and can start it again after a reboot. You need it because pnpm start in your SSH session stops the moment you close the terminal. This is the problem from Lesson 1 again: something other than your shell must own the process.

Test it: reboot the server, wait a minute, log in again and run pm2 status. If myapp is online, it survives reboots. If not, you skipped startup or save. Day to day you will mostly use pm2 logs, pm2 restart and pm2 status.

Prove the IAM role works

Lesson 5 promised that the server could call AWS without any access keys. Run aws sts get-caller-identity on the server. This command shows who AWS thinks you are. The ARN now says assumed-role/myapp-ec2-role/i-0abc…. You are wearing the role, and there is no credentials file in ~/.aws.

The temporary credentials come from the instance metadata service (IMDS). This is a small web service that every instance can reach at the address 169.254.169.254. The credentials are replaced automatically every few hours. The AWS SDK in your Node app reads them the same way. This is why the S3 upload code in Lesson 5 needed no keys. The role only allows s3:PutObject and s3:GetObject on one bucket. So even a fully hacked app cannot delete your database.

Deploying a new version

Now the loop you will repeat until Lesson 14 automates it. Pull the new code, install, build, then run pm2 reload myapp. Reload is a gentle restart. (For a true zero-downtime reload, PM2 must run your app in cluster mode. In the simple setup here, expect a short gap.) Put the four steps in a small deploy.sh script that stops at the first error. Then you never skip a step at 11 p.m.

Notice what is wrong with this way. Lesson 14 fixes each problem. The build runs on the production server, so it competes with live traffic. A failed build can leave the site broken. There is no easy rollback (going back to the previous version). Only people with SSH access can deploy.

Disks, stop vs terminate, and the bill

The disk

The root disk is an EBS volume. This is a drive that connects to the server over the network. It is billed per GB per month (roughly $0.10 per GB for gp3, so 20 GB costs about $2). gp3 is a type of SSD disk. The disk survives when you stop the server. You can make it bigger later without downtime, but you can never make it smaller.

When something fails for no clear reason, check the free disk space first. When the disk is more than 90% full, builds and logs start to break. The usual causes are logs, node_modules and old builds.

Stop, terminate — and what each costs

Stop switches the server off, like shutting down a PC, and you can start it again later. Terminate deletes the server for good. They are different, so choose carefully.

Everything this lesson costs

New AWS accounts may also get promotional credits and a free plan for the first six months. Check the Billing console to see what your account has. Do not assume anything is free, and keep the Lesson 5 budget alert on.

Troubleshooting table

Interview corner

Practice task before Lesson 8

1. Launch the server and deploy your Next.js app as above. Open http://SERVER_IP:3000 from your laptop.
2. Reboot the instance and confirm the app comes back by itself without you touching it.
3. Run aws sts get-caller-identity on the server. Find the role name in the ARN. Then run aws s3 ls — it should be denied. Which line in the Lesson 5 policy explains why?
4. Kill the app's process on purpose and watch PM2 start it again. Look at the restart counter in pm2 status.
5. Add a page to your app, push it, and deploy it by hand. Measure how long the site was unavailable, if at all. Write down two ways this process could go wrong.
6. When you are done for the day, stop the instance. Start it tomorrow and confirm the IP is unchanged.

Conclusion

You now have a real server running your real app. You also know which parts of a Vercel deploy you replaced.

• EC2 = a rented Linux computer. You choose the image, the size, the disk and the network.
• Safe defaults that cost nothing: an encrypted disk, IMDSv2 required, SSH only from your IP, an IAM role instead of keys, and a read-only deploy key.
• Something must watch your process: use PM2 with startup and save, so the app survives crashes and reboots.
• Stop it, do not forget it: a running instance bills every second. A stopped one costs only its disk and IP.
• The manual deploy is the blueprint for every automation to come: Docker (Lesson 9), CI/CD (14), Terraform (15).

The app is running, but it has nowhere to keep data. Next we add a managed PostgreSQL database that sits safely in the private subnet.

End of Lesson 7. Next: Lesson 8 — RDS: Managed PostgreSQL.