📡 How To Deploy Ruby on Rails Apps To The Internet (Production/Staging)

Heroku / Digital Ocean / Rackspace / AWS Ruby on Rails Deployment Tutorial → Apache & Passenger…

Frontline Utilities LTD

Published in

💎 Ruby on Rails Web Application Development 💎

27 min readAug 20, 2017

ℹ️ Update (August 2019)

Switched from NGinx to Apache
Updated LetsEncrypt
Updated GIT

Having recently re-deployed a number of client VPS instances, it became apparent that NGinx is too fiddly to continue using it. We now use Apache, with libapache2-mod-passenger — no messing around, just install and run…

📆 August 2019 Update! 📆 → Video explaining an introduction to the Installation & Deployment Process…

We Use **DigitalOcean** (production) & **Heroku** (staging)…

Whilst Heroku works well for Rails deployments, it’s not competitive for
production environments. There are cheaper, more versatile solutions.

TL;DR → We use $5/mo VPS servers at DigitalOcean in production.
For staging, we use Heroku’s free tier…

➡️ Overview

Shared hosting does NOT support Rails (very well anyway)…

Our old host — **Site5** — was GREAT… but didn’t support Rails (at least a recent version)…

Even though many shared hosts are claiming to support modern languages
& frameworks (Scala, Rust, NodeJS, Go, etc), CPanel hosting is mostly antiquated and unable to provide the versatility required to keep up.

To this end, it’s strongly recommended you avoid shared hosting for Rails. There is no need to use it when you have better (& cheaper) options…

We use **DigitalOcean** for inexpensive Rails VPS hosting…

The crux is that in order to get access to the OS-level dependencies required for new frameworks, it’s recommended you use a private VPS.

Whilst many incumbent hosts provide these, they operate on the basis of renting out physical server space. For example, Site5 (our old host) gives you the option of paying $65/mo for a 50GB/2CPU VPS:

The same (or at least similar) spec is available for $10/mo from DigitalOcean:

DigitalOcean is one of the more popular “cloud” VPS providers…

DigitalOcean, AWS, Azure, Google Cloud Engine, UpCloud, Exoscale, Hetzer, Scaleway (and several others) are able to do this because they work differently to “traditional” hosts. They are “cloud” providers…

Cloud VPS technology is not tied to a physical box.

Unlike “shared” hosts, the new “cloud” platforms make their entire data center (of 1,000’s of servers) available to users. This is achieved with “hypervisor” software managing the virtual hosts.

This dramatically reduces cost, allowing us to run a number of Rails apps across $5/mo worth of infrastructure…

AWS Data Warehouse — AWS allows you to run private VPS instances across 1,000’s of servers, reducing the cost

Presently, “cloud” hosting the most cost-effective and versatile solution for any modern web framework (not just Rails).

There’s a video from AWS explaining it all here:

Amazon EC2 is often regarded as the service which popularized “cloud” hosting

The drawback with cloud is that there is little support for the management of the servers (something traditional hosts do well).

In other words, you are responsible for setting up the server yourself. Whilst this may seem daunting, it’s actually very simple, and is explained below.

You can jump to configuration here.

✅ Setup

Hosting infrastructure (for any language/framework) requires a “stack” of software in order to facilitate responses to inbound HTTP requests.

Web hosting stacks consist of 3 elements (or “tiers” as they’re often called):

Web (HTTP) server software
Application (Ruby/PHP/Python/NodeJS) server software
Database (MySQL/PGSQL) server software

This software works together to accept inbound HTTP requests, build an HTML-formatted response, which is then sent to the client.

—

A Rails hosting stack requires:

🔧Server 🔧
📭 Domains 📭
🔋 OS 🔋
🚧 Install Dependencies / Build Tools 🚧
💎Install Ruby (rbenv) 💎
📋 Install Rails & Bundler (gems) 📋
💻 Install Web Server (Apache + Passenger) 💻
🔒 Create Database 🔒
📢 Create Git Repositories On Server 📢
📡 Initial Push 📡
✔️ Bundle & Asset Precompilation ✔️
⛔️ Restart ⛔️
⚠️ Test ⚠️

