Amazon Lightsail Review

Amazon Lightsail by Amazon Web Services is targeted towards new webmasters, server admins, DIY enthusiasts among others. It provides much more predictable pricing than EC2 based servers where the pricing is calculated as a cumulative cost of individual components (server, disk, bandwidth, etc).

Predictive pricing?

Predictive pricing doesn’t mean fixed-price. Let’s get things straight. No VPS provider (that I know of) provides fixed-price. Not even Linode or DigitalOcean. There is always a condition attached to the pricing. Both DigitalOcean and Linode charge 2 cents per GB beyond the bandwidth provided in each of their packages. So, does Amazon Lightsail.

For a long time, Linode’s pricing page contained the following text…

No Calculator Required
CPU, transfer, storage, and RAM bundled into one simple price.

For DigitalOcean, it is…

Simple, transparent pricing
Always know what you’ll pay per month.

Now, the above statements are true for Amazon Lightsail services as well. No more jokes on going broke running websites on Amazon Web Services.


Security is always the primary concerns for most businesses of any size. Amazon Web Services and Amazon Lightsail have been keeping security as their primary concern on their own services and for anyone who uses their services. For example, Amazon Lightsail disables password based authentication, by default, and enables only SSH key based authentication. As mentioned earlier, the targeted users are mostly system admins and DIY enthusiasts. Most of them are either aware of how to use SSH key based authentication or they can acquire that knowledge in no time. Amazon Lightsail creates a default SSH key pair automatically, keeps the public key in (any) server that it creates, and only make the private key available for us to download. Of course, we can use our own keys too. Or we could create multiple keys attached to different servers.

The availability of Amazon Linux (AMI) is another tiny step towards having better security. Amazon Linux is available exclusively on Amazon servers (EC2 or Lightsail). It is based on CentOS and is tweaked to worked only with Amazon. The hackers usually target the largest user base (I am looking at you Ubuntu), rather than going for a small-set of users. Also, here’s what Amazon has to say about the security policy on their Amazon Linux AMI…

The configuration of the Amazon Linux AMI enhances security by focusing on two main security goals: limiting access and reducing software vulnerabilities. The Amazon Linux AMI limits remote access capabilities by using SSH key pairs and by disabling remote root login. Additionally, the Amazon Linux AMI reduces the number of non-critical packages which are installed on your instance, limiting your exposure to potential security vulnerabilities. Security updates rated “critical” or “important” are automatically applied on the initial boot of the AMI. Upon login, the Message of the Day (/etc/motd) indicates whether or not any additional updates are available.


  • Better integration with other Amazon services (I use S3 heavily)
  • Better security


Note: The following disadvantages or cons do not necessarily reflects the current situation. There were just true as of this writing.

  • No IPv6 (yet)
  • Available only in US East region (for now)
  • Bandwidth beyond threshold limit is too high for generic web masters (at 9 cents per GB)
  • Limited set of Operating Systems (only Amazon Linux and Ubuntu 16.04 are available as of this writing)
  • Limited CPU and memory compared to other traditional VPS providers

Final thoughts

I highly recommend Amazon Lightsail for US based small businesses. For everyone else, I recommend EC2 (within Amazon eco system). Of course, you may decide based on vetting the differences between Lightsail and EC2.

Here’s the slideshow from Amazon that explains a bit more than what I mentioned…

Note: The slide doesn’t work for now due to a bug from Slideshare’s own API! Click the link below to go through the slides directly from Slideshare!

Feel free to share your thoughts on Amazon Lightsail..

Introducing Preload Fullpage Cache

Situation #1

Right after creating my first WordPress plugin, Auto Maintenance Mode, I came across a situation on a high-traffic blog where the visitors just rush to the website immediately after a blog post is published and shared (automatically) via social media. It created chaos in the server and the initial visitors didn’t get the cached version of the blog post, because it wasn’t even ready.

Continue reading “Introducing Preload Fullpage Cache”

WordPress Plugins and Themes – Bad Business Practices

It isn’t uncommon to see freemium plugins in the official WordPress repo. The basic functionality of the plugin would be free. Some fancy features would come with a premium price. There is nothing wrong with such business model. What’s bad (business model) is switching the free features into paid features without notification. How does it feel if WordPress Foundation started charging a small fee to use the theme customizer?

