Chazona Baum

Blog Posts

Freelance Web App with Rails API and React Frontend: Getting Set Up

Published 4 months ago


Mug with Saying: Begin

It's time to get started with the Rails API and React front end. In Part 0, I gave some background about the project, what technologies would be used and why. Feel free to check it out if you haven't already.


To get started with this project, you will need the following installed on your system. Let's get downloading!

  • Ruby - I will be using version 2.4.2 for this project. rbenv is a popular way to manage your Ruby versions, but RVM is still an option. I recommend reviewing the two options and deciding for yourself.
  • PostgreSQL - PostgreSQL is a robust, feature-rich database system, and it's the one I'll be using.
  • Postman - Postman will make it easier to build the API and test out the API calls.

Get the right version of Rails

For this project, I'll be using Rails 5.1 (currently the latest is 5.1.4), so if you don't have it, be sure to install the correct version:

gem install rails -v '~> 5.1'

Set up the API app

Let's go ahead and generate our new API app:

rails new freelance-api --database=postgresql --api

Not too many changes here, just setting the database to Postgres and using API mode. For testing, this project will stick to the default MiniTest.

Go ahead and look at the directory structure in your text editor or in your terminal with tree. If you've worked with Rails for regular web applications, you'll notice this app is a lot slimmer.

The first changes to make are with the Gemfile and the CORS initializer:

Uncomment the gem rack-cors line in the Gemfile and run bundle install in your terminal.

And in the API directory, open config > initializers > cors.rb, uncomment and modify it to read:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'

    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head]

This will allow the API to play nicely with the front end app. The origins can be adjusted once you know what domain you'll use for the front end app and are ready to deploy.

Version control and documentation

While this API needs a lot of work before it's done, it's a good idea to get in the habit of updating the documentation and keeping track of changes as we go.

You can start by creating a repository in GitHub or another repository hosting service that uses git. It should be fairly straightforward:

Create GitHub Repository for Freelance API App

Before adding the files to the repo, it's a good idea to start on some of the basic files you may not feel like working on as the project wraps up: the README, LICENSE, and CONTRIBUTING files.

Your README should already exist, but go ahead and modify it to make sense with what you have so far. For example, right now mine looks like:

# Freelance API

Make your freelancing more efficient by managing leads, proposals, project documents, clients and more.

*This is a work in progress.*

## Getting Started

### Prerequisites

#### Ruby ~> 2.4