—

Putting this into perspective, you must appreciate there are
TWO types of hosting → managed and unmanaged…

Heroku is managed
DigitalOcean is unmanaged

Most managed hosting runs the LAMP (Linux/Apache/MySQL/PHP)
stack (cannot run Rails — or the latest version, at least).

Whilst Heroku is the only managed solution for cloud VPS servers, their costs rise sharply after the free tier, making it unsuitable for production…

Heroku’s good for staging but costs rise sharply after the free tier…

As described above, the solution to this is to provision our own “cloud” VPS server… but that means deploying the software stack ourselves.

To better explain, it’s important to understand how the web works.

🔄 ️Web

When setting up a web server, you need to consider how they actually work. The web is basically an app for the Internet.

What we call the Internet is really TCP/IP… a communications protocol to connect two systems together via an IP address…

The web is a PUBLIC version of TCP/IP— allowing users to access publicly available information on computer systems that publish their IP via the
HTTP Protocol. Apps like Google allows us to search these public IP’s to find content on each computer.

Domain names were introduced to mask these public IP addresses.

The point is that web hosting is simply the process of creating a web server
to make your IP public, and display your files to the world…

All hosting providers essentially give you a “public” Internet-connected computer…

The job of a web hosting company is to provide access to servers so that you don’t need a computer running in your basement.

Web hosting works by providing a public IP to which you point your
domains to via their DNS listing:

**DNS** options are managed by the domain registrar….

Rails works outside the scope of HTTP (web).

Because it doesn’t have HTML files, it cannot rely on web server software to deliver pre-built responses (as you would a static HTML site).

Rather, it needs another piece of software to help it process requests → application server software (in the case of Rails → Phusion Passenger).

This runs on the server and forms a response for HTTP requests; mimicking what HTML files are meant to do.

Since Passenger is not installed on most shared hosts, it cannot run Rails. Further, there are a number of other dependencies required to get a Rails-compatible server working.

The extra elements required to get a web app working are known as a stack…

📢 Stack

Setting up a web “stack” means installing everything OTHER than the
web server software…

✅ Public IP (DNS)
✅ VPS / Server (physical box)
⚪️ OS
⚪️ Programming Language / Libraries
⚪️ Web Server (catch inbound DNS requests. Software or hardware)
⚪️ Application Server (run Rails apps. Software or hardware)
⚪️ Database Server (database, email etc — typically third party)

Whilst the ‘stack’ has existed since the web’s inception, it’s only started to become well-known as developers have taken to setting up their own servers:

ALL hosting companies provide ✅ (IP & server).
⚪️ determined by the type of hosting.

The web stack is rigid in requirement (every web app has to adhere to the HTTP protocol). Difference lies in how other elements are managed.

This is what we need for Rails…

💎 Rails

Rails ‘stacks’ require the following:

SSH access (to push code)
Root level dependency installation (extras required by rails)
Ruby implementation (no host can do this)

The crucial element is Passenger…

**Phusion Passenger** is essential to run Rails on VPS servers (above are its error pages)…

Passenger is an application server that runs Rails.

Whilst not the “only” Rails application server, it’s the most widely used.

If you want to set up your own Rails server, you need to use Passenger. This is easily done with native NGinx integration.

However, you need to know what you’re doing. This is not possible on shared hosting, hence why we’ll use a VPS…

🔧Server🔧

The first step is to set up a server (physical box).

To do this, you need to determine which host you’re going to use.

As mentioned, there are two types of hosting → managed & un-managed.

For Rails, the only managed hosting is Heroku. There are a multitude of other non-managed hosting providers. Our preference is DigitalOcean.

We’ll detail how to set up a “server” on each:

0️⃣ Heroku (Staging)

We use Heroku in staging…

Heroku is a freemium app hosting platform, now owned by Salesforce.com

Its free tier is the best for Rails development.

To set up apps on Heroku, you need to provide credit card information
(in case you go over the 950 free hours each month):

Heroku works differently to other setups.

Basically, it has two processes → build and runtime.

When you create an app, you push it to Heroku’s build server…

This server compiles the app into what Heroku call a slug…

