Heroku and Wordpress

This is a bit off-topic for The Map Guy since it has nothing to do with maps, directly. But it's interesting and it's about the cloud, and about software deployment. It's about... Hosting a low-volume personal Wordpress website on Heroku for free.

Introduction

I have a couple of personal websites for hobbies. I'm almost ashamed to admit that I'm using Wordpress for them, being the hardcore, bad-ass hacker that I am... but in the evenings and with nothing at stake, the convenience of Wordpress works for me.

I had been hosting my site on a Raspberry Pi at home, but the reliability just wasn't there. The Pi would crash from time to time and require rebooting. After the second time it did this while I was away on a trip, I decided it was time for a change. Even better, this is an opportunity to say Hello To The Cloud with a real-world application with no stakes involved.

Enter Heroku, my hero.

Heroku is a service that spins up virtual machines (they call them "apps"), using as their filesystem your git repository. The basic idea is this:

• You have a git repository which contains your website: HTML, PHP, Python, Ruby, etc.
• You create an "app" via their dashboard, also called a "dyno", and it has an URL. You then attach "Add-Ons" such as a MySQL database, a PostgreSQL database, SMTP via SendGrid, and other such services that you'll need.
• Using Heroku's command-line "toolbelt" you add to your clone of the repository, the fact that this clone is "connected" to that app/VPS. So your clone has two masters: git push origin master for saving your code to version control as usual, and git push heroku master to deploy it to the site.
• When you push to heroku master, Heroku resets your VPS, loading up its filesystem from your repository content. Assuming that your code works, the site works too.
• No permanent storage ("ephemeral filesystem"). When the VPS is load-balanced to another system, or put to rest, or you push again, it's reset from your repo. This is very important if your web app will be making filesystem modifications such as accepting uploads. More on this later.

So the effect is a build-from-components server, enabling the specific services you need.

For small personal sites, free tiers for the dyno and for the add-on services may prove sufficient to host the Wordpress code and the database entirely for free. The limitations of this free tier, as relevant to my personal Wordpress site, are:

• The dyno (the VPS itself) will go to sleep if there's no activity, and the next incoming activity to wake it up does mean some delay. The dyno must be asleep at least 6 hours per day, so using Uptime Robot to keep it awake is a no-no. The next step up to get rid of the sleeping, is only $10 per month.
• The ClearDB MySQL database is free only to 5 MB. This may not be enough for a long-running daily blog, but for a few postings per month maybe it's just what you need. The next step up is only $10 per month for 1 GB.

Since Heroku does support PHP, and a mysqldump of my database is only 2 MB in size, this sounds right on target for a Heroku freebie.

Ephemeral Filesystem

Let me reiterate that "permanent storage" comment above. Your Heroku filesystem is a git repository. Your dyno does have the ability to write files on disk,  e.g. an uploads folder, e.g. the Media Library component of Wordpress. But you won't like it. When your dyno resets, the filesystem is reinitialized and your modifications would be lost.

By "reset" is meant a reboot, it being load-balanced onto a new server, it going to sleep and waking back up, your next git push, or using heroku config:set to change environment variables. Bye bye, uploaded files.

The up side of this is that a hack of your website, assuming it didn't damage the database, can be solved by rebooting. The down side is that you need to find someplace else for long-term storage of any web-supplied files not in your repository (or else make a practice of manually downloading the files and adding to the repo? sounds awful)

In the case of Wordpress the easiest solution I found is the WP Offload S3 Lite plugin. When you upload to the Media Library, it goes to Amazon S3 instead, and media URLs are rewritten to point to their S3 version. Between Amazon's generous 5 GB free tier for a year and the real price being a paltry 3 pence per gigabyte per month, even an image-heavy website can get by on pocket change per month.

If you are writing your own ware, you'd want to code for your cloud storage of choice such as Amazon S3, Google Drive API, Dropbox API, etc. where you supply a file and get back a URL. I imagine you'd need to generate API keys, program the OAuth-style exchange of them, handle errors etc. and that sounds awful. For my own case here, though, the folks at Delicious Brains had generously done that heavy lifting for me.

Happy Ending

Spoiler time: My applications are all running on Heroku and the performance is quite acceptable.  And I learned a lot in the process. The rest of this story is how I got to this happy place.

So, now that I've covered the basics, tomorrow's story will be about the migration process!