What’s the (morally) right thing to do?

Let me provide real life examples.

  1. When Google removed the free version of its Google App (G Suite) in 2012, there was no impact for the existing customers including those using the free version. This domain ( was created in 2011 and am still enjoying the free version of Google App (for email).
  2. When DigitalOcean started charging for bandwidth in 2013, it grandfathered current accounts so that they would receive free bandwidth forever.

Both Google and DigitalOcean are big businesses. So, they can afford something free forever (albeit for a *small* percentage of their customer base considering their constant growth every year). If you are a small business, and are offering something for free for now, please state that clearly when you announce it. Let me provide you a recent example, announced a new datacenter for hosting services in Paris. Here’s what it said…

And if you’re still not convinced, we’re only charging Gandi server credits (or your prepaid account) for bandwidth consumed. The consumption rates for services created in “FR-SD3” will still be displayed on the website but nothing be deduced from your resources.

We’ll be running Alpha and later Beta tests at least until the end of February 2017. While we tentatively hope to go live with this new infrastructure by March 1, we will let you know 15 days in advance so that you can plan for the return to our normal hosting rates based on resources consumed.

Technically, you don’t break any TOS, SA, or any other rules. But, morally?

What’s Bad Business?

  • Switching the free features into paid features without notification
  • Moving the (free) plugin (or theme) off the repo.

A couple of weeks, a plugin (with over 1000+ active installs) has switched some of its free features into paid features after renaming the plugin too. Fortunately, they have provided a link (to their internal server resource containing a zip file) to download the plugin for future updates if anyone wants to continue using the free features. You might ask me what’s wrong with that. Let me explain.

Why do we trust WP (repo)?

I don’t like WordPress. I don’t like its every growing complexity. It is generally bloated after each release too. I still trust WordPress and continue to use it for a foreseeable future for the following reasons…

  • WordPress is monitored constantly by almost every researcher in the world, looking for any loopholes.
  • WordPress plugins (and themes) in the wporg repo are monitored regularly monitored as well. So, when a plugin is found to have a vulnerability, it is taken down from the repo immediately. Of course, when it is patched up, it is included back into repo.

When a plugin is hosted outside wporg repo, I don’t think there would be enough interest in keeping an eye on it. It is good for that plugin, though. 😉 But, as a generic WordPress user, it is not safe to download from such sources.

That’s the reason I wouldn’t recommend Github hosted plugins too. It doesn’t mean you shouldn’t use such plugins. In fact, go ahead and try them all. It is a great way to learn. There are some gems on Github too. Just be sure to trust the author, if you don’t understand the code. I wouldn’t trust a plugin that switches the free features into paid features without an explicit note during its announcement or without any notice at all.

Matt Mullenweg has a good summary of what happened when MovableType changed its subscription model.

I still believe in freedom 0.

Aptitude or apt-get?

It’s 2017. I started using linux in 1999. Yes, I am getting older and older. I have always used apt-get on Debian based servers or distributions. However, in recent times, I am getting more frustrated to use apt-get. To be precise, I may want to install a package. So, I start to type apt-get. Then I may be unsure, if the package by the exact name exists. So, I tend to search the package/s, instead of installing it. Now, I have to use apt-cache to search packages. Sigh!

Conflict resolution

Installing MariaDB by replacing the default MySQL in the older Ubuntu distributions (14.04 or 12.04) have always been a pain. I tend to miss something that resulted in package conflict. In these situations, apt-get would simply throw me an error something similar to, “Sorry, I can’t allow you to do that“. Then, I would be like “wtf, why don’t you provide me a clue on what’s going on“. Just had a similar situation where aptitude resolved the issue swiftly. A big thanks for aptitude.

But, why do articles often show apt-get commands?

There might be two reasons.

  • On each of those articles, it has to start with apt-get install aptitude
  • It is easier to show the commands than GUI offered by aptitude

Both reasons are irrelevant these days when most server admins work only on CLI. Probably, it is time to start promoting aptitude in articles.

Are there any other difference between aptitude and apt-get?

Of course. There are some minor differences.

  • apt-get autoremove is done automatically by aptitude (saves time!)
  • aptitude’s safe-upgrade and full-upgrade commands are more accurate than apt-get’s upgrade and dist-upgrade.
  • even though aptitude’s search is way too slow than its competitor’s, it has some advanced search patterns that can come in handy at times.
  • apt-get is always faster!
  • apt-get uses smaller footprint than the other!
  • aptitude has why and why not!
  • apt-get came first! (so no chicken-or-egg issue here). You’ll always find apt-get in every Debian based distro, even on a super bare-bone server. But, it may not be true for aptitude!


In the end, it’s just a personal preference, I guess. Time for me to rewrite my muscle memory to use aptitude instead of apt-get or apt-cache!

Crooky Cron

What Is Cron?

In simple terms, cron is a job scheduler in unix-like operating systems. It is also called as system cron or OS cron especially if the discussion is also about WP Cron. The job can be anything that needs to be done at a particular time. The job could be an one-time job (such as launching a rocket at a scheduled time) or repetitive (such as turning the lights on upon sunset and turning them off upon sunrise, every day!). Basically, the system cron is a program that runs all the time just to trigger a particular action at a particular time. You can throw hundreds of tasks on it to do at various intervals. System cron is like robot who is always available at your service!

What is WP Cron?

WP Cron helps to do the following tasks (among others) in WordPress core…

  • Publishing scheduled posts
  • Checking for updates to WordPress core, plugins and themes
  • Applying updates (depending on the configuration)

Plugins can also utilise WP Cron to do various tasks…

  • Pulling the latest social media tweets to display on the site
  • Sending small batches of newsletters if your site has thousands of subscribers
  • Updating inventory based on external resources

WP Cron is like an on-call assistant. It means it doesn’t run jobs all the time. It runs jobs only when someone visits your site!

WP Cron was introduced because of the limitations on the hosts (such as shared hosts) where hosts don’t allow access to the system cron. At the same time, it was never meant to replace the system cron that is more precise in executing the tasks on time. WP Cron is meant to make sure that the tasks are done irrespective of when they are done. That’s the basic difference between the system cron and WP Cron.

The other is… WP Cron can only run with a minimum frequency of 5 minutes. The (OS) cron can run at a frequency of 1 minute. Also, using a system cron can help us to run any script. WP Cron is less flexible in this regards.

What’s the problem with WP-cron?

The advent of full page caching engines, such as WP Super Cache, prevented visitors hitting the WordPress (to be precise the PHP). Full page caching engines generate HTML files that can be served directly, if exists. With the recent development on preloading full page cache, it becomes even easier to generate cached version of a blog post immediately after it is published.

This is actually good news for everyone. It saves the precise server resources for host. It saves a few bucks too. It makes delivering content much faster, without having to process PHP and MySQL. But… it isn’t good news for WP Cron. WP Cron runs only when a visitors hits uncached version of the site, thus triggering PHP, MySQL and WordPress in turn. The result is too many WP cron tasks accumulated over a period of days, weeks or months, depending on how fierce your full-page caching engine is. At times, you may see thousands of cron jobs that just fill the database, reducing the overall performance of the backend.

Most common problem with WP Cron is that scheduled posts are not published on time. Again, it is due to aggressive caching system or lack of any visitors to the site. If you run a multisite, the problems are even bigger.

What’s the solution?

Simple. Let system cron trigger WP-Cron!

If your host doesn’t support (system) cron or if you want more features than what’s offered by your webhost, then head over to, or any similar external cron service. They support per minute cron jobs, notifications upon failures, offer logging to name a few.

Most managed WordPress hosts have built-in cron system to trigger WP Cron regularly. cPanel supports cron too. Even some regular generic web hosts support OS cron.

If your host supports cron, do yourself a favour by hiring a developer to setup the cron for you!

Recommend Settings for Redis Object Cache Plugin

WordPress Object Cache system allows transients to be stored in object cache backend, such as APC, Memcached or Redis. Without an object cache, the transients are stored in the database itself. This is the default. You could verify this yourself by looking at the (wp_)options table in the database. Fortunately, we have options to store these transients in the memory using one of the backends mentioned above. Among these, Redis has become stable and is production-ready. There are two WP plugins available that use Redis as WP Object Cache. First one is Eric Mann’s plugin. The second plugin is by Till Krüss who forked the former and made it better.

Continue reading “Recommend Settings for Redis Object Cache Plugin”