Slugs are compressed and pre-packaged copies of your application optimized for distribution to the dyno manager.
When you git push to Heroku, your code is received by the slug compiler which transforms your repository into a slug. Scaling an application then downloads and expands the slug to a dyno for execution.

The slug acts like a container image, allowing Heroku to quickly provision
your application on any of their runtime servers.

Their runtime servers come in two forms — Cedar-14 and Heroku-16 (Heroku-18 currently being tested).

Each server is built around a long term supported version of Ubuntu:

Heroku deploys a number of “stacks” to run any web based app you need…

These provide dependencies necessary to get a Rails app working.

Heroku accepts inbound GIT repositories via its build servers, allowing you
to “push” new apps. When a new push is received by Heroku, its build server will “compile” the app and create a slug ready to be used in runtime.

1️⃣ Digital Ocean (Production)

We use Digital Ocean in production…

DigitalOcean allows you to create a “droplet” (VPS instance).

You need to create a new droplet (requires signup & payment) ↴

Coupons
You can use the following coupons for discounts:DROPLET10
ALLSSD10
DODEPLOY
SHIPITFAST10
OMGSSD10
FRANKFURT

To create a droplet, you need to select Ubuntu 18.04 x64 (latest compatible with Passenger), and pick a location nearest to your largest traffic source:

Obviously select the location closest to the majority of your traffic…

You should call the droplet by the primary domain of your website.

This sets the PTR value, which gives the server its name in various services:

Once created, it will provide you with an IP address.

This is what you route your domain(s) to...

📭 Domain 📭

Next, you need to point your “domain” to the server via its DNS records.

This is done where the domain is hosted (registrar or host).

We use Namecheap but you may use a different service:

If you need help with this, please feel free to contact **rpeck@frontlineutilities.co.uk**…

There are two ways to set up the DNS:

1. Name Servers

If you’re using a managed service, they may give you a set of
name servers which you can put into the registrar.

Name servers are a simple way to route domain name traffic.

Their real value comes from hosting companies; most people who set up simple wordpress sites don’t want to be bothered with advanced DNS
records, only want to input ns1.host.com or ns2.host.com…

2. DNS Zone File (typically with the domain registrar)

If you’re using a private VPS, you may be able to input the IP directly into the
DNS Zone file. How you do this depends on which domain service you use.

There are a number of DNS records you can set, including:

A
Returns a 32-bit IPv4 address, most commonly used to map hostnames to an IP address of the host
CNAME
Alias of one name to another: the DNS lookup will continue by retrying the lookup with the new name
MX
Maps a domain name to a list of message transfer agents for that domain

A private VPS will allow you to point A records to the IP of the server.

Other services, such as Heroku, encourage the use of CNAME records
to mask the Heroku subdomain of your app:

We recommend setting the A records in your registrar’s DNS zone file.
This way, all the specifics are handled by the registrar and not DigitalOcean.

Our Setup

For Namecheap (our registrar), you just have to click onto the domain in the control panel and select Advanced DNS. It’s a similar process for GoDaddy…

You need to create two “A” records (for www and @) which will point
to the IP of the server:

⚙️ ️IPv6

IPv6 isn’t essential, but does provide you with the ability to serve functionality to clients running on it. Unfortunately, the process for enabling it is not as streamlined as IPv4 yet…

We use IPv6 on our Rails apps (something you can’t do with Heroku)…

The following is directly referenced from here:

Enable IPv6 From the DigitalOcean control panel (if using DO)
Click on the VPS server of your choice > Networking > “Enable IPv6”

Click the button to power-off the VPS
This allows DigitalOcean to provide the IPv6 details

Configure Droplet To Use IPv6
This requires logging into the droplet using the SSH console. We cover this in the next segment, so if it confuses you, please use the steps outlined below…

This is our outdated version (from Ubuntu 16.04) — you need to read the DigitalOcean tutorial to get the latest 18.x structure…

The following is what you need to do to configure the droplet depending on which version of Ubuntu you’re using…

It must be stated that this is required because your server — by default — won’t have the IPv6 values set up. All you’re doing is setting the value of the IPv6 address, and giving the OS the ability to connect via the IPv6 protocol.