Download and manage via [rbenv]( or [RVM](

#### Rails ~> 5.1

    gem install rails -v '~> 5.1'

#### PostgreSQL ~> 9.6

Follow the [instructions for downloading PostgreSQL]( based on your operating system, and be sure to [create a database user with privileges](

### Installing

Clone the repository:

    git clone
    cd ./freelance-api

Install the gems:

    bundle install

And set up the database:

    rails db:create
    rails db:migrate

Start the development server:

    rails s

You can test this by making a GET request to `localhost:3000` using Postman or an alternative.

## Tests

### End to End Tests


### Coding Style Tests


## Deployment


## Built With

* [Rails]( - Web Framework
* [rbenv]( - Environment Managemet
* [Bundler]( - Dependency Management
* [Heroku]( - Deployment Platform
* [Travis CI]( - Continuous Integration

## Contributing

Please read []( for details on the code of conduct, and the process for submitting pull requests.

## Versioning


## Authors

* **Chazona Baum** - Initial work

## License

This project is licensed under the MIT License - see the []( file for more details.

## Acknowledgements

There's still a long way to go, but already a surprising amount can be included!

Go ahead and create a file and a file in your project root. My CONTRIBUTING file just lists TBA, and I am using the MIT license for my project.

Now that these documents are set up, the files can all be added to the repository you created.

git add .
git commit -m "initial commit"
git remote add origin<YOUR GITHUB USERNAME>/freelance-api.git
git push -u origin master

Wrapping up

You're almost done with the basic setup! To create and update the database, go ahead and run:

rails db:create
rails db:migrate

It seems like we've done a lot without much to show for it, but we've set up the environment we'll need to start giving the API functionality.

At this point, you can test the API out by opening Postman and starting your Rails server in the terminal:

rails s

Once the terminal indicates the server is running, in the Postman request bar, send a GET request to localhost:3000. You should see the following:

Postman Screenshot Ruby on Rails Welcome

Look deeper into the HTML you received, and you'll see it's Rails' Yay, you're on Rails! success page.

With that accomplished, the next step is to actually plan out what the API should do in a little more detail and actually start creating the data models.

Freelance Web App with Rails API and React Frontend: Why?

Published 4 months ago


Freelancer Looking at Laptop with Coffee

In my rush to try to earn something from my code learning so far, I've had to shelve some of my plans to dive deeper into Ruby on Rails and to learn front end frameworks like Angular and React. When marketing freelance work to non-coders, the most common request seems to be to make something fast, pretty and cheap, which means focusing on static or WordPress sites.

But I'm finding that trying to reach out to potential clients the traditional way is extremely inefficient, especially when conversion rates as a newbie freelancer are basically nonexistant. And solutions for non-technical folks to manage their clients and improve their sales are expensive when it might take several months to actually earn anything.

So it seems to make sense to go ahead and put together an app that will allow me to keep track of and reach out to leads, as well as managing proposals and project documents, and provide clients with access to materials relevant to them. Once the basics are there, I'll look at integrating an invoicing API like FreshBooks to get more out of the app.

And since it's been a while since I've blogged about what I'm learning, this seemed like a great opportunity.

Over the next few weeks I'll be building a freelance dashboard app, using Rails 5.1 for the API backend, and React.js on the front end.

To follow along, it's a good idea to be comfortable working with your terminal and console, have a basic understanding of how a simple Rails app works, and to have a working knowledge of JavaScript. But I'll try to keep things simple just in case.

You can either wait for the next post to start building, or feel free to dig a bit deeper into why I went with this stack below:

Why Rails?

I'm setting aside for a moment the fact that I love working with Ruby, since it's not always going to be the best tool for the job.

For one, Rails is pretty fast and easy to set up compared to other options. Given that I intend to use this toward trying to make some income soon, being able to get something up quickly and iterate improvements is a huge advantage.

If I wanted to build the back end and front end in the same application, Rails makes that easy, too. Starting with 5.1, Rails includes Webpack and makes it easy to create apps that use front end frameworks and libraries like Angular, React, Vue, or Ember rather than jQuery. I've played around with that a bit, but I think I'd still rather separate out these two key parts into an API and a front end app.

Rails is also well-known for being a great framework for building RESTful APIs. Rails 5 even provides an API mode that makes getting a JSON API up and running even smoother.

And I have some basic experience building applications with Rails. While I want to learn new things, having some familiarity with the back end will help get this built quicker, especially since I'm picking a front end framework I have no experience with.

If I didn't go with Rails, I would have considered:

  • Phoenix - Phoenix is built on Elixir, and the framework was recently brought to my attention as a more performant alternative to Rails. I definitely want to play around with the pair some, but possibly on a different project. Plus, the performance issues with Rails are generally more of a problem when it's a lot bigger than I expect this to get.
  • Node.js - When working with JSON and a JavaScript front end framework, a JavaScript back end would seem like a convenient option. I've only played around with Node in small pieces, like building Twitter bots. I want to explore Node more in the future, but Rails' benefits edge out for this project.
  • Sinatra - Sinatra is another Ruby-based option, one that's supposed to be great for tinier applications where Rails might just get in the way. I'm expecting this app to be a little larger than one I might use Sinatra for, though I'm eager to try it out on a project one of these days.

Why React?

React has gotten a lot of attention lately between concerns about licensing issues (which it seems were ultimately much ado about nothing) and its parent company Facebook constantly ending up in the headlines.

It seems most companies that have gone with JavaScript front end frameworks have landed with either Angular or React. From a pragmatic perspective, there are more jobs out there for either one than for, say Vue.

React is also a more mature framework than Vue, while having fewer breaking changes than Angular.

And React also has the benefit of React Native. If I wanted to implement a native mobile app for this web application, which I eventually do, React Native makes it much easier.

If I didn't go with React, I would have considered:

  • Vue.js - Vue, like Ruby, is a joy to use. I've tinkered with it before to build a simple Pokémon-based monster battle game. If I wasn't going with React, I would have definitely gone with Vue to have the most flexibility with my front end.
  • Angular - The other pragmatic approach, Angular is used by a lot of companies I know. It's also frequently paired with Rails.

Other Considerations

I considered breaking this project up into microservices to make individual features easier to develop and maintain, and initially started it that way. However, it's been brought to my attention that microservices should be left to situations where teams of people will be working on different services, so this project will take a monolithic approach.

And since I'll be attending RubyConf this week, posts about this project may be interrupted by posts about the conference.

This should be a fun project to work on, and I look forward to showing you along!

Roughing It Dev Style: Coding Without a Computer

Published 11 months ago


Phone Nestled in Leaves

A terrible, horrible, no good, very bad thing happened to me this month: the Surface Pro that was my exclusive personal and work computer died. Even though I found an inexpensive replacement to order, I couldn't imagine not coding for about a week. I was totally freaking out.

After a few unsatisfying days of merely reading about web development topics, I set to work on figuring out how I could get some real work done, armed only with my iPhone.

Trial and Error

Not wanting to hunt down a new solution if it was unnecessary, I first turned to tools I've used before:


Codepen wasn't terrible in a pinch. However, the layout and on-screen keyboard really wasn't optimized for coding on a phone. Making minor changes took a lot of time, and it was easy to end up with really buggy code.

Cloud9 IDE

Cloud9 had the same problems but with an already more cluttered interface. It explicitly doesn't support mobile browsers and it has been made clear multiple times that making Cloud9 mobile-friendly or developing a native mobile app for it is not anywhere on the roadmap.


When exploring the Cloud9 issue, I saw mention of an alternative cross-platform cloud IDE called CodeAnywhere. However, the iOS app appeared to have not been updated since 2014 and after four unsuccessful attempts to so much as create an account and login, I figured there had to be something better.

What Finally Worked

After some frustrating experiences, I came across tools and techniques that worked beyond my expectations, allowing me to code productively with just a phone and that can allow you to do it, too.

Editor: Buffer Editor

Buffer Editor was a hidden gem in the App Store. It didn't have a presence from advertising or word of mouth or even enough reviews to warrant a rating. It would be easy to underestimate Buffer.

When actually downloaded, though, it's clear that Buffer Editor is a real, powerful editor truly optimized for a mobile experience. Features that won me over included:

  • An extended keyboard that makes typing quick (for one-handed) and intentional.
  • A well-designed built in terminal.
  • Full-screen editing, a necessity on such a small screen.
  • Syntax highlighting and autocomplete for 40+ languages and technologies.
  • The ability to connect via SSH, FTP, SFTP, GitHub, Dropbox and iCloud.
  • Sending files by email.

Buffer Editor Extended Keyboard

It also included useful features that I didn't utilize such as Vim support and support for bluetooth keyboards.

While it isn't free, the 4.99 USD price I got it for was well worth it, especially compared to the popular Coda at almost 25 USD.

Server: Digital Ocean

Being confined to a phone gave me the push I needed to start building more websites and applications directly in a VPS solution like Digital Ocean rather than starting out solely on a local machine. Using a Virtual Private Server (Digital Ocean calls them droplets) allows setting up a development environment and managing files/servers without needing a local environment to work with, since it's on another computer in the cloud. Another benefit of VPS is that from the start, a project isn't tied down to one local machine, even if it hasn't been checked in to version control yet.

Digital Ocean has proven to be easy to use (and inexpensive), and there is a wealth of documentation and guides for folks new to running servers.

Accessing the droplet remotely was easy in Buffer Editor, simply involving adding a new SSH connection and filling out the relevant settings with information from the droplet.

Buffer Editor New Connection Form

Browser Access: Local Server Binding

The wonderful and problematic thing about web development is, of course, the primary thing you need is a browser. Using a VPS to develop, you have access to a terminal console, but not a Graphical User Interface or a traditional web browser.

When developing a web app, you often need to be able to start a local server and access localhost in the web browser, since that's where the development server displays the app. Unfortunately localhost means this computer, and so it's inaccessible outside of the VPS hosting the app files.

The workaround here involved learning more about servers and requests:

When starting a server, it sends what is called a bind request to indicate that it is ready to receive requests associated with an IP address. Local servers typically bind to because that IP address is used to loop back to the requesting computer; each computer can only request from itself, which is usually convenient for developing.

That's clearly not an option. You need to have the server bind request indicate its publicly accessible IP address instead so that it's accessible from a browser outside of that computer. This IP address is easily obtained from Digital Ocean, and the workaround involved adding a --binding flag like this, for starting a Rails server:

Now, instead of typing localhost:3000 into the browser's address bar to view the app, you would type the publicly accessible IP address, like XX.XX.XX.XX:3000. As long as the local server is running with the binding flag, the app will be accessible remotely from the server's IP address.

Buffer Editor is especially convenient by keeping the server running after you back out of the terminal (so you can open it again and continue to develop). This can be confusing at first, but to stop the server, lock and unlock your phone.

Get Back to Coding Productivity

From here, you can utilize git like usual, get to work and debug your code wherever you are and regardless of WiFi/Ethernet availability. In fact, the day before my new computer arrived, I was able to make 6 commits and push them to GitHub, all from my iPhone.

While my day to day coding will be on a traditional desktop or laptop when it's available (since two hands are faster than one), I continue to utilize these tools to work on my projects when I can't bring my laptop somewhere or when mobile internet is all I'll have access to, such as riding in a car.

I'm actually thankful for the experience of losing access to the computer, because it forced me to find a solution that now allows me to code virtually anywhere.

Getting Started with Jekyll: Meeting Jekyll's Demands

Published about 1 year ago


Jekyll Ruby Code

When this left off in Part 1, you had a basic Nginx server running and set up with remote access and a firewall.

So now that you have this awesome server, you should put some stuff on it.

Precious Rubies

First you’ll need to make sure you have the Ruby programming language installed both on your server and on your local computer. While you can have multiple versions of Ruby installed, you need both server and local to be using the same version. This will take some time to correct later since you’ll have to reinstall almost everything, so it’s important to pay attention now.

To install Ruby, you’re going to use the Ruby Version Manager (RVM) which also makes it easy to install additional tools and make updates. To install both RVM and Ruby, follow the instruction on the RVM website which will look something like the following but will change over time. You’ll want to make sure --ruby is added like this:

$ gpg --keyserver hkp:// --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
$ \curl -sSl | bash -s stable --ruby

Do the same for both your server and local computer. Before moving on, check which version of Ruby you are running by entering the following command for each system:

$ ruby -v

You should have the exact same version listed for both. If you have multiple Rubies installed, say on your local computer, you can specify which version to use with the following, replacing the numbers with the actual version number you want to use:

$ rvm use 2.3.3

Once you have the same versions being used for both, you can start working on dependencies.

Crucial Pieces

From here, you’re going to be installing and configuring packages called gems.

In your terminal for your local computer, enter the following:

$ gem install jekyll capistrano bundler

Those are set to install the Jekyll site generator, the Capistrano deployment tool, and the Bundler gem manager. You may have received an error message stating you were missing some needed gem. As many times as you get this type of error, just go back into your terminal and install the gem it tells you, then re-attempt installing our three like so:

$ gem install gem_name
$ gem install jekyll capistrano bundler

Now that you have those set up locally, it’s time to see what you’re working with in Jekyll. Go ahead and enter the following:

$ jekyll new blog
$ cd blog
$ jekyll serve

This will generate and serve a basic Jekyll blog locally. Check it out! Go into your browser to localhost:4000, and you should see something like the following:

Jekyll Blog Demo Site

When you’re done, you’re going to see that when you enter our server’s address. To do that, you’re going to need to configure a few things.



In your terminal, log back into your server’s non-root user account. You’re going to need a directory for our site to go in, so go ahead and make one:

$ mkdir www
$ cd www

You can title it whatever you like. In that directory, you’re going to add a couple of additional ones that will be needed for your site:

$ mkdir shared
$ mkdir shared/log

Next, you’ll configure Nginx to know where to look for your site. Open the Nginx configuration file:

$ sudo nano /etc/nginx/nginx.conf

And look for a section that says:

Make sure the next line reads as follows, uncommented and replacing with the domain your site will use:

Save the file, and you’ll move on. Now, you need to go into the folders Nginx will look for our site configuration information:

$ cd /etc/nginx/sites-available

There is already a file for the server demo page, but you’re going to use that to create one for our Jekyll site:

$ mv ./default ./
$ sudo nano

Once in the file, make it look something like the following, replacing user_name with your non-root user’s name and with your server’s IP address or hostname if you’ve already configured it. Uncomment the lines listen 443 ssl; and listen [::]:80; if you have set up SSL certificates for your domain:

I’ve left a lot in here that is not absolutely necessary but is helpful to learn from. Once the file is configured, save it, and you’ll need to use a symlink in your sites-enabled directory so Nginx can find it:

$ sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled/

Using a symlink (symbolic link) basically places a file that references back to another file, so the same information can be used in two places (sites-available and sites-enabled) but only needs to be updated in one (sites-available). It’s a great way to save time and reduce errors.

Now you need to make sure your Nginx server can access and the files it needs to run, as well as all parent folders involved. To do this, you’re going to make the Nginx user the owner of the directory you’re going to deploy to, and then give it read and write access to all the directories it will need:

$ sudo chown -R -www-data:www-data /home/user_name/www/current
$ sudo chmod 755 -R /home

Finally go ahead and check to make sure your setup of Nginx doesn’t create any errors, and then restart the Nginx worker:

$ sudo nginx -t
$ sudo kill -HUP `cat /var/run/`

Now that your server is configured properly, you can move on to setting up your deployment tool, Capistrano.


Back on your local machine, in the directory your blog is going in (say, /user_name/blog), go ahead and edit what’s called a Gemfile, which is basically just a file that lists what and what versions of Ruby and gems you’ll need:

$ nano Gemfile

Make it look something like this, keeping any versions, plugins or themes already listed in the file:

source ""
ruby "2.3.3"

# Hello! This is where you manage which Jekyll version is used to run.
# When you want to use a different version, change it below, save the
# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
#   bundle exec jekyll serve
# This will help ensure the proper Jekyll version is running.
# Happy Jekylling!
gem "jekyll", "3.3.1"
gem "capistrano"
gem "capistrano-rvm"
gem "capistrano-bundler"
gem "rvm1-capistrano3", require: false

# This is the default theme for new Jekyll sites. You may change this to anything you like.
gem "minima", "~> 2.0"

# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
# uncomment the line below. To upgrade, run `bundle update github-pages`.
# gem "github-pages", group: :jekyll_plugins

# If you have any plugins, put them here!
group :jekyll_plugins do
  gem "jekyll-feed", "~> 0.6"

Once that’s in place, in your terminal, run the following to create some files Capistrano will need to deploy the site:

$ cap install

Here, you’ll have a bit more editing to do. In your terminal, type:

$ nano Capfile

Like the Gemfile, the Capfile will need to list some pieces required for Capistrano to work. Make it look kind of like this:

Making these changes will tell Capistrano that you’re using RVM to manage ruby versions and bundler to manage gems, as well as which version of Capistrano to expect.

To make sure all the necessary gems are properly set up for use, in your terminal type:

$ bundle update

Then the next file to edit:

$ nano config/deploy/production.rb

Edit it so it looks like this, replacing with your server’s address and user_name with your non-root user:

set :stage, :production

# Extended Server Syntax
# ======================
# This can be used to drop a more detailed server definition into the
# server list. The second argument is a, or duck-types, Hash and is
# used to set extended properties on the server.

server "", user: "user_name", port: 22, roles: %w{web app}

set :bundle_binstubs, nil

set :bundle_flags, "--deployment --quiet"
set :rvm_type, :user

SSHKit.config.command_map[:rake] = "bundle exec rake"
SSHKit.config.command_map[:rails] = "bundle exec rails"

namespace :deploy do

  desc "Restart application"
  task :restart do
    on roles(:app), in: :sequence, wait: 5 do
      # execute :touch, release_path.join("tmp/restart.txt")

  after :finishing, "deploy:cleanup"

# server-based syntax
# ======================
# Defines a single server with a list of roles and multiple properties.
# You can define all roles on a single server, or split them:

# server "", user: "deploy", roles: %w{app db web}, my_property: :my_value
# server "", user: "deploy", roles: %w{app web}, other_property: :other_value
# server "", user: "deploy", roles: %w{db}

# role-based syntax
# ==================

# Defines a role with one or multiple servers. The primary server in each
# group is considered to be the first unless any hosts have the primary
# property set. Specify the username and a domain or IP for the server.
# Don't use `:all`, it's a meta role.

# role :app, %w{[email protected]}, my_property: :my_value
# role :web, %w{[email protected] [email protected]}, other_property: :other_value
# role :db,  %w{[email protected]}

# Configuration
# =============
# You can set any configuration variable like in config/deploy.rb
# These variables are then only loaded and set in this stage.
# For available Capistrano configuration variables see the documentation page.
# Feel free to add new variables to customise your setup.

# Custom SSH Options
# ==================
# You may pass any option but keep in mind that net/ssh understands a
# limited set of options, consult the Net::SSH documentation.
# Global options
# --------------
#  set :ssh_options, {
#    keys: %w(/home/rlisowski/.ssh/id_rsa),
#    forward_agent: false,
#    auth_methods: %w(password)
#  }
# The server-based syntax can be used to override options:
# ------------------------------------
# server "",
#   user: "user_name",
#   roles: %w{web app},
#   ssh_options: {
#     user: "user_name", # overrides user setting above
#     keys: %w(/home/user_name/.ssh/id_rsa),
#     forward_agent: false,
#     auth_methods: %w(publickey password)
#     # password: "please use keys"
#   }

And last but not least, you’ll edit:

$ nano config/deploy.rb

Make sure it looks like the following. You’re going to replace user_name with your local username, ruby-2.3.3 with whichever version you are using, the application name of "blog" with your choice if you want to change it, and the address listed next to repo_url to the address of your own repository if you use git (otherwise leave those quotes empty):

# config valid only for current version of Capistrano
lock "3.7.1"

set :rvm1_ruby_version, "ruby-2.3.3"

set :application, "blog"
set :repo_url, ""

# Default branch is :master
# ask :branch, `git rev-parse --abbrev-ref HEAD`.chomp

# Default deploy_to directory is /var/www/my_app_name
set :deploy_to, "/home/user_name/www"

# Default value for :format is :airbrussh.
# set :format, :airbrussh

# You can configure the Airbrussh format using :format_options.
# These are the defaults.
# set :format_options, command_output: true, log_file: "log/capistrano.log", color: :auto, truncate: :auto

# Default value for :pty is false
# set :pty, true

# Default value for :linked_files is []
# append :linked_files, "config/database.yml", "config/secrets.yml"

# Default value for linked_dirs is []
# append :linked_dirs, "log", "tmp/pids", "tmp/cache", "tmp/sockets", "public/system"

# Default value for default_env is {}
# set :default_env, { path: "/opt/ruby/bin:$PATH" }

# Set stages
set :stages, ["staging", "production"]
set :default_stage, "production"

# Default value for :log_level is :debug
set :log_level, :debug

# Default value for keep_releases is 5
set :keep_releases, 5

namespace :deploy do

  desc "Restart application"
  task :restart do
    on roles(:app), in: :sequence, wait: 5 do
      # Your restart mechanism here, for example:
      # execute :touch, release_path.join("tmp/restart.txt")

  before :restart, :build_public do
    on roles(:app) do
      within release_path do
        execute "/home/user_name/.rvm/gems/ruby-2.3.3/wrappers/jekyll", "build --destination public"

  after :publishing, :restart


Finally, go ahead and tell Capistrano to deploy your current site by typing:

$ cap production deploy

Open your browser window and type your server’s address. You should see this:

Jekyll Blog Demo Site

If you did, great! You set up your Jekyll site to push your local content to your server!

You’re finished for today. Want something to do in the meantime? If you set up your domain name last time, here’s a useful guide by Mitchell Anicas on securing your server with a free Lets Encypt SSL certificate.

Questions, comments or concerns? Continue the conversation in the comments!

Getting Started with Jekyll: Servers and SSH

Published about 1 year ago


Jekyll Ruby Code

If you’re a developer, there’s a good chance you may have heard of static site generators like Jekyll or Ghost. They claim to cut down on a lot of the bloat you find in behemoths like WordPress and simultaneously give you greater control over your site’s structure and design.

For those very reasons, I have recently migrated my existing WordPress blog over to Jekyll. While WordPress is a massively useful tool for sites that require a lot of features, it’s simply unnecessary for a simple blog.

For those who have never managed their blog in this way, though, it can be pretty intimidating. Thankfully, there are a couple of ways to go about installing Jekyll, and both are manageable.

The easiest way to install Jekyll is to use GitHub Pages. I won’t go over that method here; instead, to have more control over the installation and site itself, we’re going to walk through hosting Jekyll on your own server, an always-connected computer for serving content, or Virtual Private Server/VPS, a piece of a server blocked off from the rest that acts like its own server. If you have never managed your own server before, this is a great project to learn from!

By the end of Part 1, you’re going to have a functioning server you can add a domain name to. In Part 2, we’ll get to the dependencies needed to make Jekyll and our deployments work. Ready for some fun?


To follow along with this tutorial, you will need a server or VPS with root access. Basically this means you need administrator access to view and change things like system files on your server. Not sure who to use? My recommendation is Digital Ocean; for $5 a month, you will have more server than you need, full root access, as well as great documentation and support. This tutorial assumes you are able to use a command-line terminal, text editor like Sublime Text or Atom, and a web browser. It also assumes Linux, though folks using other systems are welcome to go through and let me know where you get stuck so we can work through it. You do not need to already know any particular language (though comfort with Ruby and Bash help), so if anything doesn’t make sense, please bring it to my attention.

Set Up Your VPS

To start with, you’re going to need to do some basic setup of your server. In this tutorial, we’re using Ubuntu 16.04, which Digital Ocean and others VPS providers make easy to install while creating your server. Once you receive your root login information (likely by email), log into your VPS using SSH on your console. Grab your server’s IP address, a series of four or six numbers separated by periods that tells your browser where to find your server. For Digital Ocean, this can be found on the Droplets page like this:

Droplets: Name, IP Address, Created, Tags

You should type something like the following, filling in your server’s IP address in place of the zeros:

You’ll likely see something like the following:

Type yes and enter your root password:

$ root_password

Your terminal should require you to immediately change your password. Enter your original password and then the new one twice. The prompt should then change to reflect your using the droplet like so: [email protected] ~$.

Now, this root user can easily get you in a lot of trouble because it has access to everything on your server and can do anything to it. You don’t want to be the person who accidentally deletes everything on your server by hitting just a few keystrokes.

So what we’re going to do instead is create a new user that can access administrator privileges, but only deliberately so accidents are less likely to be catastrophic. Choose a username, and in your terminal, type:

$ adduser user_name

You will be prompted for a password, and then you’ll see additional information requested:

Enter what you like; it’s okay to leave them blank if you prefer. Then we can get to adding privileges. In your terminal, type:

$ usermod -aG sudo user_name

This will add user_name to the user group sudo which by default has superuser or administrator privileges. To access those privileges, when you’re issuing a command you’ll type sudo in front of it, like this:

$ sudo command

The first time you use this in each session, you will have to enter your user’s account password. The prompt will look like:

Before we log out of the root user and into the one you’ve created, it’s a good idea to connect an SSH key pair to the server. These are a set of codes in which one is stored locally (the private key) and one is stored on the server (the public key). In order to log in with them, the user must have the right private key that matches up with the server’s public key. These codes are much harder to crack than passwords, so they make your server more secure against brute-force attacks.

If you don’t already have a key pair, you’ll need to go ahead and create one. In a separate local terminal window (not connected to your server), type the following:

$ ssh-keygen -t rsa

You will see a couple of prompts:

For the first prompt, just hit enter. The second is largely up to you. A passphrase could potentially provide more security, say if your local computer was hacked or stolen, but you would need to enter it every time you use the key pair.

When the keys have been created, the public key will be stored at /home/user_name/.ssh/ and the private key will be at /home/user_name/.ssh/id_rsa. These can be stored in a password manager vault as a backup. Now that you have them, you’ll need to copy the public key to your server under each of your accounts. While still in your local terminal window, type the following, replacing with your server’s IP address:

$ ssh-copy-id [email protected]

You should see something like this:

Type yes. Then you’ll see:

Enter the password for user_name. You’ll see:

At this point, in your server terminal window, you can go ahead and log out of the root account and try to log back in:

$ exit
$ ssh [email protected]

You should not be prompted for a password, though you will for a passphrase if you created one. Go ahead and do these same steps again starting with copying the public key to your non-root user, so that both accounts can be accessed without a password.

Important: Only complete this next step if you were **successfully* able to log in without the password on your accounts. Otherwise you can lock yourself out of your own server.*

The next thing you can do, which is optional but generally a good idea, is to disable password-logins for your root account. This ensures that someone won’t be able to gain administrator access to your server just because they cracked your password. If you do this step, using your server terminal window, open the config file for SSH:

$ sudo nano /etc/ssh/sshd_config

Look for PermitRootLogin and modify it so it says:

Then to make the changes effective, type this into your terminal to reload SSH:

$ sudo service ssh reload

Now that we have this out of the way, there isn’t much need for you to log in to the root account, so get out of there and log into your non-root account.

Configure Your Server with Nginx

At this point, you should be logged into your server as your non-root user. Now, we’re going to install the Nginx web server, which will be pretty easy. In your terminal, type:

$ sudo apt-get update
$ sudo apt-get install nginx

apt-get is a package manager that will help us install things; as long as the name of the program we need is in its listings, it should be able to install it for us. By updating it first, we’re making sure we have the most up-to-date listings to pull from. The second command handles the actual installation, including any needed dependencies. Note: If you get a dependency error installing anything in this tutorial, you may need to look at the error and install the dependency prior to installing the program you want. Just be prepared.

Now’s a pretty good time to make sure we have a firewall set up, since we’ll need to make sure Nginx can get through it. A firewall keeps track of traffic in and out of your server and makes sure that only traffic that meets certain rules can get through. The tool we’re going to use to manage our firewall is ufw, which comes built-in.

First, go ahead and check the status of your firewall by typing:

$ sudo ufw status verbose

You should get a message stating it is inactive. We’re going to deliberately enable it. First, we need to make sure that traffic can get in from the ports we need. Ports are specific endpoints for traffic in and out of the server; for example, emails are generally handled from a different port than your published content will be.

First, since we are accessing our server remotely through SSH, a secure shell within our terminal, we need to make sure we can keep accessing that way:

$ sudo ufw allow ssh

Since SSH requires port 22, that command will allow connections from that port. We’ll also make sure that http connections (the kind you usually make in your browser) are allowed. Like with SSH, ufw knows what port to listen to for http connections (80), so you can type:

$ sudo ufw allow 'Nginx HTTP'

If you have or get a SSL security certificate for your site, which will connect users by https instead and is generally a best practice these days, you will also need to keep its port open:

$ sudo ufw allow 'Nginx HTTPS'

We’re not going to worry about File Tranfer Protocol/FTP connections, used for transferring files back and forth with your server with no encryption (not a great idea anyway), or other ports because we’re going to deploy our site’s files right from SSH.

Now that we have our needed ports open, go ahead and enable the firewall:

$ sudo ufw enable

If you go back and check the firewall status again, you should get output like this:

Now we should be able to check with our system to see that Nginx is running. Type:

$ systemctl status nginx

You’ll get a detailed output, but the piece you want to look for is Active: active (running) since. Just to be sure, go ahead and see if you get Nginx’s default landing page. In your browser window’s navigation bar, type your server’s IP address (should look like and hit enter. You should see something that looks like this:

Welcome to nginx!

If you did, great! Your server is working correctly.

We’re finished for today, in Part 2 we’ll get all the dependencies needed and install Jekyll, and Monday we’ll get the blog posts and changes deployed! Want something to do in the meantime? If you have Digital Ocean, here’s a useful guide by Etel Sverdlov on setting up your domain/hostname on your server.

Questions, comments or concerns? Continue the conversation in the comments!