New Feature: RunCache

Introducing RunCache Purger

What Is RunCache?

Everyone wants a fast website and at RunCloud, we love fast websites. When you install RunCloud on your server, NGINX is a part of the stack and caching is turned on by default. When caching is enabled, NGINX will save responses in the disk cache and use them to respond to browser requests without having to proxy requests for the same content every time. This will reduce latency, offload repetitive CPU tasks from your server, and increase speed times as well as Time to First-Byte.

From the NGINX website itself:

A content cache sits in between a client and an “origin server”, and saves copies of all the content it sees. If a client requests content that the cache has stored, it returns the content directly without contacting the origin server. This improves performance as the content cache is closer to the client, and more efficiently uses the application servers because they don’t have to do the work of generating pages from scratch each time.

Within the past year or two, we noticed an issue that our users were having: they were not able to clear their NGINX cache in any easy way and it required you to be an advanced user with an abundance of knowledge of Linux terminal commands to clear the NGINX cache. The only way to really do this without that knowledge was to restart your server, which is usually not ideal for anyone who needs their website up and running 24/7.

While we definitely salute our users with the advanced knowledge they may have, RunCloud was established with developers from all backgrounds in mind: from beginner to expert. Thus, we have been working hard to bring you a new feature that will make life and running your website a lot easier.

The update will enable one-click NGINX Cache Purging directly through your RunCloud dashboard via WordPress one-click install only. You will no longer need to mess with anything through Linux terminal command line interface for server-side caching. The RunCache service will come with its own WordPress plugin to install which will allow you to control everything right from WordPress or the RunCloud Dashboard.

Once you have created a web application through the RunCloud dashboard, you will see new options available. To access these options, simply click on RunCache or General Settings in the RunCloud dashboard.

RunCache Settings

After you have installed a web app for WordPress, you will gain access to the RunCache page, but you will need more than the free plan to use it. By default, RunCloud will set the Cache Folder Size to 50 MB. If you have an abundance of SSD storage, you may want to increase this to at least 1 GB or 1024 MB.

You may also tell RunCloud to store the cache for as long as you wish with 0 being never, 60 being one hour, or even 1440 minutes which equals 24 hours, and is highly recommended if you wish to cache everything for at least a day.

RunCache Pre-Installation

When you get everything set up, you will gain access to RunCache within the RunCloud dashboard. You can purge the cache or remove the plugin directly from the your WordPress install. Without RunCache being installed, caching will still occur, but you will be unable to set limitations for your NGINX caching.

Although you can delete the plugin directly from WordPress, if you do decide to remove it, it is recommended that you remove it via the RunCloud Dashboard.

RunCache Post-Installation

Note: RunCache will not cache anything for logged-in WordPress users. As you gain more visitors, you will begin to see the amount of data cached for them. The larger, the better, which means your visitors are being served data directly from the cache rather than from the database, speeding up the delivery of all content on your website.

What Is RunCache Purger?

By default, the NGINX server will always try to cache everything in order to speed up queries and processes of the server and the CPU. Other than by code, this involved a very lengthy process of clearing the cache, detailed in this article: NGINX Caching Tutorial For WordPress. Unfortunately, this method was not only tedious, but did not accomplish the task it was intended to do.

The RunCloud team realized this was an issue for all of our users. To resolve it, the RunCloud devs were hard at work to correct the issue and made it even more simple for our users to clear the NGINX cache. All of the pains of trying to clear your cache are now taken away with our brand new plugin via RunCache Purger.

We will be launching it with a few basic options and releasing updates based on further feedback and other findings as we move forward. The WordPress plugin will be available as well as the RunCloud Purger through the RunCloud Dashboard.

Once installed, head over to WordPress and you will now see RunCache automatically installed as a plugin on the Administration bar.

RunCache Purger plugin located on the Administration Menu

Located within the Settings is the menu item for the RunCache Purger as well.

RunCache Purger located on the Settings Menu

Once you click into the RunCloud Purger, you will see a screen with a variety of options.

RunCache Purger WordPress Settings Dashboard

Within this screen, you may clear the cache for the Homepage upon New Posts and Pages and deleted posts. You can also set options to purge all cache content when content is published or comments are added or removed. The cache extends to clearing the cache for archives.

RunCloud will automatically setup Redis Object caching for you with this plugin. You may also choose to purge the Object Cache and enable or disable the RunCache Purger plugin to handle this for you. It is unlikely you have to change any settings for the Redis Server. In fact, it is advised that you do not change any of the Redis Server settings. Doing so may cause things to stop working.

While RunCloud has been hard at work to deliver this new feature, and it is technically out of beta, we still need users to continue testing and ensure everything is working properly. For any issues that may arise, please use the Support menu at the top and open a ticket. We are very excited to release this new feature and hope it is as useful to you as it has been for us.

Share This On
Share on facebook
Share on twitter
Share on linkedin
Share on reddit