Reboot
After doing this, reboot your system using the sudo reboot command.

Check IPv6
After doing the above, you need to check to see if the IPv6 setup works, which can be done by pinging Google’s IPv6 address:

# From your Droplet's SSH console
ping6 2001:4860:4860::8888

If this returns a positive response, it means you’re going to be able to use the IPv6 protocol for your site.

Set Your DNS AAAA Settings To The New IPv6 Address
AAAA records are for IPv6 clients — you can set them to tell browsers where to access the IPv6 version of your web resource. You need to set them to ensure that you’re utilizing the system as effectively as possible:

—
Good explanation from DigitalOcean.

Another good tutorial about how to handle this with DigitalOcean directly (IE setting the DNS nameservers in your registrar to DigitalOcean’s).

🔋 OS 🔋

Most VPS services provide OS images when you set up a server…

If you don’t have an OS installed, you need to install one.

We recommend installing the latest version of Ubuntu (currently 18.04).

Some may opt for the LTS version because it is deemed more stable. Doesn’t really matter, as long as it’s not ancient.

💻 SSH

On top of this, we also need to set up SSH.

SSH is the protocol used to connect to our newly created VPS server.

Use the public IP (mentioned above) to connect to the box via SSH.

To do this initially, you need to click on the “Console” button on the top right of the work area. This will load up a small console which is already logged-in as root…

When you first load the droplet, it will ask you to reset the root password
Do this to your choice
After this, you should gain root access to the box
You then need to create a new “deploy” user
This user will be used instead of root (protects security):

useradd deploy
usermod -aG sudo deploy

After this, you’ll have to then change the /etc/ssh/sshd_config file to ensure that root cannot access the server. You’ll also want to change the SSHport so hackers don’t have it easy:

nano /etc/ssh/sshd_config

Manage sshd_config from within DigitalOcean’s console…

You should change/add the following (Ubuntu):

PermiteRootLogin no
AllowUsers deploy

This will ONLY allow the recently created deploy user to log in with SSH.

Make sure you do the following (and remember, this is Ubuntu → if you’re using another OS, it will be different):

Change the port to something other than 22 (adds more security)
Deny root access via SSH
Add the “deploy” user (or whatever username you used)

Save the document (with nano, it’s CRTL + x).

At this point, if you’re not kicked off by the console, you should re-access the system with the deploy user. This allows you to test that the user is functional, and that you’re able to use it to login correctly.

To finalize, restart the ssh service(s):

sudo service ssh restart
sudo service sshd restart

Once you’ve done this, exit the online console and load an SSH client from your computer. If you’re using Windows 10, you can use CMD :

Good article from **HowtoGeek** about enabling SSH in Windows 10

For previous Windows versions, PuTTY:

🚧Dependencies 🚧

Next, you need to set up the various dependencies & build tools for Rails.

This is best done using the following:

sudo apt updatesudo apt install git-core curl zlib1g-dev build-essential libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev libcurl4-openssl-dev python-software-properties libffi-dev nodejs imagemagick libmagickwand-dev nodejs yarn

Basically, each time you use Ruby/Rails, there will be a number of packages required by the system.

In the case of the mysql2 or rmagick gems, for example → you’d need to install separate packages (which aren’t included above). The above just gives Rails the ability to utilize 90% of the functionality it requires to run.

💎Ruby💎

After installing dependencies, you need to install Ruby.

There are several ways to do this.

We now prefer rbenv, as this allows you to install & manage multiple Rubies on the same system:

cd
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
exec $SHELL

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' >> ~/.bashrc
exec $SHELL

rbenv install -l
ruby -v

The build process should take some time.

Don’t do anything, just let it install (and follow the prompts where required).

The big difference with rbenv is that it makes ruby accessible for all users without the need for sudo permissions.

This means that if you want to run bundler or use the likes of GIT (below), it makes the entire compilation process MUCH easier. Strongly recommended.

📋 RubyGems 📋

We should have already installed RubyGems with the dependencies (above).

You now need to install the bundler and rails gems…

gem install rails
gem install bundler

