WordPress is, by far, the most popular platform for websites. “30% of the web uses WordPress…”, claims wordpress.org. I’m not surprised. WordPress is easy to setup, easy to work with, highly cusomizable, and there are tons of resources, plugins and themes to fit almost any use case.

Jekyll is a blog-aware, static site generator. No database. You author your content in either html or markdown, then generate the static website.

I recently moved pdxcode.com from WordPress to Jekyll, and here’s why…

Cost

WordPress hosting cost

You could use some shitty hosting service like GoDaddy.com to host your WordPress site for as little as $2.99/mo. Not too bad. But the downsides are; 1) shitty performance, and 2) it’s difficult to manage free SSL certs using letsencrypt.org. So screw that!

So, let’s talk about AWS. There are a couple ways to host a WordPress site in AWS.

1. EC2 instance (t2.nano) with Apache + PHP and RDS instance (db.t2.micro) of MySQL, MariaDB, or Aurora

   • On-demand:

     $4.25/mo (EC2) + $13.03/mo (RDS) = $17.28/mo

   • Reserved 3yr contract, paid all upfront

     $1.46/mo (EC2) + $5.63/mo (RDS) = $7.09/mo

2. EC2 instance (t2.micro) with Apache + PHP + MySQL

   • On-demand:

     $8.50/mo

   • Reserved 3yr contract, paid all upfront

     $3.20/mo

If you run an RDS instance for the database, you can get away with running Apache + PHP on a t2.nano instance, but if you run the database on the EC2 intance without using RDS, you’ll need a t2.micro instance for everyting. So, best case scenario, with a 3yr contract paid all upfront, you’re at a cost of $3.20/mo. Not too bad. You can create an Auto Scaling Group with a min and max of 1 instance to have some fault tolerance at no additional cost (except for the tiny S3 storage cost of the AMI needed for the lanch configuration).

Jekyll hosting cost

The static files generated by Jekyll will be stored in an S3 bucket. I use CloudFront to serve the site via SSL using a free certificate from AWS Certificate Manager. I also use a simple Lambda to enable directory indexes, as described here.

• Transfer out 10T $0.08/m
• HTTP requests $0.0075/m
• S3 Standard $0.023/m
• Cloudfront $0.22/m
• Lambda Free
• ACM Cert Free

Total: $0.33/mo

Workflow

WordPress is easy to use. There’s a really nice admin interface where you can install plugins, manage widgets, add and edit content, etc. It’s simple enough that anyone can use it. Changes are often made to a production system, and are live immediately. It’s critical to take backups prior to big changes.

The Jekyll workflow is a little more down and dirty. I version the site in AWS CodeCommit. I use AWS CodeBuild to generate the static site and sync it to S3 buckets in 2 different regions for redundancy. I use AWS CodePipeline to trigger the build when a change occurs to the master branch. So, updates to this site get deployed automatically when the changes are commited to the git repo in CodeCommit. Changes are live once the cache expires in ClouFront (TODO: figure out how to trigger a cache invalidation when the build completes). Editing the site consists of editing HTML, CSS, and JavaScript. For strictly content editing, it’s just HTML or Markdown.

I have a strong DevOps and software development background, so I’m super comfortable with this workflow, and it was easy for me to get all the moving parts to work together.

Fault Tolerance

In order make the WordPress installation described above more fault tolerant, I’d need to create an Auto Scaling Group with at least 2 EC2 instances, and place an Elastic Load Balancer in front of them. And if using RDS, I might even want to make the database multi-AZ. These changes more than double the cost of the system.

Fault tolerance is handled by AWS for the Jekyll installation. For minimal cost, I could replicate the S3 bucket to another region and use Route53 and/or CloudFront to failover to the replicated S3 bucket in the case of a region failure. This would provide vastly more fault tolerance than a multi-AZ WordPress deployment at a fraction of the cost.

High availability

The WordPress installation is limited by the size of the EC2 instance and RDS instance serving the site. It’s pretty easy to tip over a site hosted on a t2.nano or t2.micro. It might not be an issue for a site that gets so little traffic as mine, but it’s a limitation worth noting.

The Jekyll site, hosted by CloudFront and backed by S3, can handle a virtually unlimited amount of traffic.

Serverless

The WordPress installation requires maintaining a server. You need to login to the server to configure the software, and run updates on the software and OS. When something goes bad, you need to look at the logs, etc.

The Jekyll installation is serverless! No instance to manage. No software to update. No OS to patch. No plugins to update. No admin interface for the Russians to hack. Ah… the bliss.

So why not?

Why would anyone not ditch WordPress for Jekyll like I did? I’m serverless! My workflow is dialed. I’m living the dream.

…well not so fast there Big Daddy. There are some good reasons to stick with WordPress. Here are a few:

1. You’ve got many different authors who are not into using developer tools like git.
2. You’ve use plugins like WooCommerce, or Paid Membership Pro
3. You’re using a shitty hosting provider like GoDaddy.com.
4. You just really love WordPress.