How I published my site to the web from the command line

Who is this article for?

If you're a seasoned front end developer with lots of experience deploying websites, then you're probably not going to get much out of this post. If you're looking to launch your own site from a graphical user interface like Filezilla, this article is not going to help with that. I wrote this article as a reference for myself and also for any beginner out there who are interested in uploading their own site to a server from the command line. My goal is to make the daunting task of uploading a website (without relying on a graphical client) a bit more clear-cut.

Prerequisites

If you're following along, please note that I'll be working primarily out of the terminal. Some knowledge of the command line and git will make these next few steps easier to get through.

Goals

By the end of this post, we will be able to:

Connect a domain to a hosting platform.
Upload website files to the hosting platform using SSH & git.

Let's get started!

Connecting our domain to the hosting platform

The hosting platform we'll be connecting our Hover domain to is called NearlyFreeSpeech.net, but I'll refer to is simply as NSFN from now on.

We will first enable NFSN's optional DNS service for our domain ('demosite.com'). Log in to NSFN > Domains > Enable DNS.

This will make it so that we can register our site's hostname through NSFN (rather than through Hover.com), and lets us manage our DNS records directly in NSFN.

✧ tip
Managing the DNS records from my site host simplifies things for me, as I currently don't need to use Hover for anything else. YMMV.

Next we will go ahead and update our domain's nameserver fields so that they point to NSFN's nameservers. This is done in our domain registrar, Hover. All we do is copy the authoritative nameservers from our NSFN account and paste them into our domain's control panel. Log in to Hover.com > Control Panel > Nameservers.

This will make it so that the nameservers point to the appropriate DNS records (wherever they are managed).

✧ tip
NSFN offers a discount if we register our domain AND host our domain through NSFN.

At this point, we are switching gears. Let's fire up our terminal--we will be working from the command line.

Upload website files to the hosting platform using SSH & git

In order to add content to our site, we will first need an SSH key to establish an encrypted line of communication; to create that SSH key, we'll use the OpenSSH application.

OpenSSH & SSH keys

SSH is a communication protocol. SSH is complicated, but all we need to know right now is that we can use SSH keys to allow secure connections between a client (our local machine) and a server (NFSN). Any data sent during this connection is able to be encrypted. An attacker cannot read the messages without either of our private keys. Super secure!

The OpenSSH application is a CLI tool for generating these SSH keys; it’s built into the Unix platform, so if your local machine is a Mac, it already has it. If you're using a non-Unix machine, you may need to install OpenSSH manually. Check to see if your machine has it by typing ssh -V in the terminal.

OpenSSH generates public & private keys (mathematically related; written in bits; also called ‘key-pairs’). We can also create a password, generate signatures, and leverage the many built-in commands to manage the encryption/decryption of our files.

Once we've established an SSH connection, we can start adding content to our site.

Creating an SSH key

To create a new SSH key, we will type this into our local terminal:

cli (local)

ssh-keygen

An automated response will display:

cli (local)

Enter a filename in which to save the key-pair:

Enter a filepath (something like: /Users/user/.ssh/id_nfsn). At this point, you will also be prompted to include an optional password for your SSH key. If everything is done properly, we should see a confirmation that our SSH Key created successfully and saved in our indicated local folder! Cool.

Screenshot of an ssh key created in a local terminal. The key fingerprint is a SHA256 and about 80 characters long. — This key fingerprint is a SHA256 and about 80 characters long. Since it was generated on a Mac, it ends in '-iMac.local'.

Add the SSH public key to our NSFN account:

Let's go ahead and add this key to NFSN. Copy and paste the full public SSH key we just created. Then, navigate to NSFN > Profile > Add SSH Key and save changes.

✧ tip
Be sure to paste the entire key, including ssh-rsa at the beginning and the .local at the end.

Connect to the NSFN server from your local terminal with SSH

It's time to open the line of communication with the NFSN server from our local machine. Logging in to the server from the command line generally looks something like user@host_ip_address. For our situation, it will end up looking like this:

cli (local)

ssh hipstina_demosite@ssh.phx.nearlyfreespeech.net

If everything was done correctly, we should have successfully connected to the server.

✧ tip
During the SSH connection, if we typed pwd into the terminal, we'd see that we're by default in the /home/public directory of the remote server.

Now that we have established a remote connection with the NSFN server and verified that our domain and website are live, we can start uploading stuff! We'll be using the command line to navigate the server, and git commands to upload our website files.

Push a git repository to the NSFN server

For our purposes, we need to publish our website content (which should be stored in a git repository) to the NFSN /home/public directory.

In our remote server, we will initialize a bare repo in the /home/protected directory. Everything git related that we don’t want public-facing will be stored here:

cli (remote)


            mkdir demosite.git

            cd demosite.git

            git init --bare

✧ tip
A bare clone does not create a working directory--we don't need it in the remote server--we simply need to store our latest website files.

Meanwhile, everything client-facing will be stored in /home/public. But we'll configure this later.

Back on our local machine, create a name for the remote repo web and define where it will live in the NSFN server using SSH:

cli (local)

git remote add web ssh://hipstina_demosite@ssh.phx.nearlyfreespeech.net/home/protected/demosite.git

Let's check our work: On our local machine, verify that web was added as a remote repo:

cli (local)

git remote -v

If it was successfully added, we should see a remote repo named web listed. So, the remote repo is referred to as web in our local machine, and on our remote server it is literally labeled demosite.git.

Now we get to implement something extremely clever¹. Back on our remote server, add the following commands:

cli (remote)

$ cat > hooks/post-receive

              #!/bin/sh

              GIT_WORK_TREE=/home/public git checkout -f

              $ chmod +x hooks/post-receive

✧ tip
#! is called a shebang, and tells the parent shell which interpreter should be used to execute the script. In this case, this script requires bash. Meanwhile, the interpreter actually reads this line as a comment!

What's happening here is that we are creating (and enabling it to automatically execute) a custom post-receive hook. The hook will update the root directory with the latest version of our site.

How exactly?

A post-receive hook is triggered every time git push takes place.
GIT_WORK_TREE sets the location of the root of our working directory to home/public, which is a different directory than our bare home/protected/demosite.git repo. (The working directory is wherever we have the checked out version of our repo.)
chmod +x provides permissions to execute this hook for all incoming pushes.

To summarize: every time we git push a new version of the website files to remote web, git will checkout the latest tree of our repo to /home/public while the git metadata files stay in /home/protected/demosite.git.

And now the time has finally come when we can finally push our website content to the web repo. In our local machine, type these commands:

cli (local)

git push web +master:refs/heads/master

✧ tip
To force a push to only one branch, we used a + in front of the refspec, and a : after the refspec, and the exact directory ref (refs/heads/master) which we wanted to publish to in the remote server.

If everything is done correctly, our site will deploy to the world wide web. Hooray!

We may need to update or add to the website later. To push the most up-to-date master branch to the remote NSFN server, navigate to the repository that the website live in on the local machine and type this into the command line:

cli (local)

git push web

✧ tip
Finished? We can type exit to end the SSH connection with our remote server.

That's it. Thanks for reading!

Sources ¹ Abhijit Menon-Sen developed this elegant process for managing a website with git.