These should install the base gems required for your application.

Installing them on a global / system level makes them accessible to all apps.

💻 Web Server 💻

Next, we will need to install web server software.

We use Apache (Nginx works just as well), because it’s the most simple and effective for Ruby & Passenger. You’re also able to obtain LetsEncrypt certificates easily with it.

Installation is simple:

# Install Apache
sudo apt install apache2

—

# Install Passenger
sudo apt install -y dirmngr gnupg
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 561F9B9CAC40B2F7
sudo apt-get install -y apt-transport-https ca-certificates

# Add our APT repository
sudo sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger bionic main > /etc/apt/sources.list.d/passenger.list'
sudo apt update

# Install Passenger + Apache module
sudo apt install -y libapache2-mod-passenger

—

# Enable Passenger
sudo a2enmod passenger
sudo apache2ctl restart

You can read the official tutorial on how to do this here ↴

After this installs (considering it ran correctly), you will need to ensure it is working. To do this, input the following command:

sudo /usr/bin/passenger-config validate-install

After this (if successful), you need to go on your web browser and load
the IP of your server. You should see the following:

If this shows, it’s a good day.

Now, setting up Apache can be tricky.

To explain, you have to appreciate how web server software works.

Basically, the web server software will catch ALL requests made to your server’s IP through port 80 or 443.

It then uses virtual servers to “route” those requests to appropriate configurations. The routes will be determined by the requesting domain.

When setting up your server, you need to know which domains are going to be sending traffic. Both Apache and Nginx work by storing two folders with configuration files inside /etc/nginx/sites-available/yoursite.com or /etc/apache2/sites-available/yoursite.conf and the equivalent sites-enabled…

Neither web server cares what’s in the sites-available folder, only
sites-enabled.

It will match the inbound request to any of the sites listed in the enabled folder. It also has a default which is used as a fallback.

We set our system up by defining our primary configuration inside the default conf file. This (in both servers) gives us a central location through-which to define a series of server-wide conditions:

Apache

No need for separate SSL import
All files work with LetsEncrypt

NGinx

The best way to get the above working is to let the base/default system run, follow the SSL steps below (to get the certificate assigned), and then format the various domains you want to have hosted on the server.

—

🔒 SSL/LetsEncrypt

In order to protect your domain from a number of attacks, it’s recommended you protect it with SSL. SSL is basically a secure method of HTTP transfer, using TCP port 443, rather than HTTP’s standard port 80…

**HTTPS** is now widely used & recommended by Google — good article from WebHostingSecrets.

SSL certificates come in 3 “flavors” → each using the same encryption technology to keep HTTP applications protected. The importance of this is that it doesn’t matter which SSL certificate you end up using, the only difference lies in how the protection is shown to your visitors.

For the sake of this tutorial, we’ll just use LetsEncrypt to secure it.

Because we’re now using Apache (rather than Nginx), this process is extremely simple. It requires installing the certbot package through apt:

LetsEncrypt’s “certbot” is very easy to install and use…

Whilst SSH’d into your VPS, run the following commands:

sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt updatesudo apt install certbot python-certbot-apache

This will install the “certbot” package, allowing you to run the following command:

sudo certbot --apache

This will run the certbot agent, identifying the domains you have created in your Apache configuration above, and *should* create the appropriate SSL certificates…

Good tutorial on how to use Certbot with Apache

—

For our demonstration domain (above), we originally used an SSL cert purchased through Namecheap, but we use LetsEncrypt:

You MUST remember to add the following folders to your system:

/var/www/pcfixes.com/public

This gives NGinx the ability to at least identify a route. It won’t work until you get a GIT repo set up, but at least the server should work…

You will then need to run sudo service apache2 restart

This will restart the Apache service (considering it’s successful) and should show a Passenger error page if you try and access the URL:

This should show if your server is set up correctly (app not on server yet).

🔒 Database 🔒

After this, you need a database.

Now, in terms of your set up → it depends on which server you’re using.

If you have a developed app, with lots of traffic, you may need a separate database server. This is where the likes of Heroku and other PaaS providers do quite well…

Heroku’s default is to set up a separate DB server for you…

