ScaleSimple works by offloading your origin servers and serving your content from our network of caching devices. Getting up and running is as simple as creating a hostname in our portal, assigning a ruleset to that hostname and updating your DNS to point to our network.

ScaleSimple is made up of a few key parts. Hostnames, Rulesets and Rules. Below are sections dedicated to each of the major components of our platform to get you going as quickly as possible.


Hostnames are the entity which are routed through the ScaleSimple network. When you decide that you would like to accelerate and enable caching for a domain, the first step is creating a hostname. Having ScaleSimple serve that hostname involves a couple of steps that you need to take.

First, you create a new hostname in the portal. When this is done, a new DNS entry is created in our network that you must CNAME your hostname to. Assuming the hostname you create is, the CNAME you must create for in your DNS provider is This means that when someone tries to go to, it will resolve to a ScaleSimple IP address and that user will be routed to the closest destination in our network. We will also then cache your content from our edge nodes. Once your hostname is setup, you must assign a proper Ruleset, see below for more details on rulesets and rules.

If you need help on configuring your CNAME, please check here for our DNS help howto.


Rulesets are the cornerstone of what makes ScaleSimple so powerful and easy to use. Rulesets are assigned to one or more hostnames and contain two sets of rules. The first set of rules are called "global rules" meaning, every global rule is applied to every request (or backend response) in that ruleset. This is useful for situations when you want to apply some action to every request (like remove a query string or header). The second type of rules are called "ordered rules". These are processed top down until a match is found and then the processing stops. This is useful for building more conditional logic into your ruleset. Keep in mind that since rules are processed from the top down, the more specific rules should be placed near the top to ensure they get evaluated first. If you have a more generic rule at the top, then the more specific rule may never get evaluated below it. Also note that ordered rules get processed AFTER global rules, so it is possible for an ordered rule to override a global rule.

Once a ruleset is assigned to a hostname, it is considered to be "Active". The other great feature about rulesets is that they can be shared across multiple hostnames, eliminating the need to duplicate rulesets for all of your hostnames. Active rulesets can be assigned to one or more hostnames. If you need to modify an active ruleset, you need to clone the ruleset by clicking the "Clone" button to the right of the ruleset on the Rulesets page. Active rulesets can NOT be modified once they are active. Once you clone the ruleset we will copy all the rules over and rename the rule to "Copy of Ruleset". You can then rename the ruleset, modify the rules and assign it to a hostname. If your ruleset is in the state "Unassigned" that means that it is not assigned to any hostnames and can be freely modified. If your ruleset is in a state of "Error", then there was an internal error in the ScaleSimple network and someone from our support team will reach out to you right away to investigate.

When creating a ruleset, you have the option of creating a blank ruleset, or using a "Template". A template is an easy way to bootstrap the rules needed for your ruleset. Templates are shared across all of our customers and are there for very common use cases. Some of the common uses for a template are popular CMS systems like Wordpress, Drupal and Joomla. These systems have very specific rules needed to ensure you are caching properly, so we use templates to prevent you from having to rewrite these rules yourself. Once you build a ruleset based on a template, we simply copy the rules into your ruleset so you are free to modify any of the default configurations to suit your needs. If you need a template built for you, just contact us and we will be more than happy to help you out.


An individual rule in a ruleset is composed of two parts, the conditions and the actions. The conditions identify which parts of the request to match on, and the action defines the type of action you would like to take when a condition is matched. Rule Actions have actions that can either be combined, or must be used individually. The current list of actions that can not be combined are HTTP Redirect, Deny Request and "Do Not Cache". All other rule actions can be combined when a rule condition is met.

Conditions, on the other hand are matched either against the client request or the backend response. These rules can be combined and each rule can be set to either be required to match ALL rule conditions or match ANY rule condition. The difference here is that when match ALL is set, every condition must be satisfied as true in order for that rules conditions to be true, whereas match ANY means only ONE rule condition must match in order for that rule to be considered true. For example, say you have a request and you have a rule that says to match the URL against "/directory1" and query string of "q" with a value of "foo". If you had a match ALL setting on this rule , the actions would not be executed because both criteria do not match. However, if you change this setting to a match ANY, then the rule actions would execute since the rule condition "URL == /directory1" matches and only one criteria must match for ANY to succeed. This is useful for customizing the level of granularity that a rule needs.