Hosting a FullStack Javascript Web App on Digital Ocean Part 1

This is the first of a three part series showing how to host a fullstack MERN app, both the Node JS back-end and React front-end on one Digital Ocean droplet. Please find the introduction here

Creating A Digital Ocean Droplet

First things first, we have to create a Digital Ocean account. I suggest creating one using your existing github account. After that login to your Digital Ocean dashboard, click on the Create drop down and select Droplets.

In the first section, select Ubuntu OS for the server.

Select Ubuntu Server OS

Then select the $5/month plan for the lowest prices.

Select cheapest pricing plan

Choose the closest location to you for the physical data center region. Also note that you need to choose the same location for all your droplets if you will ever need them to connect to each other using a LAN.

Choose a datacenter

Under authentication, select SSH keys and click on New SSH Key to add a new key. Enter the following command on the terminal on your local machine to generate a new SSH key pair.

$ ssh-keygen

Click enter to accept the empty passphrase and other default settings. The above command generates two files: id_rsa & id_rsa.pub. Enter the following command to stream the contents of the id_rsa.pub file.

$ cat ~/.ssh/id_rsa.pub

Copy the contents of the file from the terminal into the SSH key content field in Digital Ocean and click on Add SSH Key. Then select the newly added SSH key as shown below.

Select SSH authencation

Choose a memorable host-name for the droplet and then click on Create Droplet to finalize the process.

Connecting to the Droplet Using SSH

You should now have access to your newly created droplet. If not, click on the Droplets link on the side bar to the left. This should take you to your droplets where you can access your droplet’s IP address. Use this IP address to access your droplet using ssh by typing the following command on your local machine’s terminal.

$ ssh root@your_server_ip

Accept the warning about host authenticity if it appears.The root user is the administrative user in a Linux environment that has very broad privileges. So the next step is setting up a new user account with reduced privileges for day-to-day use. Once you are logged in as root, you’ll be able to add the new user account. In the future, we’ll log in with this new account instead of root. To add the new user enter the following command.

# adduser username

You’ll be asked to enter the user’s password. Make sure to enter a strong password since this will be used for commands prefixed with sudo later on.

Output
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Next, you’ll be asked to fill in some information about the new user. It is fine to accept the defaults by hitting ENTER and leave this information blank:

Changing the user information for sammy
Enter the new value, or press ENTER for the default
    Full Name []:
    Room Number []:
    Work Phone []:
    Home Phone []:
    Other []:
Is the information correct? [Y/n]

Use the usermod command to add the user to the sudo group:

# usermod -aG sudo username

To test that the new sudo permissions are working, first use the su command to switch to the new user account:

# su - username

As the new user, verify that you can use sudo by prepending sudo to the command that you want to run with superuser privileges. For example, you can list the contents of the /root directory, which is normally only accessible to the root user using:

$ sudo ls -la /root

The first time you use sudo in a session, you will be prompted for the password of that user’s account. Enter the password you set above. To go back to the root user account type in:

$ exit

While in the root user account, we need to setup the UFW firewall to make sure only connections to certain services are allowed. Applications can register their profiles with UFW upon installation. These profiles allow UFW to manage these applications by name. OpenSSH, the service allowing us to connect to our server now, has a profile registered with UFW. You can see this by typing:

# ufw app list
Output
Available applications:
  OpenSSH

We need to make sure that the firewall allows SSH connections so that we can log back in next time. We can allow these connections by typing:

# ufw allow OpenSSH

Afterwards, we can enable the firewall by typing:

# ufw enable

Type y and press ENTER to proceed. You can see that SSH connections are still allowed by typing:

# ufw status
Output
Status: active
To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

The next step now is to make sure we can SSH into the regular user account for daily use directly. We will need to add a copy of our local public key to the new user’s ~/.ssh/authorized_keys file to log in successfully.

Since our public key is already in the root account’s ~/.ssh/authorized_keys file on the server, we can copy that file and directory structure to our new user account in our existing session.

The simplest way to copy the files with the correct ownership and permissions is with the rsync command. This will copy the root user’s .ssh directory, preserve the permissions, and modify the file owners, all in a single command. Make sure to change the appropriate portions of the command below to match your regular user’s name:

Now, open up a new terminal session on your local machine, and use SSH with your new username:

$ ssh username@your_server_ip

You should be logged in to the new user account without using a password. Remember, if you need to run a command with administrative privileges, type sudo before it like this:

$ sudo command_to_run

You will be prompted for your regular user password when using sudo for the first time each session (and periodically afterwards).

This ends part 1 of the series. Check out part 2 here.