If you read my first blog post, you know how I ended up with GRAV to build this website. As a next step, you might expect me to follow up with a blog post about the design and coding of this website. But, eager to disappoint, I will skip right over that. Not without a good reason, though. There are so many tutorials for HTML and CSS available online that I can’t add any value to what is already there.
Instead, I’m going to point you at this video (fast forward to the 12:25-minute mark). It was the starting point that led me to the software stack described on the about page. From there it is fairly easy to follow the GRAV documentation to set up a theme for a website.
If HTML and CSS are not your cup of tea, the developers of GRAV have a good set of skeletons or themes available. After installing any of those, all that is left to do is to fire up the text editor and write the content in Markdown.
With that out of the way, I want to talk about the path I took to get this site onto the Internet.
Do it Yourself or Hire a Team
There are lots of different types of web-hosts available, Wikipedia lists eleven. You can host your website in your basement on a raspberry pi for a total of a one time $30 investment, or, on the other side of the spectrum, you can “hire” a team of people who manage the server for you to the tune of hundreds of dollars each month. I knew I needed to be somewhere in the middle between those extremes, but where exactly?
To bring down the number of choices, let me mention a few constraints and wishlist items. First, GRAV requires PHP, a server-side scripting language. That ruled out a few web hosting services that host static websites for free. GitHub is one of the popular choices; I also tried out the Google Cloud Platform in the past.
Second, I had a specific development and deployment process in mind. I wanted to develop locally under version control (git) and automatize the deployment through pushing my changes to a remote depot on the web host. That eliminated some of the shared web-hosting options. Although, when you start with what appears to be an infinite supply, getting rid of some doesn’t bring down the number by much.
Third, costs are important. Running this site is a hobby activity that does not make any money. On the bright side, that also means no income is lost if the site goes down. So, reliability —and the extra costs associated with it—will not have to be a top priority when judging the alternatives.
Taking those three items into considerations, I was left with two types of hosting options that made sense to me; a shared web hosting service or a Virtual Private Server (VPS).
A Chunk of a Computer; One Way or Another
High quality shared hosting that can support my workflow was one option I considered. For the sake of the discussion, WebFaction is an example of such a service that was recommended to me. They offer fully managed servers —no worries about security patches or server monitoring— with plenty of resources regarding storage and bandwidth. A wide variety of web applications are available through their control panel; others can be installed with a little more effort. Overall, every item on my wish list can be found at WebFaction. As of this writing, their plans start at $10 per month.
A VPS is a chunk of a bigger computer, acting as a single computer. It is unmanaged; all the maintenance required to keep it running falls onto the owner. Among a host of other issues, having to deal with securing a computer against malicious attackers is the main reason why a VPS is a bad idea. It takes time and requires constant attention; a task best left to people that get paid for being on top of server security.
On the other hand, there are reasons in favor of a VPS. For one, managing the web-host yourself is fun (YMMW). Second, a VPS in a configuration I needed to host the site was cheap. GRAV will run on a 512MB, 1CPU configuration quickly and efficiently. Such a system can be had for $5 per month or less.
Other than having to deal with securing the machine, a VPS offered what I wanted.
ServerPilot to the Rescue
ServerPilot is a Control Panel for PHP and WordPress sites. It installs optimized server application stacks for best website performance, including modern technologies such as Nginx in front of Apache, and PHP-FPM. The key selling point to me —and I’m using that term loosely as ServerPilot is free of charge for my needs— is that it takes care of securing the server. Right away it installs an iptables firewall to lock down all ports of services that are not needed. From then on ServerPilot automatically installs security patches as they become available; not only for the operating system (Ubuntu) but for PHP as well. The software to manage all that is developed by people that have a strong security background.
With security covered, there are many other excellent features that ServerPilot offers. The management panel makes it easy to deploy web apps and create MySQL databases. The documentation is excellent. They even provide a tutorial for my preferred workflow; explaining in detail how to deploy a git repository into a web application managed by ServerPilot.
For a monthly fee, ServerPilot offers additional features. Most of them appear to be targeted at an audience with a business need that ServerPilot can address; separated from the free features by a nearly perfect dividing line.
To me, ServerPilot turns an unmanaged VPS into a managed system comparable to the service I would get from a shared web-hosting service. The critical part of securing a computer that is constantly connected to the Internet is handled by people who do that for a living, yet I retain the flexibility that comes from having root access to the machine.
At this point, I felt that I had boiled down the web hosting choices to something manageable. The software stack was all set, and a VPS was selected as the hosting platform. All that was left to do was to pick a specific VPS supplier and start hosting this site, so I thought. That turned out to be a bigger job than expected. The number of companies offering VPS plans is huge. Large enough to warrant another blog post to detail my decision process on how I eventually ended up with a VPS offering from RamNode.
- Cloud courtesy of and copyright Free Range Stock, freerangestock.com; photo by Jack Moreh
- Beach Hut courtesy of and copyright Free Range Stock, freerangestock.com; photo by Ian L.
- sun server provided under the Attribution-NonCommercial-NoDerivs 2.0 Generic (CC BY-NC-ND 2.0) license
There are other ways to keep the local and remote website in sync, but in my experience, nothing is as reliable and fast as git. ↩
The feature I wish was part of the free service is the handling of SSL certificates. There is a big push these days to encrypt everything on the web, and additional costs are another barrier that gets in the way to reach that goal. ↩