Get Your Website Up and Running on Ghost with Workarounds

“Hey, look what I made!” Addressing a friend, I triumphantly said, “It’s online. Just open the link!”. I was very proud of my work. After a few evenings of frantic work, I finally had my little project ready, and I was ready to show it to the world.

“But I don’t see anything!” My first user replied showing a hint of doubt. “Screen is blank.” I was amazed. I felt betrayed and vulnerable. My wonderful personal website was down after only a few hours, and I have no idea why. This was a situation I could not tolerate.

My personal blog Ghost, an open-source content-creation platform. I wanted to go for a self-hosted solution, so I instantiated a small EC2 instance with only 1GB of RAM (yes, it’s included in the AWS free tier, and yes, I’m a peon) and Set up my blog on it. I published a few posts, took a cool picture of myself under the Tour Eiffel, and set out to dominate the blogging scene. Little did I know that my small website would be shut down within a few hours.

In the heat of the moment, I restarted the EC2 instance, and in no time, I was able to show my website to my friends again. However, this issue proved particularly sticky: Like a mischievous marionette, something was going wrong in my (virtual) house and causing trouble every few hours. But who was the culprit? Of course, traffic spikes were out of consideration: nobody knew about this website, and the page hadn’t been indexed yet. According to the AWS console, CPU usage seemed pretty stable, and I also had a decent credit balance. The most reasonable conclusion at this point was that Ghost was running out of RAM for some reason.

After searching through several blog posts and user groups, I found something interesting. Some users have noticed that Ghost can run on 1 GB of RAM, but from time to time it kills itself to death. The reason for this is still not clear (someone blames Node.js memory leaks, I wonder picture). On my part, I had no intention of changing the instance type to buff its specs and was not particularly inclined to delve deeper into the issue.

Once an intuition came to my mind. I reached over to the EC2 console, and I confirmed my guess: I only had 1GB of memory, but I was sitting on an 8GB SSD. “Well,” I thought, “maybe the default change The division is too small. let’s watch.”

$ free -m
total    used    free 
Mem:             941    870     71

That’s right. Perhaps surprisingly to the tech-savvy reader, no swap partition was defined in the virtual machine. After gathering this information, the solution was at my fingertips.

First, I would create a swapfile with dd command (also referred to as friendly data destroyer,

sudo dd if=/dev/zero of=/swapfile bs=128M count=8

By choosing eight blocks of size 128MB each, I would have, at this point, 1GB of extra memory at my disposal. At this point, let’s give proper read and write permissions to the swapfile:

$ sudo chmod 600 /swapfile

It is also necessary to tell Linux to create a swap area:

$ sudo mkswap /swapfile

Finally, I can enable the swapfile:

$ sudo swapon /swapfile

After running these commands, I felt alive with plenty of memory in my VM:

$ free -m
total    used    free 
Mem:             941     411     530 
Swap:           1023     491     532

I wanted my instance to remember my decision to create and use a swap file on start-up. To instruct it to do so, it is necessary to add the following line to /etc/fstab file:

# /etc/fstab 
/swapfile swap swap defaults 0 0

One can say that relying on swap file is a cheap solution. To me, this is a real life cheat code.