We have become quite familiar with pagoda box in the last year. One of our very busy websites has been operating on Pagoda box for more than a year now, and I wanted to take some time to write a review about our experience, on the hope that it will help others.

An overview of our website

Our setup consists of the following pagoda box services, explained below:

Pagoda Box Services

  1. Web1: A web service which holds our WordPress website. This is a regular membership-based woocommerce website, along with a few custom plugins and themes.
  2. Web2: Holds a generic PHPMyAdmin installation. Sometimes we need to manually manipulate the DB, and it’s easier when working with a direct connection instead of opening a remote SSH tunnel.
  3. Web3: A web service which holds our API service. Here are some figures:
    1. We have around 1000 clients daily posting data to our API
    2. Anytime of the day there is between 30-160 users simultaneously posting data.
    3. Each user sends around one request per minute.
    4. our API is built on top of Slim Framework
  4. Worker1: A worker service which handles all of our website-related cron jobs. Since our website is very busy, we wanted it to be very fast, so we moved our WordPress cron jobs to a different service.
  5. Worker2: When our API receives data from our clients, it stores the requests into a queue instead of directly inserting the data into our database. This worker instance takes the data from the Queue and inserts it into the database. If you’re wondering, we used a queue system for the following reasons:
    1. It reduces stress on our database server. If 100 clients are posting data, there is no need for 100 database connections. Only the worker connects to the database and stores the data.
    2. It allows us to send a faster response to clients. Storing data into a caching system like Redis is faster than updating data in MongoDB, although Mongo is pretty fast!
  6. Database1: A database service which holds the MySQL data for our WordPress website
  7. Storage1: This service is a storage service, which holds everything we upload to WordPress, such as images, files and videos… We don’t store these on our web1 instance, because pagodabox is a read-only environment.
  8. Database2: This is our MongoDb instance, which stores hundreds of millions of records, and is basically the most active service of all. We’re processing millions of operations on a daily basis, and we are using almost 75GB of data. If that can’t be called big data, then I’m not sure what big data is. 🙂
  9. Cache1: This is a redis-based instance which hosts our queue system, and acts as a PHP sessions handler. We had to move our PHP sessions to redis, because when you enable redundancy, some requests are processed through one instance, and others through another instance. But since PHP stores session data inside temporary folders, each machine has its own folder, and thus session data is not consistent. Therefore, we solved this problem by storing session data in a redis cache.

Migration To Pagoda Box – The Challenges

When migrating to Pagoda Box, it took us some time in order to get things setup properly. Here’s why:

  1. It took us some time to read the docs, familiarize ourselves with how the whole system works, and the whole terminology (apps, instances, services, Boxfile….)
  2. WordPress was originally built for traditional webhosting platforms. Since pagoda box is a read-only environment, we had to change the way we work as follows:
    1. We had to mark a few directories as writable inside our Boxfile, because WordPress and some plugins need to write to them (Uploads directory, wp-content/cache/ directory…)
    2. W3 Total Cache plugin was a real pain to setup, but once it was setup, everything was running properly. Sometimes when we enable or disable caching methods, we have to manually copy/delete files, since W3 Total Cache places files in WordPress’s wp-content directory upon activation of certain caching methods, and removes them upon deactivation.
    3. Since we’re on a read-only environment, we have to update plugins on our development website, and later on push to pagoda box. Actually, that’s not a limitation since it’s highly recommended that you test on a dev site, but it’s something you need to be aware of if you’re new to pagoda box.
  3. Setting up composer was a real pain, but once you get the hang of it, it becomes really easy.

Pagoda Box Advantages

Here’s what I really like about Pagoda box:

  1. In one git push to your app’s repository, your latest code goes live. It is exactly the same as pushing code to a remote github reposity, and their system takes care of the rest. It does so by reading your Boxfile configuration and acting upon it. You can add servers, modify server configuration… The possibilities are endless
  2. They have a very good support system. For urgent issues, they’re highly available, and for less urgent issues, they usually respond within a day, which is pretty good.
  3. Their systems are really stable, rarely did we have issues with them. We experienced 4-5 times a stuck deploy, and they were pretty quick to resolve it.
  4. There is no system administration involved. You don’t have to worry about server management, period. Your full focus is on writing code.

Pagoda Box Limitations

Although it’s a really great system, it does have its limitations. Here are some we have encountered:

  1. If you’re a seasoned server administrator, you’ll find it hard to work without root access. I found it very hard at first, but I learned that 90% of things can be done without root access. For the other 10%, I’ve always find another way of doing things. So sometimes, the simple solution doesn’t work.
  2. With simplicity comes less flexibility. While this doesn’t hurt most users, heavy users do suffer from time to time. For example, we have critical data on our MongoDB instance that we can’t afford to lose. We wanted to setup an exact replica of the MongoDB on an AWS EC2 instance, but the system didn’t allow us to do so. We ended up creating database dumps and storing them in an S3 bucket. The disadvantage is that backups take hours to complete, and would take hours/days to restore, since we have 75GB+ of data on our MongoDB instance.
  3. If you’re an AWS guru, Pagoda Box can seem pretty expensive. However, if you count all of the system administration time that it saves you, it might be worth it for you.

I hope this helps, any questions, just drop us a line