If you’re using the likes of Heroku, you’ll be able to set up a “free” Heroku PostgreSQL database server through Amazon. This works extremely well — but (as mentioned), the costs tend to outweigh the benefits if you need a more robust solution:

Heroku’s PGSQL offering is good — but the costs can be inhibitive…

If you’re looking to get an app deployed to a private VPS, you’ll likely want to spin up a DB server directly on the server itself. This is the most common way to host a DB — often used by “shared” hosting companies as a means to save on costs…

MySQL is fully supported by cPanel — this is typically a “local” server…

The issue with this process is that you’ve got to set it up yourself, and it can be a pain to maintain. I would certainly prefer a separate DB server — but when you’re starting out, getting something running is the most important thing.

To set up MySQL on a private VPS (excellent tutorial), you can follow these steps ↴

1️⃣ Install MYSQL package on the VPS

Depending on which version of Linux you’re running (we only run Ubuntu) — the following steps will differ. DigitalOcean have two very good tutorials (16.04/18.04) on how to do this, so if you have any issues — you either have them or us to ask:

# Ubuntu 18.04
sudo apt update
sudo apt install mysql-server
sudo mysql_secure_installation# Ubuntu 16.04
sudo apt-get update
sudo apt-get install mysql-server
mysql_secure_installation

2️⃣ Configure Login, DB etc

The next screens will be a series of inputs for the likes of the system’s root password and a number of other security features…

Set root password as you require
Follow the next steps (if you want to just click next — that works)

After doing this, the system should be set up. What it won’t have is the ability to manage the various users. We had a small issue with the root access requiring a password each time…

3️⃣ Change Root User Details

After doing this, you will need to ensure the root user is able to access the database properly. To do this, you need to use the following steps:

sudo mysql -u root -p ********

4️⃣ Create New DB For Each App

Once you’re logged in to the MySQL console, you’ll need to use the following commands to create new databases for each application you’re running…

CREATE DATABASE books;
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;

Remember, any time you use a Rails app — what you’re doing is creating tables within a database. It should go without saying that you should be creating different databases for each app — allowing you to create as many tables as the application requires.

5️⃣ Exit MySQL & Set Up Rails

After doing this, exit MySQL and you’ll need to set up your Rails application…

If you’re using Rails 5.2.0, you will be best using the new credentials system to provide the database username, password etc. This saves you from having to manage all the environment variables (which can get annoying).

—
Obviously, the choice of SQL variant depends on your own specifications.

For us, being used to shared hosting, we found that MySQL is the most applicable system we could find. From it, we’re just able to install a simple instance on our VPS server and let it run.

You’d just as easily be able to use the likes of PostgreSQL and others in the same way.

📢 GIT Repo 📢

Next, we need to set up git repos for the apps.

These repos allow you to push new code to the server.

The way it works is to create a bare GIT repo in the app’s primary folder. We are then able to use a post-receive hook to push that code to the deploy folder:

sudo git init --bare /pcfixes.git

This will create a bare repo (the one we push our code to)…

On top of this, we need to add a post-receive hook which allows us to move the bare git code to a working repo:

Create a new post-receive file in /yoursite.git/hooks
Run:

chown deploy:deploy post-receive
chmod -Rf 755 post-receive

Once this is done, you’ll be able to push your code to the new repo ↴

📡 Push 📡

Once you’ve added the git repo, you need to add it as a remote repository to your system:

git remote add production 
ssh://deploy@111.111.111.11:1234/pcfixes.git

This will add the remote repository to your local git repo — allowing you to use the likes of git push production master — this is exactly how Heroku manages its GIT repositories…

✔️ Bundle ✔️

After doing this, you need to get all the gems installed by creating the first “bundle”…

Depending on how your post-receive hook is set up, it may be the case that your git repos will bundle automatically. Our git post-receive hook lacks the correct permissions, so we have to go in manually and bundle the Gemfile every time…

We are reworking our post-receive hook — but the general idea persists…

What you want is to be able to push the application, it bundles and then asset compilation works…

After the bundle completes (regardless of how you do it), the system will be able to start running and processing Rails requests.

