██FR█████ █INTELL███████████

VPS For Frontend Engineer – Part 1


This content originally appeared on DEV Community and was authored by Joseph42A

I remember the first time I tried to deploy my web app on a VPS. It was a horrible experience! Then I switched to Cpanel deployment. Ohh, that was even worse than a VPS, lol. After years of taking on multiple full-stack projects, I truly believe if I had taken a course earlier, I would be on another level right now.

So, if you’d love to dive into DevOps, stick with me and practice alongside. We’ll cover more things later, like AWS, Docker, and more.

I know you may be asking why a frontend developer needs VPS knowledge when you can deploy an application with one click?

Vercel, Netlify, GitHub, etc…

You’re correct, if you’re just a “vibe coder”!

To be honest, it has a lot of benefits. For starters, it gives you free SSL, which many providers are now selling you!

Don’t stick with only frontend skills in the age of AI. To be honest, as a frontend developer with over 5 years of experience, I don’t think we’ll survive with only FE skills.

Learn a new skill, open a new horizon. Instead of complaining, explore the world!

As someone who has learned these skills, I can now communicate and better understand what my team is really talking about.

CI/CD, Docker, Redis, Cloudflare, etc…

Here’s the thing: today’s market is rough! You have to gain more knowledge and not just focus on one area, especially frontend.

And don’t worry if you enjoy coding already, you’ll find VPS super fun to learn. Many new concepts and pains you currently suffer from will go away.

One last thing: it’s super easy to learn but incredibly valuable to have in your skillset.

Let’s dive in!

What we’ll learn in this article?

You’ll learn and master the following points in three articles.

Part 1

  1. Setting Up Our Custom VPS
  2. Best Practices for Accessing and Using a VPS

Part 2

  1. Falling in Love with NGINX
  2. Configure a Domain and Subdomain with Free SSL
  3. Setting Up Node.js and Next.js applications

Part 3

  1. Docker
  2. CI/CD and GitHub Actions so you don’t need to touch the VPS again, lol!
  3. Load Balancer

First Step: Buying a VPS

First, we have to buy a VPS. One of the best providers is DigitalOcean. For learning purposes, it won’t cost you anything for the first 2 months. You can click the link below to sign up and get a $200 credit to use on DigitalOcean.

digitalOcean

After that, go ahead and create a Droplet (VPS). Choose and fill out the options. The important thing here is that we’re using Ubuntu, so make sure you’re using the latest LTS version.

Setup SSH to Login

One of the best security practices is to log in via SSH instead of a password.

SSH login is a secure way to connect to a remote server over the internet using the Secure Shell (SSH) protocol.

So, in a nutshell, with SSH key login, you have:

Public Key → Stored on the server (~/.ssh/authorized_keys) to recognize you.

Private Key → Kept on your local machine and never shared; used to prove your identity when connecting.

From DigitalOcean, click on Add SSH Key as you see below.

Okay, now let’s create an SSH key and upload the public key here on DigitalOcean.

It’s super easy to create SSH keys. Run:

ssh-keygen

You can give it a name (I’ll use frontend-key) or let it be the default name and path (~/.ssh/). It will ask you to create a passphrase (you can skip this if you’d like).

Now you’ve got two keys:

  1. Private key: ~/.ssh/frontend-key
  2. Public key: ~/.ssh/frontend-key.pub

Note that you can differentiate the public and private keys by their file extension. The public key ends with .pub.

Now, in order to log in to the server, we always have to specify where our private key is by running this command:

ssh -i ~/.ssh/frontend-key root@server_ip

To avoid specifying the private key every time, we can run an ssh-agent and add the private key to it. That way, we can just run ssh root@server_ip to log in to the server.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/(your_private_ssh_key)

One last thing before we try to access our server: we have to add our public key to the server (remember, the one that ends with .pub is the public key).

Using the cat command, we can display the content inside the .pub file and copy it:

cat ~/.ssh/(your_private_ssh_key).pub

Upload this key to the Add SSH Key section in DigitalOcean.

Disable the root User

The next security best practice is to disable login for the root user. Since the root user is the highest level and can do anything on our system, disabling it protects us from attacks and the risk of unauthorized access.

The first step is to create a new user. We want to be 100% sure the new user works correctly before we disable the root user.

Run this command to create a new user:

adduser newUser

Note: You may need to run this command with sudo if you encounter a permission denied error.

It will ask you to create and repeat a password. You can skip the other questions by simply pressing Enter on your keyboard.

Then, we’ll change the group for that user to be sudo so they can run high-level commands, just like the root user.

usermod -aG sudo newUser

Switch to the newly created user:

su newUser

Now, before testing this user, we have to upload the public key into a special file called authorized_keys. Go ahead and create the SSH directory for your new user:

mkdir ~/.ssh
chmod 700 ~/.ssh
cd ~/.ssh
touch authorized_keys

Now you can open that file with the vim or nano editor and paste the public key. You can use the same public key you used for the root user or create a new one. (Note: You may need to run this with sudo, e.g., sudo vi authorized_keys).

The last step is to change the permissions for that file and restart the SSH service:

chmod 644 authorized_keys
systemctl restart ssh

The number 644 means that only we (the owner) can read and write, but other users can only read. You may not understand these numbers, but they all have a meaning. They are represented in octal, which is a base-8 number system.

Each permission is assigned a value:
read (r) = 4
write (w) = 2
execute (x) = 1

You add these values to get the number for each category. For example, to give full read, write, and execute permissions, you’ll use 7 (rwx = 4+2+1 = 7). We used three digits together (644), which means the first digit is for the owner, the second is for the group, and the third is for others.

So if you want to give all types of users all permissions, you would say 777 (rwx).

Now, test logging in with this user:

ssh newUser@server_ip

Boom!

Now let’s disable the root user.

Switch back to the root user:

sudo -i

Then, go to the SSH daemon configuration file at /etc/ssh/sshd_config to disable root login. Find the line that says PermitRootLogin and change it to no. (But please make sure you’ve already tested your new sudo user, otherwise you’ll lose everything!).

Now our server is ready, and we can securely access it via SSH without the root user.

In Part 2, we will set up NGINX and prepare our server for a full-stack, production-ready deployment.

Cheers!


This content originally appeared on DEV Community and was authored by Joseph42A