When Pagely first launched in 2006, the idea was simple: we wanted to make it easier for people to get online with WordPress. We grew rapidly at first, starting out as a WordPress software-as-a-service solution and quickly evolving into the first managed hosting platform for WordPress.\r\n\r\nOver six years, we stumbled, got up, tried again, and developed Pagely. Each new version of our platform was better than the one before and made each month since we started our best month to date.\r\n\r\nThis is our origin story, from 2006 to 2012. In it, we share with you how our company came to be, and highlight some of the technical aspects of what powered the Managed WordPress Hosting system we developed during this time.\r\n<h2>Before Pagely, We Built Websites for Clients<\/h2>\r\nEvery idea starts with a problem. Ours was simple: we had too many clients.\r\n\r\nBack in the internet dark ages, pre-Twitter, my wife, Sally, and I ran a web consultancy shop in Phoenix, Arizona. We served all manner of clients with your typical fare of web-related services, like website design (remember Dreamweaver?), SEO, light programming, and the like.\r\n\r\nAround late 2005, we started using WordPress for deploying client sites. These were the early days of WordPress -- launched only two years earlier -- but even then we could see that it was going somewhere. WordPress 1.2 showed promise.\r\n\r\nSally wondered why it took so long to create custom sites, one day saying, "I thought you guys just clicked a few buttons and added some images and the website appeared. Why can't it be that easy?"\r\n\r\nTurns out, she was some kind of prophet.\r\n\r\nWe went upmarket as our business grew, charging tens of thousands of dollars rather than hundreds of dollars. Soon we were turning away repeat business from early clients. After Sally heard me turning away our fourth client one day, telling them we had raised our prices and couldn't reduce our fees, she said to me, "Josh, you've said \u2018no' to a few thousand dollars today. We are leaving money on the table!"\r\n<h2>Identifying the Opportunity: A SaaS for Managing WordPress<\/h2>\r\nSo there it was, an opportunity staring us in the face. How could we still serve these lower-paying customers profitably? We had to automate -- we needed to give them the power to build their website themselves.\r\n\r\nPagely v0.0 was born. Or as it was known then, Flare9.com.\r\n\r\n<img class="lazy aligncenter wp-image-20209 size-full" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image2.jpg" alt="flare9" width="613" height="500" \/>\r\n\r\nOur market research found no one else in the space. As in: no one else was offering anything like an automated software-as-a-service approach to managing self-hosted WordPress sites.\r\n\r\nThere were consultants clicking buttons for people, but Flare9 was the first-of-its-kind WordPress SaaS.\r\n<h2>Pagely v0.0: Under the Hood<\/h2>\r\nOur first crack at a Managed WordPress Hosting solution (we'd try again later) was <a href="http:\/\/blog.joshuaeichorn.com\/archives\/2007\/03\/12\/what-ive-been-up-to\/" target="_blank" rel="noopener noreferrer">coded by our only employee at the time<\/a>, Joshua Eichorn. He bootstrapped a slick little system that could intake and bill orders and send them over a socket connection to our "installer" library, which then ran around moving files, creating databases, and restarting Apache.\r\n\r\n<img class="aligncenter size-full wp-image-20212 lazy" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image5.jpg" alt="pagely in 2006" width="354" height="316" \/>\r\n\r\nAs an aside: Joshua is one of the most talented programmers I've ever worked with. After working at Pagely for a year and then going on to work as Director of Engineering at Stumbleupon, he returned to Pagely, becoming our CTO.\r\n\r\nAt the time we were using the Plesk hosting panel on all our web servers. We also tapped into the Plesk SOAP API to handle much of the vhost and DB config for us. The server was a simple Dual-Core Xeon hosted at EV1 (now defunct).\r\n\r\nHere's a rundown of our basic setup:\r\n<ul>\r\n \t<li>One server doing everything (PHP4, MySql, Apache, email, etc.)<\/li>\r\n \t<li>Simple code library written in the then brand new Code Igniter framework<\/li>\r\n \t<li>Plesk SOAP API for vhost configs<\/li>\r\n \t<li>Very basic file and database backups<\/li>\r\n<\/ul>\r\nLooking back, we didn't have:\r\n<ul>\r\n \t<li>Caching plugins<\/li>\r\n \t<li>HTTP acceleration, like Varnish or NGINX<\/li>\r\n \t<li>Firewalls<\/li>\r\n \t<li>Memcache or APC<\/li>\r\n \t<li>Automatic updates for WordPress or plugins<\/li>\r\n<\/ul>\r\n<h2>It Worked! Now the Hard Part: Finding Customers<\/h2>\r\nThe provisioning system worked well, and in late 2006, over the course of two to three months, we had forty or fifty paying customers.\r\n\r\nHosting, for the most part, was easy. Marketing was where we struggled.\r\n\r\nYou've got to remember, this was pre-social media, during the heyday of Google PPC. No one had really heard of WordPress yet and we had a really hard time getting anyone to notice us outside of our local business community.\r\n\r\nAfter a couple of months trying to get noticed, we turned off active sign-ups and moved on.\r\n<h2>Try, Try Again: Rebooting Pagely in 2009<\/h2>\r\nIn 2009, with the economy in a skid, we were ready to try again. I was really tired of client work, and we still had 70\u201380% of our old customers still faithfully paying their monthly fees.\r\n\r\nWe started rewriting the code base and chose a better name: Pagely.\r\n\r\nWe re-launched, but again our marketing missed the mark. Pagely was still ahead of its time and users still weren't quite sure what we were offering.\r\n\r\nSo in late 2009, after many months of retooling, we went back to the market with an improved Managed WordPress Hosting solution.\r\n\r\n<img class="aligncenter size-full wp-image-20216 lazy" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image9.jpg" alt="pagely in 2009" width="800" height="1600" \/>\r\n\r\nThe new platform was based on the core logic of the prototype -- providing an automated way to deploy WordPress-powered sites. But this system, Pagely 1, offered groundbreaking improvements:\r\n<ul>\r\n \t<li>Automatic WordPress core updates<\/li>\r\n \t<li>Automatic WordPress plugin updates<\/li>\r\n \t<li>Automatic nightly backups<\/li>\r\n \t<li>An integrated "hosting panel" via a custom-developed WordPress plugin that communicated with our core system and wrapped vital hosting administration tasks like DNS, email, and billing management without the bloat of a full cPanel or Plesk interface<\/li>\r\n \t<li>Our one-of-a-kind white screen eliminator<\/li>\r\n<\/ul>\r\nInitially, we pushed the "choose your theme" aspect of our platform, letting customers select from a library of chosen WordPress themes. But this turned out to be a conversion killer -- users stressed over which theme to use and ultimately abandoned the cart. (We later downplayed this feature in Pagely 2, which we'll get to shortly.)\r\n<h2>Pagely 1: Under the Hood<\/h2>\r\nPagely 1 used the same infrastructure as our earlier prototype -- a single LAMP box using the Plesk SOAP API, but now using PHP 5. Really, not that exciting.\r\n\r\n<img class="aligncenter size-full wp-image-20218 lazy" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image11.jpg" alt="pagely 2009" width="354" height="316" \/>\r\n<h2>This Time Around, Pagely Worked<\/h2>\r\nEverything worked like a charm, and by the end of 2009, we had a modest hundred or so users.\r\n\r\nCustomer feedback was interesting. Some people loved Pagely, while others hated it. There were people who would troll us by saying, "Oh, I can do X myself. Why would I pay for it?" Those who got it, got it and understood what we were trying to do: make WordPress better through automating technical tasks.\r\n\r\nBy early 2010, as our customer count neared five hundred, we knew we needed to scale. Our hosting provider at the time wasn't helpful. Nothing against them, but they were a hands-off provider -- they basically made sure the server was plugged in, and that's about it.\r\n\r\nSo we searched for a new host. We needed a host we could partner with to not only address our security concerns but also assist with fine-tuning and managing the hardware setup.\r\n\r\nAnd that's when we found Firehost.\r\n<h2>Finding a New Home and Beginning to Scale<\/h2>\r\nFirehost (now <a href="https:\/\/www.armor.com\/" target="_blank" rel="noopener noreferrer">Armor<\/a>) met all of our criteria. Plus, I knew the CEO. They were small (at the time) and nimble like us, and security was their core offering.\r\n\r\nIn one evening, we migrated our single server over to Firehost.\r\n\r\nWe also went through a couple of site redesigns during this time:\r\n\r\n<img class="aligncenter size-full wp-image-20210 lazy" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image3.jpg" alt="pagely redesign" width="800" height="1200" \/>\r\n<h3>Better Security<\/h3>\r\nThe move to Firehost added multiple levels of security to our system. Not only did it boost our offering, but it value-added -- we stressed this benefit in our marketing and haven't strayed from it since.\r\n\r\nOur security features at the time included:\r\n<ul>\r\n \t<li>Managed redundant firewall protection<\/li>\r\n \t<li>Managed redundant web application firewalls<\/li>\r\n \t<li>Managed redundant DoS\/DDoS mitigation<\/li>\r\n \t<li>Multi-level intrusion prevention and detection<\/li>\r\n \t<li>Real-time virus scanning<\/li>\r\n \t<li>Real-time malware scanning<\/li>\r\n<\/ul>\r\n<h2>Pagely 2: Under the Hood<\/h2>\r\nOur new and improved system featured:\r\n<ul>\r\n \t<li>All nodes HA (High Availability)<\/li>\r\n \t<li>Four web servers running Plesk & Litespeed (and DNS)<\/li>\r\n \t<li>A single MySQL node<\/li>\r\n \t<li>The Plesk SOAP API for vhost configs<\/li>\r\n \t<li>Opcode Caching<\/li>\r\n<\/ul>\r\nIt was around this time that we also started experimenting with WordPress caching plugins.\r\n\r\n<img class="lazy aligncenter wp-image-20217 size-full" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image10.jpg" alt="" width="910" height="721" \/>\r\n\r\nWe were moving in the right direction. We had better security and enough power to serve thousands of domains.\r\n\r\nSpeed-wise, this setup was okay. Initial hit (not full page load) times were about 200\u2013400ms. If you had been a Pagely customer around this time, you would've felt some pain: thanks to our single-server-per-user setup, we had to take down an entire node whenever we needed to run maintenance.\r\n\r\nIn 2010, we flew past one thousand customers. It was also the year we:\r\n<ul>\r\n \t<li>Launched our Reseller program, allowing folks to white-label Pagely;<\/li>\r\n \t<li>Deployed our Vertical Platform, allowing select partners deeper integration with custom reseller packages;<\/li>\r\n \t<li>Switched email to a third party provider;<\/li>\r\n \t<li>Had a PowerUp system for a while, packaging bundles of themes and plugins from our providers. We moved away from even though it is was fairly successful.<\/li>\r\n<\/ul>\r\n<h2>New Players Enter the Managed WordPress Hosting Market<\/h2>\r\nBy 2010, new players began arriving on the <a href="https:\/\/pagely.com\/blog\/managed-wordpress-hosting\/">Managed WordPress Hosting<\/a> scene that we had started. It was inevitable. We had done the hard yards to prove the space had legs and that there was revenue to be made, and no good idea goes un-copied for long. We were also making a name for ourselves in the WordPress community, and that had helped get the word out.\r\n\r\nA couple of interesting points regarding these new arrivals:\r\n\r\nAt SXSW in 2010, I went to a WordPress barbecue held at a co-working space in Austin, where I handed out a few shirts and talked to folks about Pagely. One guy I distinctly remember talking to must've really been paying attention because a few months later he co-founded a competing company.\r\n\r\nThis company's co-founder solicited us about using our technology to power their new offering rather than re-inventing the wheel. I was receptive to the idea (it fit squarely with our collaboration-over-competition philosophy) and agreed to a phone call, which never took place -- they decided to reinvent the wheel after all.\r\n\r\nAnother new player wasn't content with merely re-factoring our idea, but was "heavily" inspired by our marketing. I had to pull them up on the overt similarities between our website copy.\r\n\r\nAt the end of the day, we didn't -- and we still don't -- see any of these companies as competitors. We work from a mindset that with tens of millions of WordPress sites online, there's more than enough space for other Managed WordPress Hosting providers.\r\n<h2>Time to Go BIG: Scaling with Pagely 3<\/h2>\r\nBy late 2010, it was time to scale again. The system choices we had made when we started out with Pagely were fitting at the time but, as we grew, and kept growing, our old system was struggling under the strain.\r\n\r\nSo we embarked on what would be an all-consuming project: Pagely 3.\r\n\r\nWith Pagely 3, our goal was to design<a href="https:\/\/pagely.com\/blog\/wordpress-data-reliability\/"> a system that was more reliable<\/a>, secure, scalable, and -- importantly -- performant.\r\n\r\nOur plan was to develop Pagely 3 next to Pagely 2 -- build a mansion next to the condo and then, come moving day, pack everyone up and move next door. Sounds simple, right? As it turned out, the build process was long and not without problems.\r\n\r\nWe started by consulting some of the best and brightest minds in the web community. I spent hours talking to my good friend <a href="http:\/\/stu.mp\/" target="_blank" rel="noopener noreferrer">Joe Stump<\/a> (former Lead Architect at Digg), among others who had "scaling" knowledge. We developed a simple plan: use small nodes to do specific tasks and scale out in layers.\r\n\r\nWe decided we needed dedicated machines for MySQL, web, Varnish, Memcache, etc. We also needed load balancers out front and robust, fast storage behind it.\r\n\r\nWe also had to dump Plesk. It was fine when Pagely was small, but it simply didn't scale.\r\n\r\nHere's how we built Pagely 3 in five phases:\r\n<h3>Phase 1<\/h3>\r\nOur first task was to add more database servers -- two new slaves coming off the master. Then we added WordPress's <a href="http:\/\/codex.wordpress.org\/HyperDB" target="_blank" rel="noopener noreferrer">HyperDB<\/a> system-wide to segment those reads and writes. We went from a single 8 Core 17GB machine to 3\u20134 Core 10GB machines. The slaves happily processed 700\u2013800 queries a second at 0.20 load.\r\n<h3>Phase 2<\/h3>\r\nNext, we set up new storage with NFS. At first, we went with a solid 700GB disk, but decided it would be better to serve ten 70GB disks up to the web nodes by NFS4. Firehost also upgraded all our storage to Fibre. The disk speeds were crazy fast. We did all hard file operations directly on the storages nodes, which also sped things up.\r\n<h3>Phase 3<\/h3>\r\nWe set up Zeus load balancers out front in a failover configuration, with dual Varnish nodes directly behind it. This gave us a lot of flexibility, allowing us to segment and direct traffic around or through specific Varnish nodes directly to some or all of the web nodes. It was also fault-tolerant -- if both Varnish nodes fell over, everything would move gracefully to the web nodes. With this setup, we could serve pages and static assets in 20\u201350ms -- a 4x improvement over Pagely 2.\r\n<h3>Phase 4<\/h3>\r\nNext, we set up some other nodes to handle a few management tasks like Puppet, Memcache, cron jobs, backups, logging, etc. We also gutted all the code that relied on Plesk since we were no longer going to use it and bashed together a temporary set of scripts to install and manage our system.\r\n\r\nFinally, we directed certain types of traffic to specific nodes tuned for the task. We didn't blanket all web nodes with all traffic. As an example, we set up wp-cron.php commands to hammer a pool of servers all day, allowing others to work without nasty processes sapping CPU.\r\n\r\nGoing into 2012, we varied between sixteen and twenty-four4 nodes running, depending on load. Here's what the Pagely 3 server topology looked like:\r\n\r\n<img class="aligncenter size-full wp-image-20215 lazy" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image8.jpg" alt="" width="910" height="1024" \/>\r\n<h3>El Pollo Diablo: Top-Tier Hosting<\/h3>\r\nIn 2010, we launched El Pollo Diablo, our Managed WordPress Hosting service for top-tier customers.\r\n\r\nIt was essentially the same architecture stack with a hybrid approach. We routed traffic through the load balancers to a dedicated Varnish node and web server pool specific to the customer. Sometimes the customer would run their own MySQL pool as well; other times they took advantage of our MySQL cluster. This flexibility allowed customers true "dedicated" resources but also offered the use of our redundant and failover safe systems as needed.\r\n\r\nObviously, we don't want to share every piece of the puzzle, as there were a few blackops systems we put in place to add that little extra awesome that made Pagely special back then.\r\n<h3>Phase 5: Transitioning Customers<\/h3>\r\nMoving clients to the new system wasn't easy. Over the three months from October 2011 to just after Christmas, we moved one of the old Plesk servers at a time, rsynced all that data over, then popped IPs off those nodes and onto the load balancers. We moved our last customer after Christmas and finally shut down the old nodes. After every block, we would tune and test, uncover bad mojo, and cure it.\r\n\r\nThat period between October and December 2011 was probably the hardest our company has had to face, and hopefully ever will face. We had a hard time getting the balance just right, redoing our storage setup and Varnish configs at least four times while serving live traffic.\r\n\r\nIt's hard to plan for what you don't know. For example, a nasty bug in PHP at the time essentially lstated a file four to eight times every single time it requested it. On local storage, you probably wouldn't notice the hit, but over NFS with the millions of files we were accessing millions of times a day, it was literally shredding the SAN and sending IO on the web nodes through the roof.\r\n\r\nThis was just one of the handful of things we found at scale.\r\n\r\nAgain, we had to work through each of these things under live conditions. And once we moved a block of customers, there was no going back.\r\n\r\nThere was some customer attrition as we worked through the issues. We'd won them over with a solid offering and stellar support, but even the most understanding customers would only hang around so long if we couldn't keep the system up for more than ten hours at a time.\r\n\r\nWe wished them well, knowing they'd be back -- they always came back because other Managed WordPress Hosting solutions "just don't stack up" (one customer's words, not mine).\r\n\r\nAfter three tough months, investing $100,000 in labor and new hardware while losing customers, we continued to grow. We hired four employees, more than doubled our customer base, and redesigned our website.\r\n<h2><img class="aligncenter size-full wp-image-20208 lazy" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image1.jpg" alt="" width="910" height="1229" \/>\r\nFine-Tuning Pagely 3<\/h2>\r\nGoing into 2012, we investigated alternate storage systems and looked at everything from <a href="http:\/\/www.gluster.org\/" target="_blank" rel="noopener noreferrer">gluster<\/a> to <a href="http:\/\/www.netapp.com\/us\/" target="_blank" rel="noopener noreferrer">netapp<\/a>, and <a href="http:\/\/en.wikipedia.org\/wiki\/Global_File_System_(Red_Hat)" target="_blank" rel="noopener noreferrer">GFS<\/a>. We were constantly fine-tuning and tweaking the Varnish nodes to maximize hit rate and delving deep into WordPress itself to tune it for our system.\r\n\r\nAt this point, we had essentially forked WordPress. We maintained a set of patches we applied to new versions of the core software and tested before rolling them out to the customers.\r\n\r\nWe also looked at alternate caching systems around the database and object cache to make full use of Memcache; <a href="http:\/\/php.net\/manual\/en\/book.apc.php" target="_blank" rel="noopener noreferrer">APC<\/a> was also running on a very narrow fileset that could be expanded.\r\n\r\nWe still had our work cut out for us, but we were making progress daily instead of monthly.\r\n<h3>Updating the Pagely Dashboard<\/h3>\r\nOur business dashboard had performed its duties well over the years, but it was time to retire it. I had coded it in CodeIgniter and it allowed us to perform nearly any task needed without ever hitting the command line. We could pull up accounts, orders, domains, and DNS; manage affiliates and resellers, and even track our growth.\r\n\r\nHere's a look at the dashboard we retired:\r\n\r\n[caption id="attachment_20211" align="aligncenter" width="910"]<img class="lazy wp-image-20211 size-full" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image4.jpg" alt="" width="910" height="1634" \/> Note: The credit card number is only the last four digits and is pulled from Authorize.net with an API call. We never sit on this data.[\/caption]\r\n\r\nThe dashboard setup worked from a system management and app deployment perspective, but it was slow and prone to errors. It worked exceptionally well when managing five hundred domains and adding two or three a day. But it came under strain when managing thousands of domains and adding ten to twenty a day.\r\n<h3>A Brand New Backend for Pagely 3<\/h3>\r\nUp through Pagely 2, we were using the Plesk SOAP API to manage vhost deployments on specific web nodes. Then with Pagely 3, we bashed together some scripts to replace Plesk. But those were temporary fixes, and in early 2012 we rewrote our whole deployment and management system upon a CodeIgniter REST API.\r\n\r\nOur new account dashboard included:\r\n<ul>\r\n \t<li>Reseller management<\/li>\r\n \t<li>Account management<\/li>\r\n \t<li>Domain management<\/li>\r\n \t<li>Billing system<\/li>\r\n \t<li>DNS management<\/li>\r\n \t<li>Domain registration<\/li>\r\n \t<li>App provisioning system<\/li>\r\n \t<li>Reporting\/logging<\/li>\r\n \t<li>Affiliate management<\/li>\r\n \t<li>Infrastructure management<\/li>\r\n \t<li>Product management<\/li>\r\n \t<li>Support integration<\/li>\r\n<\/ul>\r\nAs you can see, there's much more that goes into running a functional and successful Managed WordPress Hosting business than just helping customers install WordPress.\r\n<h3>A Brand New Front-End for Pagely 3, Too<\/h3>\r\nWe wanted a new UI that was light, responsive, and worked well with our new API service methodology (more on that next). Enter Bootstrap. Our CodeIgniter client apps served up the data, and Bootstrap made that data easy to interact with.\r\n\r\nHere's what our new dashboard looked like:\r\n\r\n<img class="aligncenter size-full wp-image-20214 lazy" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/06\/image7.jpg" alt="" width="956" height="724" \/>\r\n<h3>Our API Service Methodology<\/h3>\r\nWe wanted to make everything in Pagely a RESTful service; that was our methodology. So we built an API specifically for the installer and server\/system processes, another API for account\/user-related functions, and another specifically for job queuing, etc. This approach allowed us to:\r\n<ul>\r\n \t<li>Decouple code<\/li>\r\n \t<li>Maintain narrowly defined unit tests<\/li>\r\n \t<li>Craft lightweight REST client apps and UIs<\/li>\r\n \t<li>Document it and make it accessible to partners<\/li>\r\n<\/ul>\r\nImportantly, it allowed us to expose many of our core provisioning and account-managed API endpoints to authorized partners so they could re-sell Pagely managed WordPress on their site.\r\n\r\nAdditionally, it allowed more developer-savvy partners to generate reports and lists of their current customers, and manage accounts for those customers. It also let them manage their integration points with Pagely, such as defining which themes, plugins, or content would be preinstalled on their new customer sites.\r\n<h2>Pagely: A Proudly Bootstrapped Company<\/h2>\r\nIn 2010, a large and well-known hosting company approached us about acquiring Pagely. In 2011, the same thing happened again with another company. We also toyed with the idea of raising funds that year.\r\n\r\nAt the end of the day, we always came back to the same conclusion: we like what we do, we like doing it our way, and we like doing it on our terms.\r\n\r\nWe had a vision of the type of company we wanted Pagely to grow up to be, and that vision hasn't changed. We didn't want to maximize profits with gimmicks at the expense of customers, just to appease a board or make our earn-out. We didn't have a "win at all costs" mindset that pushed integrity and professionalism aside.\r\n\r\nOur vision was and still is, to be the best at what we do, provide a quality service, and treat our customers and employees how we wish to be treated -- with fairness and honesty.\r\n\r\nI believe these values are compatible with making a healthy profit, not exclusionary to it. Could we achieve this goal with outside capital? Sure. Are we going to waste time trying to convince a VC to play along? Probably not. Someday, perhaps. I am not anti-VC, but I am anti getting into bed with someone that may not share our values.\r\n<h2>In 2012, Pagely's Future Was Bright -- and Still Is<\/h2>\r\nFrom a failed concept in 2006 to the second go in 2009, after insane growth and success in 2010 and server madness in 2011, the future looked bright in 2012 -- and it only got better from there, as we now know.\r\n\r\nI hope you enjoyed this look back at Pagely's early years from 2006 to 2012. I tried not to get too technical or bore you with all the business details of our story. I hope you found some value in learning about our early system configuration and system design choices.\r\n\r\nWe are immensely proud of what we achieved, developing the first managed hosting service for WordPress. Today, we're built entirely on <a href="https:\/\/pagely.com\/wp-aws\/">Amazon Web Services<\/a> which helps to power our<a href="https:\/\/pagely.com\/blog\/optimizing-wordpress-for-speed\/"> blazing fast hosting solutions<\/a>.\r\n\r\nIn true Pagely fashion, we have no plans to slow down.