⛔️ Restart ⛔️

Once you’ve got the above set up, restart the server.

This can be done either by using sudo reboot (if using Ubuntu), or by using the “Power Off” function in DigitalOcean:

“Power Off” simply turns off the server — you should then click “Power On” when the button appears…

You can use the “sudo reboot” SSH command from within Ubuntu…

Either way, you need to restart your server to ensure all the processes / packages are running correctly. Without this, you may not be able to identify particular issues that you may have.

⚠️ Test ⚠️

Lastly, you need to test the server setup.

If you’re using something like Heroku, the process is very simple → push the git repo to the server and let it build.

If the process returns an error (such as the images below), you’ll need to go into the logs and see what the problem was.

Obviously, the scope of errors is so vast that I’m not in a position to detail every single one here. If you need any specific help, you’re welcome to email me at rpeck@frontlineutilities.co.uk ↴

Once you push a repository to Heroku, you’ll quickly find whether it is going to succeed or not…

If you’re using a private VPS, or another self-managed service → you will not receive such tactile feedback. You’ll have to work out the problem yourself…

**Phusion Passenger** often causes a plethora of errors in a Rails server stack…

1️⃣ Access the domain through your browser → this should return the latest (current) version of the app with the correct HTTP headers etc. If it doesn’t you need to progress onto the next step…

—
2️⃣ Check to see if the web + application servers are set up correctly → it’s often the case that Apache or Passenger will have some deeper issue…

Running the following commands will show you whether they’re set up correctly:

sudo apachectl configtest
sudo passenger-status

—
3️⃣ See if your application has been deployed correctly, and resides in the correct directory for server software to access it…

Obviously, this takes time and depends on your setup.

—
4️⃣ Read the Access + Error Logs → obviously, this is going to be tricky as hell, but is sometimes necessary if you want to get to the core of the issue you’re experiencing:

NGinx’s logs reside at /var/log/nginx/access.log + /var/log/nginx/error.log…

These will often highlight errors / problems missed further up the stack.

—
If you can’t find the problem by using the above, it often means there’s either an error in the OS-layer or some other part of the system.

Again, there are *so many* potential issues that it’s best to just contact me directly if you need a second pair-of-eyes.

☎️ Further Support ☎️

Finally, if you need further help… please feel free to contact us through our sister service → 👾PCFixes.com👾. PCFixes provides live technical support for business and consumer, typically covering software centric issues:

**PCFixes.com** currently provides support services through **Fiverr**…

The service is designed to be an affordable (starting from $20) way to get direct support for all sorts of computing problems → from Wordpress errors to Rails VPS deployment.

—
We have a 👾PCFixes.com👾 live chat support channel at https://www.pcfixes.com/ → available 24/7…

👾**PCFixes.com**👾 Is Currently Voted The ⭐️**Best Live Tech Support**⭐️Service

Live support is recommend IF you use your system for business or work.

If you need the help right now, getting an expert on screen gives you the ability to at least get a second opinion (and perhaps someone to help guide you through the fix). Live support is the only way to do this.

⚠️ Do NOT use live services that charge up front. ONLY use companies who provide live support without ANY up-front commitments…⚠️

✔️ PCFixes.com is the only recognized online system repair service
✔️ PCFixes.com is operated from the UK by veteran PC repair technicians
✔️ PCFixes.com gives 24/7 support to anyone needing system repairs

📴 PCFixes.com also resolves issues with Android & iPhone

⭐️⭐⭐️⭐️⭐️

PCFixes.com is FREE to talk to anyone and you’re welcome to stay on the line for as long as you require to get things fixed.

The real benefit of PCFixes.com lies in its contributor network → if you cannot get your system fixed directly, you can use their local network (call an out an expert to come and solve the issue for you)…

👾 PCFixes.com 👾 provides 24/7 LIVE support which gives you the ability to connect with real people to get specific solutions for your system.

If you need any help identifying or solving the problem you’re experiencing, it’s worth using the service to gain a second opinion. If you want to keep them on the line whilst you try and fix it, you’re very welcome to do that…

📥 Thanks For Reading! 📥

If you need further help, please feel free to ask below…