The Migration to “Cloud”

Over the past 5 months, we’ve extensively evaluated over 150+ different providers and solutions. Today, we’re happy to announce that we will be migrating our entire “High Performance” platform to the “cloud.”

Over the past 5 months, we’ve extensively evaluated over 150+ different providers and solutions. Today, we’re happy to announce that we will be migrating our entire “High Performance” platform to the “cloud.” In addition to this, we’re also rolling out V2 of our platform, which comes with significant changes and improved functionality.

What, and Why?

A “cloud” platform adds an extra virtualization layer on top of “bare metal servers” (which we previously almost exclusively used).

Something like this:

An overtly simplified diagram explaining a virtualized VM vs a bare metal-only server

What makes the “cloud” different from a virtualized VM (virtual machine) is the ability to access a wide range of on-demand resources without the underlying hardware.

For example, if we wanted to double the number of CPU’s available or change the underlying processor, the virtualization layer makes the “guest”/instance OS much more portable. Upgrading means running an operation akin to:

Much easier than scheduling a maintenance window to access the physical hardware, or even moving the data (or drives) to another server.

Having access to a variety of on-demand resources gives us significantly more flexibility to allocate resources and servers as needed. As an added bonus, these “VMs” will run on significantly newer and even more powerful hardware, which means faster websites 🙂


For the most part, with only this change, basically, everything would remain the same. However, we’ve taken this chance to push out some major features and improvements to our platform. Here’s a full list of changes:

  • A full rollout of CynderFS, our in-house filesystem isolation technology
  • Native outgoing email support
  • Removal of support for ModPagespeed (rationale)
  • A “Trash” folder for the built-in file manager
  • Significant speed improvements for PHP
    • Underlying platform and hardware changes have further accelerated the speed (TTFB of uncached requests. We’ve seen TTFB cut by ~20-40%, a major, major improvement over our already-ultra fast platform
  • Drastically improved RTO and RPO for (potential) outages
  • Slightly more simplified CDN management UI
  • Transition to JWT tokens for API authentication
  • Improved bandwidth statistics accounting
  • Minor panel UI changes
  • General tweaks for increased scalability and stability


While a firm date has yet to be decided, this migration will likely take place on 5/17th, from 4-8PM PST.

During this migration, there will be no impact to service availability. The nature of our platform allows us to perform the migration without interruption and instantaneous propagate origin route changes.

Having said that, we would recommend ceasing any sort of changes or updates to your site during the migration window, as these changes may not be migrated to the new server. If this isn’t possible, we recommend reaching out to us. We’re happy to coordinate the migration for your site individually at another time, or simply perform another synchronization for your site alone post-migration.

Post Migration Changes

The IP used to connect to the server will change. There are no DNS updates required, but if FTP/FTPS/SFTP is currently being used, the hostname will change. This information will be updated on the panel.

Your login information and portal URL will remain the same.

While we’ve tested the new environment extensively, this is not a 1:1 platform. We highly, highly recommend giving your site a brief look and test to ensure:

  • All data was migrated
  • Everything is working as expected
  • The site looks the same

Furthermore, we will be deprecating the “/purge-some” CDN + Local Cache Endpoint. (

If you’re using our WordPress plugin, it has already been updated to reflect this change. If you’re using a third-party application, we recommend updating it to use the “/purge-multiple” endpoint instead.

Furthermore, the authentication scheme will shift to a JWT based authentication.

The new token will be visible from the portal under “CDN & Caching.” We recommend switching out the token being used by any application (including our WordPress plugin) as soon as possible. The current authentication scheme will cease to work sometime after the migration. If any help is needed doing this, please let us know.


April 30th: Initial Migration Notification

May 8th: Migrations Start

May 17th: General Migration Window from 4-8 PM, PST

May 21st: Last Day to Migrate

May 24th: Current servers will be shut down and deprecated. If something breaks because it’s still pointed to the old server, you’ll know and we can work to fix it ASAP.

May 28th: All data on the current platform will be removed.


We’re moving to a faster and more reliable platform. Look out for some more information from us, and be ready to test your site and change the API token once the migration is live.

As always, we’re available anytime if you have any questions.

Leave a Reply

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