24 thoughts on “New Feature: RunCache”

    1. Hey Mark, considering this has to do with the NGINX cache, which is caching at the server level, this should be compatible with multisites and a complimentary cache to WP Rocket.

      1. This is fantastic! I’ve been waiting to see what would come of the nginx caching on runcloud, and I can’t wait to try this out!!!!

    1. Hey Irwan, an interesting request, but it has been done before. Remember that RunCloud, ServerPilot, Moss, EasyEngine all setup their own Apache/NGINX stacks meaning they tweak their own files and then install them on your server the way they feel is the most optimized. With the RunCloud NGINX stack, caching is enabled by default at the server level, so if you wish to test it, you have to setup a server with a one-click install WordPress on it, such as DigitalOcean or Vultr, and then run your tests. Setup another server with RunCloud on it and run the same tests, and you should see a difference. Here’s an article where someone actually did the test: https://quvor.com/serverpilot-vs-runcloud-wordpress/.

  1. Can you clarify the statement “when you install RunCloud on your server, NGINX is a part of the stack and caching is turned on by default”?

    Does that mean that every RunCloud application has NGINX caching enabled automatically, or does this statement only apply to one-click-install WordPress applications?

    1. Nginx caching functionality is always there, but it will need extra step to enable it on your web application.

      Before RunCloud released RunCache, we usually have to follow this tutorial https://blog.runcloud.io/NGINX-caching-tutorial-wordpress/ and it requires a lot of work.

      RunCache simplify this process and RunCache Purger WordPress plugin allows you to clear Nginx caches from your WordPress dashboard.

  2. Hello,

    RunCache is great but I have problem with WooCommerce. If user is not logged. Also I have wishlist and compare on my store and you hard cache this pages so if I user delete something from wishlist or compare, it is not removed from page.

    Can you please fix this?

    1. If you can’t see RunCache menu when viewing your web application, you can go to Web Application Settings page. You will see new “Web Application Type” option under Web Application Stack options, please choose WordPress.

      If you have implemented the NGiNX caching by following tutorial from this blog, please REVERT everything to their original state before you enable RunCache for your web application.

  3. (1) So this works only on the Apache/Nginx stack? Not on native Nginx only?

    (2) The cache will only work for a site that is creating by one-click WordPress install? What about a previously installed site (i.e. created prior to one-click install existing)?

    (3) What is it caching? JS and CSS files?

    (4) Is there a way to tell if the cache is actually working?

    1. 1) It works for both native Nginx and Hybrid (Nginx/Apache) stack.

      If you are using the Native Nginx stack, it will use FastCGI cache. And if you are using the hybrid setup, it will use the proxy cache.

      you can refer to previous tutorial (before RunCache), https://blog.runcloud.io/nginx-caching-tutorial-wordpress/

      2) If you can’t see RunCache menu when viewing your web application, you can go to Web Application Settings page. You will see new “Web Application Type” option under Web Application Stack options, please choose WordPress.

      3) PHP

      4) you can check it from HTTP Response where you will see x-runcloud-cache = HIT, please check this screenshot, https://prnt.sc/ppjmob

  4. This is very interesting, I have been using the “old method” in all my websites, but what about updating from the past method to this one, and what about if we don’t desire to use one-click wp, and we wish to install WP manually.

    Is there any advice on how to migrate or how to use this new method if we installed wp previously or without one-click service.

    1. If you install WordPress manually, you can go to Web Application Settings page. You will see new “Web Application Type” option under Web Application Stack options, please choose WordPress.

      Once you choose WordPress for “Web Application Type” option, then you will see RunCache settings page on current web application.

      If you have implemented the NGiNX caching by following tutorial from this blog, please REVERT everything to their original state before you enable RunCache for your web application.

    1. Redis will be used for Object Cache.

      If you want to use RunCache + RunCache Purger plugin, then it is better to control Redis Object Cache from RunCache and disable object cache from W3 Total Cache.

  5. This is for the people that would like make use of RunCache or just NGINX caching, but with their own WordPress installation (instead of the one-click-install mentioned in the article):

    Easiest way to achieve this is by creating a new one-click WordPress installation. Runcache should be enabled by default. Now ssh into your machine and run ls command on /etc/nginx-rc/extra.d then you’ll see 4 files per one-click WordPress installation. The files are named as followed:

    .headers.runcache-purger.conf
    .location.http.runcache-purger.conf
    .location.main-before.runcache-purger.conf
    .location.proxy.runcache-purger.conf

    Now duplicate those files and replace with the app name you want to enable caching for. So you if your app name is called super-cooker your file names will be:

    super-cooker.headers.runcache-purger.conf
    super-cooker.location.http.runcache-purger.conf
    super-cooker.location.main-before.runcache-purger.conf
    super-cooker.location.proxy.runcache-purger.conf

    Now you have to open each of those renamed files and find and replace all occurrences of the old app-name and replace them for, in this case, super-cooker.

    Make sure you have made no syntax errors by running:
    nginx-rc -t

    now restart nginx:
    systemctl restart nginx-rc

    Voila, RunCache should now be functional once installed as a plugin in your WordPress installation. As far as I can tell, you can throw W3 Total Cache out of window *byeee* /wave

    Good to know, the cache folder will be located at /var/run/runcache-proxy-

    If you’re running atomic deployments you probably want to be making sure to purge all cached files upon a new release. Therefor you should add a script before or after Activating Latest Release. Make sure to remove the contents of /var/run/runcache-proxy- with: rm -rf /var/run/runcache-proxy-/*

    Although the folder is owned by runcloud-www I haven’t been able to run the command via that user. So, for now I set the user that should excute the command to be root.

    Now you’re effectively using NGINX caching with the ability to use the RunCache plugin!

    1. if you want to disable RunCache from your web application:

      (1) deactivate & delete RunCache Purger plugin on your WordPress dashboard.

      (2) go to RunCache settings on your Web Application setting page, you can find “Deactivate RunCache from your web application” option there.

  6. Hi,
    So maybe a close case.. when I’ adding new application and choose to install WordPress it will be installed, database created etc but.. finally it will give me error and will not be on application list in runcloud. So last time I endup with adding application “by hand” and pointing to the same directory it installed wpress earlier but not catch it in the runcloud panel.

    Will test this again for sure but.. for now.. with quick wp install.. not a good experience.

  7. @Agus, I think that @Ian is talking about the situation I described. There’s no easy way to remove since the instance is not on applications list. So only adding separatelly as custom with directory pointed and removing the created database would help.

Leave a Comment

Your email address will not be published. Required fields are marked *

You May Also Like

Scroll to Top