Upsun uses the Fastly CDN service to serve static pages from servers geographically close to end users. This allows for tremendous speed improvements over Plesk (in which we relied instead on the internal Drupal cache), but it does come with new complexities about which we must be aware. Following are details of all of the parts of the system that pertain to our work. 

1. Purging the CDN
   When nodes and other objects are changed or deleted, the CDN will continue to serve stale copies until the URLs of the altered objects are purged. This can be done a couple ways:
   1. A cron run on the target site. This is the preferred method. Users can wait for the next scheduled cron run (up to 19 minutes), or manually run cron from the status page (Reports > Status) or the cron page (Configuration > System > Cron). 
   2. Using the Fastly purge/invalidate all site content button at the bottom of Drupal's Fastly page (Configuration > Web services > Fastly). WARNING: DO NOT USE THE PURGE WHOLE SERVICE BUTTON UNLESS YOU ARE ABSOLUTELY 100% SURE YOU KNOW WHAT YOU ARE DOING. This function, whose legit purpose I can't possibly imagine, is our system's self-destruct button. It will completely invalidate every CDN on every site GT hosts on Upsun. This will produce a surge of traffic large enough to extinguish the sun and we will be forced to feed you to the pigs. Don't do it.
   3. Using the Fastly plugin in the Upsun console. From here you can purge all URLs for a site (not recommended) or purge individual URLs. 
       
2. The Fastly Upsun plugin
   Each site and each environment has its own Fastly plugin. If the plugin has not been installed, follow the instructions on this page. If the plugin requests credentials, you can get these by doing upsun ssh "env" | grep FASTLY or upsun ssh -e main "env" | grep FASTLY for the stage and main environments respectively.
   1. The plugin page displays realtime information on Fastly performance, VCL versions, ACLs, and dictionaries for the service. Of particular note:
      1. VCL versions. Click the looking glass next to the latest version and search for drupalmodule. If this is not present, Drupal's default VCLs have not been uploaded (See section III-1).
      2. Manage ACL. There are a couple of items of interest here:
         1. rate_limit_bypass
            Enter specific IPs to allow unlimited hits on the application. Note that it's then up to you that you to avoid running processes that are indistinguishable from denial of service attacks, por favor. 
         2. NGWAF_bypass
            IPs entered here allow a bypass of the WAF. This and 3.i are both useful for DubBot.
   2. Manage Dictionaries
      There is one item of interest here: geo_restrict. Use this to block Iran or Canada or whatever. 
3. Drupal modules
   These all need to be enabled. Most of them are configuration-free. 
   1. Fastly
      The Fastly module does not require any configuration, but after installation, or if ever anything on the configuration page should change (and possibly also whenever the module is updated), one must click the upload latest Fastly VCL, which will then show up in the VCL versions panel (II-1-i).
   2. Core tags queuer
      Objects in Drupal are tagged to create cache groups. Drupal core provides most of the cache groups you would expect: nodes, users, blocks, and so forth. No configuration required. 
   3. Fastly purger
      Connects the purge module to Fastly. No configuration required. 
   4. Purge cron processor
      Creates a cron task that processes 60 queued purge items per queue. No configuration required. 
   5. Purge UI
      Provides a UI for the purge module. We should leave this on because it can be useful to be able to see the queue. No configuration required. 
   6. Purge
      Does all the heavy lifting. Should be configured (Configuration > Development > Performance) as follows:
      1. (in the Performance tab) Caching
         Set the browser and proxy cache maximum age to 1 year. Seems crazy, right? Basically this just means that if a path never gets invalidated, keep serving the same page for a year. Which is fine because no invalidation means the page hasn't changed. If the system allowed, it could be set to infinity. 
      2. (in the Purge tab) Drupal Origin
         Choose Fastly.
      3. That's it for configuration, but there is useful information in the Purge tab:
         1. In the Queue fieldset, under the Database select, you'll find an option named Inspect. This will show you exactly which cache tags are awaiting purging. 
         2. In the event that something goes wrong, you might want to change the logging behavior under the Logging fieldset.