We’ve got some great updates to share since our last post about PHP Upgrades for the Pagely platform. We’ll share some information about how the recent upgrade from 7.4 to 8.0 went for sites using the “Stable” version preference in Atomic, as well as what we have planned for the November 28, 2022 full EOL of PHP 7.4. Stable: Moved from 7.4 to 8.0, planning to move to 8.1 in 2023. We transitioned our “Stable” PHP from 7.4 to 8.0 in August of 2022. Before doing so, we tested each site for compatibility. We version locked any apps that failed our checks so they’d remain on 7.4 for the time being. A few sites experienced more subtle failures when we rolled out the upgrade to 8.0 and it was trivial to switch those back to 7.4 while each site owner worked with our team to update their codebases. As of this writing, less than 6% of sites hosted on Pagely needed to be locked to 7.4 and each of the ones that are locked have a plan in place for remediation. Making this transition happen early granted our customers a healthy amount of time to sort any issues out while 7.4 is still receiving security updates. We will be upgrading “Stable” to PHP 8.1 in Q1 of 2023. The precise date of that is to be determined. The timing of that change will depend on getting all sites using “Stable” onto at least the 6.0.x branch of WordPress Core. All of our customers using “Latest” are already at that minimum WordPress version and we’re working on bringing the last few remaining apps up to par before we’d consider changing the PHP version for “Stable”. Sunset: Moving on from PHP 7.4 Pagely makes different selections available for PHP (“Latest”, “Stable”, and “Sunset”) that map to specific PHP versions throughout each version’s lifecycle. We change these over time in accordance with the PHP: Supported Versions Schedule, and while there are times where there is overlap of running the same version for “Stable” and “Sunset”, we try to follow the schedule published by PHP to make your version choices straightforward. Sunset is due for an upgrade on November 28, 2022 because security support ends for PHP 7.4 on that date. Currently, the Pagely team is conducting compatibility testing like we have done previously and will be reaching out to customers before November 28, 2022 to coordinate any sites needing to be version locked. After that is done, we will be updating “Sunset” to run on PHP 8.0, which will continue to receive security updates for one more year after its active support ends on November 26, 2022. While we do make exceptions in some rare cases to hold an app back on a PHP version after that version has reached end-of-life, we still work with each customer to establish a timeline for remediation; it is very important to get off of old versions that no longer receive security updates, not to mention the performance wins and new features you can take advantage of by being on the latest. Latest: Staying on 8.1 for now In our last post, we alluded to the possibility of introducing support for PHP 8.2, which is due to be released on November 24, 2022. Since the release is not officially out yet, and WordPress Core will have to catch up with the changes to become compatible, we are not planning to introduce it as a “Beta” selection right away. Given that the team’s focus will be on helping our customers upgrade from PHP 7.4 to 8.0, and that WordPress Core is still preparing for 8.2, there’s just not a good reason to add support for it at this time. We can add it quickly once it makes sense. Legacy Shared Customers Pagely has been providing enterprise-grade managed WordPress VPS hosting based on Amazon Web Services for about nine of the 14 years we have been in business. In that time, we have helped countless brands and companies scale and adapt to the ever-changing world of software and the cloud. Our Performance and Scale plans provide single-tenant hosting environments that deliver computing capabilities and a degree of flexibility that most other platforms, whether they’re based on multi-tenant or single-tenant architectures, can’t easily match. Up until about 2017, we were also offering shared hosting plans. We still support customers on our shared hosting platform and have kept that environment updated with the latest WordPress, operating systems, AWS EC2 instance types, and, of course, PHP versions. This time is no different; we’ll be updating our shared hosting clusters to PHP 8.0 once 7.4 hits full end-of-life. We will be testing each site for compatibility and reaching out to customers ahead of time if we determine they will have issues. Although the PHP version selector in Atomic is not yet available for sites on our shared hosting platform, we will be able to lock an app’s PHP version to 7.4 if it’s necessary for a short time. Bonus Round: What’s cookin’ at Pagely for WP 6.1? Now that we’ve got all that out of the way, I wanted to provide a glimpse into some of the cool things Pagely is working on with regards to WordPress 6.1, due to be released later today (November 1 2022). In partnership with Object Cache Pro’s (OCP) own Till Krüss, Pagely now supports the use of Relay with OCP. Relay is a drop-in replacement to PHPRedis, with a key differentiator being that it has a cache that is built directly into the PHP runtime environment. Early bench-marking shows that it outperforms a remote Redis server and reduces bandwidth, but what was more exciting to learn was that it even beats a locally installed Redis instance! Why is this relevant for WordPress 6.1? If you haven’t yet read the Performance Field Guide for WordPress 6.1, you totally should. There are some changes coming that will make more extensive use of caching to make things like WP_Query and the REST API perform better. If your WordPress application does not use an object cache, you won’t benefit as much from those changes. If you do use an Object Cache, you will see some great performance wins by upgrading to WordPress 6.1. Taking that a step further (after all, our motto is “Expect Extraordinary”), utilizing the Relay extension with OCP will net you the biggest performance gains. Pagely always wants to be at the forefront of performance when it comes to WordPress. We were the first to establish a partnership with Object Cache Pro and we were there to help provide feedback during the development of Relay, and we’re obviously going to be an early adopter of Relay. Starting today, you can request your site to use both OCP and Relay on Pagely, for absolutely no additional cost to you. Just reach out to our support team for enablement. We’ll have a more extensive article in the coming weeks that digs into the benefits of this new development, but we wanted to get this good news out to you today.
Fifteen years ago our company built and launched a website builder based on WordPress v1.x that allowed anyone to quickly launch a site with rudimentary managed services like automatic backups and upgrades. With only a few dozen paying customers and not knowing exactly what we had — it sat in limbo for a year or two. Twelve years ago our company went all in on launching what is now known as Managed WordPress when we introduced Page.ly (domain hacks were cool back then) to the world. Managed WordPress has now become a multi-billion dollar channel and Pagely is the recognized leader therein. Today Pagely serves hundreds of billions of monthly requests, from the most mission critical websites, owned by the world’s biggest and most recognizable brands. When your site outgrows every other hosting provider, or when your business actually matters, you then become a Pagely customer. Scale, Durability, and Legendary Support are our calling cards. After a total of 18.5yrs in business, we are proud to announce we are moving on to the nextphase of our journey: we have agreed to the sale of the company to GoDaddy. “But wait, Strebel you serious? GoDaddy!? What?” Crazy, I know. And… If you know Sally and me, you already know why we did it. TL:DR; To help more people. If you don’t know us, nice to meet you, and I’ll walk you through it briefly. We built a successful company that took the uncompromising position that employees and customers came first. This has allowed us to focus exclusively on the needs of those stakeholders. Never competing on price, only on quality of service. Creating a robust and performant hosting platform and industry leading NPS and CES scores for our efforts. Legendary Support Pagely has built a reputation on delivering exemplary customer service which is the envy of other hosting providers. Our customers have responded with gifting us an industry leading 80 NPS Score and 96 CES Score.(90 day scores) The Pagely Way NPS 80 CES 96 We did it our way, and It worked. It worked so well that one of the largest internet brands in the world, GoDaddy, wants us – to help them – to be more like us. They’ve put their cards, and cash, on the table and are serious about serving a wider segment of the market, with better quality products and top class service, to ultimately; help more people succeed. Sally would like to add: “Our beloved conference, Pressnomics, may look a little different going forward, and will remain a Pagely hosted event with the same mission as always: to elevate and connect business owners in the WordPress Ecosystem. I already have a theme in mind for the next one. Stay tuned.“ So what are our mission goals? We will be working closely with the amazing team of WooCommerce experts from SkyVerge (previous GoDaddy acquisition) on the GoDaddy commerce team to deploy a world-class WooCommerce SaaS aimed at powersellers. If you want all the sanitized corporate PR goodness here you go – Else let me just say, we’re coming in hot.Double down on everything you know and love about Pagely. Sally and I would not have done this deal without the confidence that Pagely will not just continue, but greatly expand, it’s presence as the Enterprise hosting leader in the WordPress Ecosystem. Back to our story… We did it our way. We put our employees and customers first, and for many of the early years took our share as founders last. This strategic M&A transaction has minted new millionaires not just named Josh and Sally. It has also set many others up for major long term financial success. Not a single one of them was an “investor”. We proved to ourselves that we could win the game by sticking to a simple set of values summed up as “Business is personal”. I can’t say it will be business as usual as we go forward from here. Why would it be? I hope we can do more of the things our customers love, and less of the things their customers don’t. This partnership with GoDaddy was entered into with our customers’ needs top of mind and you all had a primary virtual seat at the bargaining table. We will continue to deliver the world-class product and support you’ve consistently rewarded us praise for and is a key feature of this deal that GoDaddy will continue to support. Like in all plans, there may be a few hiccups along the way as we execute them, however you’ll always get the transparency and fairness from us when navigating through them, together. The Pagely team and product suite isn’t going anywhere, and each will continue to be supported by the core values and drive to service excellence that we have stood upon since our inception. Sally and I have always been and remain so incredibly grateful to be able to work in service to our team. Your concerted attention to excellence all these years and the joy and ease in which you have all set about making this dent in the universe together — to be a part of this team, has truly been one of the great honors of our life. Thank you. Our new partners’ stated mission is to support and serve the current and next generation of entrepreneurs and business owners. It’s very much in line with our own. As of today, we begin working together to do just that. Let’s. Fucking. Go. — Joshua Strebel– Co-Founder and former CEO of Pagely, Inc.
B A N A N A S Pretty much sums up the last year – It’s been bananas. Never ending Pandemic, New Brands, Growth, Working towards compliance, New Product Launches, and more. This September 2021 is a very special month for us. Pagely, and by extension the entire multi-billion dollar Managed WordPress Hosting channel, is 12yrs old! Quick Flashback: In Early 2009 I opened up my IDE and started looking at some code we wrote in 2006 for a website builder based on WordPress. I added a few features to it, picked a new leet domain name, and in September 2009 – Launched Page.ly – The world’s first Managed WordPress hosting company. All the WordPress hosting buzzwords you know and love: Automatic Backups Automatic Updates Blazingly Fast Secure like Fort Knox 1 Click Staging Caching All. Of. It. Started. Here. Yes of course it is true we did not actually create everything under the sun, however the early work we did in the space is the parent to every Managed WordPress product offering available, regardless of the company selling it. Except billing for Pageviews, eff that noise – we don’t want any part of that. Team Retreat in 2015 Always Forward As Pagely begins it’s 13th year we have a strong wind at our back once again. I’m sure in some companies, especially investor fueled ones, growth is always fast and up while profitability is tied up in ropes and cinder blocks, then thrown off the end of the pier. In our company we’ve had our periods of growth insanity and just normal one foot in front of the other measured progress to increased profitability and high NPS scores. 2018 through most of 2020 was a bit of an odd timeframe for us when looking back – we invested heavily into the development of NorthStack and gained deep technical learnings. These lessons were then applied to Pagely as the decision was made to pause the NorthStack product while we felt out how the world was going to react to a fast spreading novel Coronavirus. Team Retreat Early 2020 As we came up to a major revenue milestone in 2020 we turned our focus inward to reevaluate our processes and to create new ones, address team makeup, and revisited our mission and values. We took the time to prepare for what was coming and to lay the foundational groundwork for our future goals. Less manic startup energy – more “we’re a real business now” mentality. We hired into newly created roles in team management, finance, enterprise sales, and compliance. Sally and I handed off more and more of the day-to-day responsibilities to our skilled team so we could take stock of where we are, and where we needed to go. Then we all worked together to formulate the plan to get us there. Allison’s (SupportOps Manager) dogs: Winne and Lola (“Karen”). The last year has been all about executing on that plan. We added 30% to our headcount – while improving and expanding our benefit offerings. We’ve engaged the services of an auditing firm and will shortly achieve SOC 2 – Type 2 compliance certification. Our brand glow up – which is the culmination of months of work by our Dir of Marketing Dave Amirault, and the creative team at Struck – will be launching momentarily. We’ve delivered on many of the requested features to our Enterprise clientele such as Single Sign On (SSO) to our services, and expanded support models and enhanced SLA’s. Back of the napkin math tells me our employees significantly increased their usage of PTO – after much encouragement and prodding from myself and their team leads. We launched Mercury just a few weeks back, which is a major win for our bottom line and our customers’ site performance. 20-30% faster network speeds on every request at cheaper data rates. Truly a win-win. These and many more items that are part of our strategic plan have resulted in a steadily growing sales pipeline and a pronounced upward shift in our momentum heading into 2022. Did I mention we are hiring? Get your tech jobs here. Times have changed. The important stuff has not. Jeff Matson’s doggo – Henry 2021 was also an emotional roller-coaster as we all bared witness to the, at times, abject selfish nature of people — and — the grit, empathy, and kindness of others. Sally and I have personally seen all of this up close and personal this year, a story we may share at another time. Each day though we took heart that by and large, the world is good and things tend to work out in the end. Keep the good people in your life close, and hug your kids every day. It costs you nothing to be kind. We lean on our core values as we make decisions and plan for the future. We also relied on them heavily in the past as we navigated the ups and downs of the pandemic. Sally has always said that if we do the right thing, success will follow. Doing the right thing by the people in our lives, our companies, and our communities is typically a selfless act with no expectation of return. At times though, the universe does surprise you with a healthy payback of goodwill, tenfold. There are lot’s of new faces at Pagely, as we said goodbye to others. It seems everyone has collectively reevaluated how they wish to invest their work time. Many leaned into the stability of good careers, others felt it was time to explore new options. At each coming and going I’m thankful to see new faces embrace our vision and values and old friends take a little part of the Pagely magic with them as they move forward to a new adventure. We are just as committed today as we were yesterday, and every day prior to becoming the best version of Pagely we can be. Branding work in 2021 Looking forward is as exciting today as it has been at each one of our 11 prior birthdays. I want to personally thank the team here at Pagely, and all of our customers and the fans we have in the WordPress community for being part of our journey thus far. Happy Birthday to Us. This coming year is going be the most interesting chapter in our story yet. I guarantee it.
Malware is the bane of most site owners’ online journey. New threats emerge daily and a successful attack can bring your operation down by defacement, tanking your SEO, or harvesting your private data. Pagely has created a new malware file scanning tool under our PressARMOR™ security framework that is not only more capable than existing tools, but also faster. Malwatch Highlights 15% Better Detection 25% Faster Scan Time 14% Less CPU Usage Real Time Monitoring and API Reporting Engine Already deployed across the entire Pagely fleet. Existing malware scanning tools used across most web hosts are proven and effective – having many years of development and market use. While we were satisfied with the existing tools, we asked the simple question – how can we make it better? A typical one off website owner may not be as concerned with the performance of a scanning tool as long it works. As a web hosting service provider, Pagely requires a malware scanning solution which focuses on efficient resource usage, can be easily deployed and maintained platform wide, while being able to closely integrate with our other tools and platform. Most existing malware scanning solutions today do not place high emphasis on threat intelligence – they do a decent job of reporting a hit or quarantined file, yet the analytics and reporting leave much to be desired. Basic log files and email reports do not solve our complex needs and more robust reporting capabilities were necessary. Most existing solutions are heavily based on technologies such as ClamAV but our needs were for an in house solution that can be easily maintained and include the latest technology, while still offering the same or better feature set. Roscoe Skeens, a member of our Info-Sec team, took this question of scanning performance and threat intelligence to heart and began working on an answer last year. Introducing Malwatch Malwatch is a fully featured malware scanner designed for Linux based general purpose web server environments. It can scan both files and processes together with the inclusion of real time scanning capabilities. Malwatch is built upon the incredible Yara library, which is the same technology used by XProtect that comes included for macOS. Development started in January 2020 and within a few weeks we had a basic scan engine implementation working. It became clear by March that the concept was achievable and additional core requirements such as automated malware cleanup and an embedded database began to materialize. Real time file monitoring was added during the April sprints, which concluded the minimum core set of functions that were originally scoped. During testing we used large sets of malware samples to compare accuracy and Malwatch started to show higher detection rates than other solutions towards later builds, even though the same signature bases were used. We completed tens of thousands of test runs. See benchmarks below. Deployment to production environments was a very well planned and controlled process. Individual AWS regions were chosen, each with a week long trial run alongside Pagely’s previous malware scanning setup. Over the course of Q4 2020 Malwatch was deployed across the entire Pagely fleet. Only a couple of bugs were identified post rollout and each were fixed on the same day. Neither caused any serious problems and each could only be reproduced every thousand or so scan runs. Malwatch features an API driven reporting engine offering JSON based compatibility across our platform and tooling. In an upcoming release, customers will be able to see informative scanning reports and findings within our Atomic hosting dashboard, while our information security team can monitor trends, scope, and active threats in a purpose built threat intelligence dashboard. What is Malware? We’ve all heard about it or have been affected by malware. Malware is any software intentionally designed to steal information, gain access to, or cause damage to a system. Computer viruses, worms, Trojan horses, ransomware, spyware, Facebook, and adware are all forms of malware. Malware typically infects a WordPress site in 1 of 2 ways. The first being by a code vulnerability in a plugin or theme that has been exploited for nefarious means. The second being by a hacker (or automated program written by the hacker) using a stolen or brute forced password to gain access to a WordPress user account. With that access they typically upload other malware to perform some nefarious activity. Keeping your code updated and passwords rotated and strong are the single best lines of defense a user can take. What is Malware scanning? Tools like Malwatch, Maldet, and others are very much like the antivirus software running on your PC – except they tend to be focused on systems like web/cloud/file servers. They scan files or running processes and compare the contents to a list of known malware signatures (think fingerprints). When a suspected match is found the tools can be configured to send a notification, quarantine the file or process, and in some cases automatically clean/repair the file or process. Why do hosts like Pagely invest in and run Malware scanning? The most basic reason is because malware costs everyone time and money. Malware infections may not only cause harm to the site (and the site owner’s business) of the initial infection – but may also affect the underlying systems of the host by slowing down servers, infecting other sites, or harvesting data. In a nutshell it is in everyone’s interest to mitigate the risk of malware and therefore like at Pagely, malware scanning is typically a value add included with many hosting plans. Scanning Benchmarks during testing We started this project with a simple question – how can we make our malware scanning platform better? Which set Roscoe down a path that ultimately yielded a brand new tool all together. It was important for us to make sure the new Malwatch tool performed as good or better as the many capable and successful malware scanning tools in use today. Benchmarks have been conducted on idle Amazon Web Services C4 instances. Each benchmark category’s result is the average from three runs. Malwatch was tested first in each category. The benchmarks comprise of Malwatch, ClamAV and a web hosting related ClamAV frontend. Most established Linux based web hosts do not use ClamAV in isolation but rather a web hosting specific frontend which is specifically geared for the industry. The standalone ClamAV installation was specifically configured to be as optimal as possible to deliver best possible results. Throttling tools such as “nice”, “ionice” and “cpulimit” had all been disabled for the benchmarks. Other industry specific solutions such as Linux Malware Detect (Maldet) were also tested but with similar or worse results. Detection Rate Benchmark A third party malware zoo was used to compare against a large assortment of known and unknown malware samples. The same signature base was loaded for all three series of tests and the file count also verified. One possible reason for the lower than expected ClamAV result is the Yara signature set not being fully compatible, although there were a fair amount of Yara rules being matched. Scan Duration Benchmark 25% faster scanning time for 35,000 files. Process CPU Usage Benchmark 14% savings in CPU usage with Malwatch Process RSS Usage Benchmark Roughly the same memory footprint Roscoe’s thoughts on his choice of using Yara and Go The Go programming language offers extremely stable and well structured support for concurrency, which delivers orders of magnitude better performance when shifted from single threaded operation. The true power of what Yara can offer is attributable to further performance gains throughout each new build. It became logical to rely on Yara for more optimal algorithms such as Aho-Corasick instead of devising our own form of it. Although it has origins from the 1970s, the Aho-Corasick algorithm is still incredibly quick because it performs all matches in one pass. In Summary Malwatch is not a Pagely owned tool. Roscoe did much of the early development on his own time – and the later stages utilized company time with collaboration from other Pagely software and DevOps engineers. We agreed early on if anything came of the project we would work out a fair IP agreement for both parties. Therefore all the source code and IP (that which was owned by Pagely) has been assigned to Mr. Skeens in return for a perpetual use agreement/license with Pagely, Inc. Roscoe is considering the option of open sourcing his work and we fully intend to support him and Malwatch with further resources and support – least of which will be its continued development and testing inside our hosting platform. Pagely has been a market leader in Managed WordPress hosting for over a decade – we were first-to-market in the now multi-billion dollar channel we created after all. A core commitment to our customers has always been a focus on information security and a trouble free experience for hosting clients. Adding Malwatch to our PressARMOR™ risk mitigation framework allows Pagely to achieve greater detection accuracy with quicker completion times, while reducing resource usage on customer instances across the entire fleet. Well done Roscoe, well done indeed.
This title is intentionally clickbait, however let me share how we did take our annual company-wide downtime for Christmas and New Years‘ (and 4 days for Thanksgiving). In the web hosting industry, where 24/7/365 always-on is table stakes, we make it a point to all but lock the doors and power down the lights every year to relax and refresh. Allow me to provide a little context. Seasonal businesses like water parks or ski resorts are of course, seasonal. Most other companies have normal ‘business hours’. These types of companies have structured, repeatable time off, shared by everyone. However, modern consumers expect online businesses to provide service at all times which means multiple shifts around the clock. This holds true for a company like Pagely due to our responsibility as a backbone hosting provider to thousands of popular online businesses. Many of these online businesses also earn the bulk of their revenue around the holiday season. So how in the world do we manage to have light days and fully close around the holidays without causing disruption for our customers and mayhem to our bottom line? Stick to your priorities Sally and I have been in business together for nearly 18 years and fully embraced the “people matter” concept long ago. The people we work with/hire in our company remain the most important stakeholders. A highly successful and healthy company originates from a relaxed, happy, and engaged team. Traditionally the winter holidays provide a time for friends and families to come together. In our fast-paced society gathering together with friends and families becomes more and more difficult as the demands of commerce may allow for only a brief pause for activity. Ultimately, though, not a lot of critical business occurs between Mid-December and Early-January. When teams boast that they’re never taking a break and always on, we’re wary of this. Beware the #hustleporn. It seems ethically wrong for companies to take pride in having their employees wear a sacrifice badge for their health and family’s happiness. To live our values it is a priority of ours that our team can enjoy the holidays with their families and friends. We are unwavering in this. So then we have to account for the tradeoff. If the company is effectively closed for 2 weeks, who is responding and looking after the needs of the customers? Well, we are, of course, with ample planning and communication. Consider a science-backed approach In any growth business, there’s never a good time to power down the machine. But, science proves that taking time off increases productivity and improves physical and mental well-being. Overworking with no time off (especially in those important times, like the holidays) leads to stress. That stress then increases the production of our “stress hormone,” cortisol, which can lead to anxiety and depression when increased for prolonged periods of time. Taking time off literally renews and re-channels the brain for greater focus, happier home life, and a decrease in burnout. At Pagely we have generous individual PTO and actively encourage our team to use it – it’s more fun when everyone gets more PTO at the same time 😉 Fun fact- Did you know that LinkedIn closes the week of July 4th? While it’s not the classic winter holiday timing, they utilize another popular holiday to give their team some time to recharge. Communicate early and often Many parts of the world also celebrate some form of winter holiday and therefore we share a common context with most of our customers. This makes it easier to communicate our plans, and communication is the most important thing you can do. Let’s face it, it could be a bit rattling for your customer to hear you won’t be available when they may need you – unless there has been a dialog and planning beforehand. We start communicating with our customer base in October about our upcoming holiday hours and offer assistance to prepare – encouraging customers to engage with us now to prepare for later. We feature our closure dates on our newsletter and pretty much all other announcements up until the time we’re out. What’s more, is we take this to heart when it comes to our employees as well. We’re always over-communicating our plans, our schedule, our expectations. Make sure your customers are still covered Of course, lots of products and services are essential to business, but few more so than your website. What that means for most customers at Pagely is that they absolutely must know that their site stays up at all times. While on the surface we are completely closed for 2 weeks – let’s be real though – we do of course maintain team on-call rotations and full monitoring of all services. I would be remiss not to mention that we plan for this. Did I mention that we plan for this? You might be thinking “but this doesn’t give your employees the full time off that you suggested above, they still have to work, Josh!” and while you’re sort of right, this is far from a gotcha moment. We’ve done this enough to know that support load will decrease – so we can also significantly reduce shift coverage – leaving just a minimally staffed on-call rotation needed. Our SupportOps (Support and DevOps) team is in complete control of what the on-call schedule looks like during our break, and how they want to handle and assign shift coverage. That means well before the holiday break is even approaching, we’ve worked together to put together a reduced schedule that we’re all happy with. We try to reduce the number of on-call shifts over the break to ~3 per employee, and ultimately they can select the shifts that work best for them. We’re never asking anyone to sit around and wait for tickets to come in during this time, but instead, just make sure their laptop is close by if an alert or page comes in. Our customers’ sites remain ready for traffic fluctuations due to intelligent planning, testing, and our team’s expertise. We thoughtfully prepare for our time off by evaluating client needs and reducing any potential for service disruption. The Proof is in the pudding So how does it work in practice? Here is the data. We cut actual SupportOps hours worked by 75% for 2 weeks and still responsibly addressed all our customer support obligations. Support load was down by approx 59% during this time as clearly we were not the only ones on vacation. Dec 11th-22nd (Full Ops) Dec 23rd – Jan 03 (Holiday Break) # Tickets x 41% of x Resolved in one-touch 38.4% 35.6% Reopened tickets 19.6% 22.7% AVG First Reply time 13mins 6mins AVG First Resolution time 36mins 42mins AVG Full Resolution time 6h30m 7h24m Internal SLA achievement 95.1% 92% That is not a typo – our First Reply time actually got better while on break. Our customer effort scores also tell the story, and we’re happy to boast them here. Pagely’s customer effort score as seen from our CX partner, Delighted. You see those numbers unwavering from the 75-100 range? That’s real data, taken from our recent holiday break. It’s a thing of beauty if you ask me. The ability to reduce human resources over the winter holidays while maintaining or increasing CES and NPS scores provides a testament to living by company values rather than just saying them. We honor a work-life balance. Our team approves. Be remote-first, so you can hire around the world From a customer perspective, this checks the box on 24/7 support, but it also makes it easier for us to make sure we’re able to fill our on call schedule during holiday breaks. If we all worked in one place, who would want to cover that shift during Christmas dinner? Like most things we do at Pagely, even this blog post was touched by many employees, across many time zones. We’re all contributing when we can, which makes the whole engine run smoothly. The remote-first approach allows our global workforce flexibility to take advantage of local holidays or banking days, knowing that we all value and respect teamwork. We encourage our teammates outside of the US to take time off for their national holidays with the confidence that we’ll cover for each other. Thanksgiving? Those dates are different in Canada and the U.S., folks! Be decent and look out for one another Perhaps the most important point is this. Be decent to people. Remember that each person on the team has family, friends, and deserves downtime away from work. We’re lucky at Pagely in this regard as our culture and size foster a close knit and caring atmosphere built on respect and trust. Take this one step further to say that we also understand our customers are human. They deserve to watch their kids rip open presents without another care in the world, especially not wondering if their site is still being looked after by a hosting provider. To us, it’s one of the greatest holiday gifts around to be able to have the best of both; vacation and happy customers. Whether it was to share updates from the Annual Pagely Christmas Hammening (another blog post is needed to explain that one), a coveted delivery from Santa, or to share a recipe for a New Year’s Eve cocktail the team was still connecting over the holiday break. It speaks to the culture we’ve created here at Pagely. Not a culture of overworked anxiety, but a culture where respect and friendship reign at the end of the day. As a founder, I’ll take it. The time off lets us recharge, reflect, and reconnect with our families and friends. 2021 came roaring in delivering one of our best sales booking months on record and we’re off and running implementing our strategic goals for the year. Let’s go.
TL;DR In the midst of an outage at our IaaS provider (AWS) – I reflect on what a crazy year it has been and how fortunate we are to go through it together. A fitting end to 2020 Sometimes the world throws something at you that, despite your best preparation and skills training, you get hit square in the face and fall on your ass. – 2020 in a nutshell. In what is now month 9 or 10 (depending on who you are asking) of a global pandemic, we’ve been doing more non-traditional Zoom meetings as much of the world has; cocktail hours, games of Among Us, and the tournament-style Dad Joke contest that our SupportOps Manager orchestrated last month for the team. Zoom has become the substitute for so much. Breathe A recent Friday morning was our first yoga-over-zoom session. Not everyone could make it, however, those that did followed along for around an hour as the instructor demonstrated various stretching and breathing exercises. It was a touch of team building, with a dose of self care, and should have been a relaxing ride into the weekend. Everyone on the planet has had to evaluate and examine old notions and learn new coping strategies this year as we wrestle with the metric ton of chaos around us. Chaos Nearly the exact moment the yoga session was ending, PagerDuty goes bananas. Alerts bubble into Slack and all the calm in the room evaporates as the team springs into action. An Aurora RDS database cluster has failed, and failed hard. Even the Amazon cloud is going to fail sometimes – and when it does, most of the world feels it. This failure was isolated and seemed to only be affecting us, and even then, just a single cluster of many that we manage. To the best of our abilities, we’ve architected around the inevitable failure; nothing is ever 100% and we account for that in our stack design. We’ve made decisions that result in a higher cost, but yield automated recovery and multiple redundancies to shelter the assets of our customers. Our automated recovery systems: Failed Our manual recovery attempts: Failed AWS’s automated recovery routines: Failed .. and the clock is ticking along. To make a long story and a 3-hour outage event short: It was a failure/bug in the AWS software that runs the AWS Aurora database platform that had the cluster stuck in a repeating loop of: segfault -> recovery attempt -> segfault. All our training and our disaster recovery gamedays prepared us – because sometimes even the world’s largest cloud provider has an unpatched bug in their codebase – we started executing our plan B’s, C’s, and D’s. See the status thread here: https://status.pagely.com/incidents/22ggyk6m3vg1 Thankfully the AWS engineers were able to recover the cluster and get everything back online. Sometimes, managed database services fail. Despite your best preparation and skills training, you get knocked around a bit – but your team is there with you – working through the problem in real time – our Friday in a nutshell Did I mention we did yoga earlier that day? People Matter Sally and I are in the enviable position, and thankfully have been for sometime now – where we are most certainly NOT the most important people in our company. So while this was all going down we chimed in a bit here or there, but mostly we just watched our #warroom slack channel and marveled at the expertise and professionalism on display. There was no single hero of the day – there was only a team of peers dynamically working together as a single unit – and it was glorious to behold. I’ll save you the rest of the corporate platitudes and thought leadership BS and just say that who you work with makes all the difference in the end. In a global context this year could have gone any number of ways – sadly it went about as poorly as imaginable. In the center of the bad and the occasional bright spots of good – were people. 2020 has taught me that the people we choose to lead us, the people we choose to follow, the people we choose as business partners, the people we surround ourselves with, and the people we invest our time in are the difference – for better or worse. I am humbled and grateful that our people here at Pagely are ones I am proud and thankful to work with on a daily basis, and I look forward to seeing what opportunities 2021 will bring us. I wish all of you a safe and happy holiday season and a bright beginning to the New Year ahead. — Joshua Strebel
Since this is the internet – and the rules of the internet clearly state everyone gets an opinion, I’d like to share one of mine around website hosting billing plans. Quick backstory: 10+ years ago when we launched Pagely we did so with a simple line on our pricing page denoting a rough estimate of the expected capabilities of that plan ie: Plan – 1 was suitable for ~1 million pageviews. Along came the next several providers who did something similar with one important difference. They actually attempted to measure and cap pageviews per hosting plan, bracketing their plans by this new billing metric. In my opinion Pageviews used as a billing item is a predatory and anti-consumer practice and you should be very wary of working with any company that applies this #successtax to your monthly bill. Definition of anti-consumer : not favorable to consumers: improperly favoring the interests of businesses over the interests of consumers Hi, I’m Joshua Strebel, Co-founder and CEO of Pagely – A leading Managed WordPress hosting company – Thank you for attending my TED Talk. What are you buying when you are buying “hosting”? To host a WordPress site you need a few key components. A server (a computer) connected to the internet with software installed to process requests and responses for your application. Storage / Disk space attached to that webserver to save your files to. Data Transfer / Bandwidth. This is the pipe the information flows through. That’s basically it. Hosting providers typically lease/sell you packaged fragments of these resources for a monthly fee. Plan A, Plan B, Plan C. etc. Of course there are other items that may be line-itemed such as included support levels, CDN GB’s per month, managed services, etc. Plan A has X amount of consumables for Z price. It’s all fairly straightforward as most consumers understand what a Gigabyte of Disk space is and can at least grasp that more CPU/RAM offered should equate to more potential performance. “Pageviews” does not fit this model well – as the definition of a pageview is amorphous and subject to exploitation. Oh, and spoiler alert, PHP workers is not a valid billing metric for WordPress hosts either. What does an automobile lease have to do with hosting plans? Pageview limits on hosting plans are akin to annual mileage limits on auto leases. It’s a cap on the use of an asset you already purchased. In an automobile lease context a mileage cap at least has some merit as being a form of controlling the depreciation of the vehicle – you are essentially financing the deprecation of the automobile asset with a lease – and the lease company expects to sell that car (New retail value – Depreciation) when you return it. If the depreciation is too high, they lose money on that transaction as they have to sell it for less than they calculated. Your hosting plan is not a depreciating asset though – the hosting company is going to sell the same resources to the next customer when you are done for the same or likely higher fee. Therefore in my humble opinion: Pageviews are just an arbitrary anti-consumer fee – a penalty tax for using the service you already paid for. A Pageview is (depending on who you ask) a wrapper around these items: A measurable amount of Data Transfer in and out A measurable amount of CPU resources to process the request and render the response A measurable amount of Disk and Database activity Are you not already paying for these items as part of your hosting plan? Hint: Yes you are. But wait, there’s more – and my colleague will dig into these more in a future post. This pageview billing model is so poorly defined by the hosts that use it – it is ripe for abuse. It’s a scheme to generate revenue for the hosting company and unfairly penalizes the consumer. Hint: You already “paid” for the sum of the parts of a “pageview”. No two pages are the same. A cached page even with a few images can be served a million times a month with ease, and yet a badly coded membership-site page may tax the hardware it runs on each time it loads. They have very different cost profiles to the host – yet both are treated equally under this model. If you invested the time to optimize your site, get it caching well and then blow it up with viral traffic.. That is a GOOD day for you and costs your host pennies of the monthly fee you are already paying them – yet when you get the overage bill for exceeding your pageview cap at the end of the month, are you going to enjoy that tax on your success? If you want to keep paying twice for the same resources you are welcome to. I simply do not think that is fair. Our friends down in Austin have made millions on charging their customers overage fees for exceeding their monthly pageview cap – even to the point having to publicly respond to criticism – only to keep the practice in place. Reminds me of airline baggage fees and fuel surcharges. and An “online payment convenience fee” when they only accept payments online. and JetPack being “free”. Happy WordPress’ing – Joshua Strebel
PHP workers are getting a bad rap lately in the WordPress hosting world. Most commonly, they’re being cited as a scapegoat for a hard upsell by the host. Let’s dig in a bit deeper and discover the truth behind PHP workers and how they apply to hosting WordPress sites. Table of Contents What is a PHP Worker? Why Would I Need to Care About PHP Workers? Why Would My Site “Run Out of PHP Workers”? Wouldn’t More PHP Workers Fix the Problem? How Many PHP Workers Do I Need? How to “Tune” PHP Workers Here’s the Real Question That You Should Be Asking Don’t Believe Us? Want Proof? There you are, just minding your own business – literally minding your online business – when your workflow is suddenly interrupted with a prolonged loading page. You say to yourself, “That’s weird. It seemed to be working fine just a moment ago”, so you tap the refresh button. After a moment, you see a white screen with a 50x error printed across the top. You want to be sure that it wasn’t just a freak accident, so you give that refresh button one last tap and the WordPress admin page you were working on loads right up. It’s like nothing ever happened. Since the incident, a million thoughts of panic and discomfort are running through your mind. “Was this just a random issue? Should I worry about this? How often does this happen? Do my customers see this too?” Unfortunately, there’s no magical catch-all answer. This “blip” or “timeout” could be attributed to any number of causes throughout your hosting stack. Within this article, we are focusing on the specific and casually offered, “you need more PHP workers” reframe that far too many WordPress hosting support desks seem to respond with. What is a PHP Worker? A single-core processor on a timeline. 2 PHP workers drop tasks into the processing queue and are handled in a fairly consistent fashion. Memory usage stays somewhat constant as CPU usage modulates with workloads. In a basic sense, a PHP worker is a background computing process that runs PHP code. It hangs out on the server, waits to be told what to do, does it (hopefully in a timely fashion), returns the response, then goes back to twiddling its thumbs until another task comes in. When they pick up a new task, they’ll use whatever CPU cycles and RAM they have available to get the job done. To ensure that they always have resources available for when the next job comes in, PHP workers also reserve some resources to stay warm after they finish. Of course, you wouldn’t want to have a bunch of PHP workers sitting around and eating up additional resources just to sit there idle. In addition to being statically defined by always keeping the same number of PHP workers ready, they can also be dynamic. By utilizing dynamic PHP worker counts, they’re able to grow or shrink as necessary. In a WordPress context, PHP workers are kind of dumb. Since WordPress runs as a single-threaded application, a single PHP worker handles the entirety of the request. Because of this, a typical WordPress request looks something like the following: A request comes into the web server and passes it off to PHP. A PHP worker within the worker pool starts processing the code. If your code requires information from the database, the PHP worker then passes a query over to the database server, then waits to get the results back. Once the worker receives what it needs from the database, it then performs further processing before finishing and passes the completed work back over to the webserver. Why Would I Need to Care About PHP Workers? Most of the time, you don’t need to know or even care about how many PHP workers your hosting account has, much less how they are allocated – until you run out. When high traffic to your site, poor performing code, or a combination of the two uses up all your available PHP workers, it bottlenecks the chain. Once you run out, requests get turned away or queued until one of your PHP workers finishes a task and can take on another one. Why Would My Site “Run Out of PHP Workers”? Wouldn’t More PHP Workers Fix the Problem? As we stated above, a PHP worker stays “blocked” while active. During that time, it’s not able to perform any additional tasks until the current task has finished. The benefit of having more PHP workers is that it may allow the site to handle more tasks simultaneously. Typically, the number of PHP workers is not as critical as the type of workloads that those workers are performing. While handling more tasks simultaneously may help with making sure that every task gets finished, excessive PHP workers can also cause individual tasks to take longer. As each task takes longer to finish, this means that when resources are exhausted, it can take quite a while for spare PHP workers to become available. Typically, the number of PHP workers is not as critical as the type of workloads that those workers are performing An excellent way to think of your worker queue is like a list of tasks. If you have a few tasks that you can handle at once, you can get them all finished relatively quickly and become ready for more tasks. But if you take on too many tasks at once, you might find yourself overextended, take longer to complete each task, and see your backlog grow exponentially. Long/Slow Running Tasks Clog Up the PHP Worker Queue Code performance is the most significant factor in regards to PHP Worker capacity. Let’s take a look at a very simple instruction in PHP: print(“This is a PHP function”); This instruction alone occurs almost instantaneously. Because it happens so quickly, it consumes 1 worker for only a brief nanosecond. On the other extreme, let’s look at a complex instruction that could occur when a customer searches for a product on an eCommerce site. If the customer was searching for car parts that are compatible with a particular product, your code might handle it like this: Give me all products from my database that match the keyword “spare part”, has a price between $5 and $15, and is compatible with SKU “4232”. Now take these records and process them. For each one, get the paths for up to 3 corresponding image thumbnails. Before making the items available, make a call to my 3rd-party inventory management system API and check to see how many are available. Once you have all of the products and inventory counts, start building the web page with product reviews, social media posts, and the product images for each product. Print that content to the browser along with my header, footer, and sidebar. Relatively speaking, this process keeps 1 worker occupied for a very long time. Each task waits for its part of the instructions to finish before it can move on to the next. Combine this with that page builder plugin that you love so much to generate the 3MBs of HTML, and you’ll be left with a reasonably substantial PHP process to chew through. Now, if your database is slow for any reason, it’s going to take a few hundred milliseconds longer to return its data, keeping that PHP worker active while waiting. Let’s say that you’re hosting your product inventory management system at a different cloud provider – the PHP worker needs to wait for that API communication and transaction to take place. You get the idea. The worker has to finish a task before it can take on any more tasks. Most of the time, it’s a non-issue. It does its processing, your page renders in 300-600ms, and you move on with your life. 2 PHP workers drop tasks into the CPU timeline. They’re processed consistently at first, but then 1 task “waits” as the other worker tasks continue moving. This demonstrates how a worker can become occupied or “stuck” while the transaction takes place, unable to do anything else until the task completes. Juggling Too Many Tasks At Once On your typical WordPress site, the whole process works fine a million times a day. Except when it doesn’t. Let’s say that your marketing team just sent out a wildly successful newsletter blast. It drove an influx of traffic to your site, and the crew is popping champagne in the break room. But on your server, it’s a different story entirely. You’re getting the same types of requests, but they have now multiplied and are happening all at once. From there, your PHP workers get bottlenecked as they cannot clear their tasks fast enough. That’s when your site slows to a crawl. A Note on Request Queuing Most modern hosting stacks use PHP-FPM to manage the number of PHP workers, allowing tasks to queue up gracefully while waiting for CPU resources to become available. If you are running Apache and mod_php, request queuing won’t happen gracefully, and any new request is unceremoniously dumped. Queuing is an excellent solution to handling short bursts of traffic, but has a downside that becomes apparent when your sustained traffic occurs at a higher level than you can process. When every request spends time in the queue, all you are doing is adding additional time to the response. If the queue size is large enough, you can even get into a scenario where each request is waiting for greater than 30 seconds before work even starts. At this point, you aren’t completing any requests in a useful amount of time. You would have been better off serving errors to half of the traffic and content to the other, rather than make everyone wait half a minute or more. 4 Workers drop tasks into the CPU timeline, which are processed in a fairly consistent fashion at first, but then begin to queue up waiting for available CPU. In summary, the PHP-FPM request queue lets you use the optimal number of PHP workers while still handling traffic bursts. However, it still needs to be capped at a size that allows it to process the entire queue in a short amount of time. Otherwise, you could end up in a runaway delay situation. Exhaustion of Server Resources As we’ve previously mentioned, each PHP Worker consumes a bit of RAM and CPU cycles. Even if you have 50 PHP workers to handle your workloads, your run-of-the-mill WordPress hosting plan likely does not have enough resources allocated to run all of those workers efficiently. One cannot merely add more PHP workers in a vacuum. Increasing capacity to serve additional website requests means increasing CPU and RAM (server/container size) in proportion to the PHP workers, based on what your workloads demand. 4 Workers drop tasks into the CPU timeline. As the volume of tasks increases and all available memory is occupied, tasks are unceremoniously killed off to make room for the tasks coming in behind it. This is a demonstration of the Out of Memory (OOM) task killer which, when active, causes all sorts of unpredictable performance issues. The 4 variables of CPU, memory, PHP worker count, and workload (code efficiency) all need to be in harmony when it comes to right-sizing a hosting stack. It’s worth mentioning again that code efficiency is the most important. Increasing the other 3 may just let you do more of the slow and inefficient tasks (concurrency) with no effect on how fast those tasks complete (performance). Cache is King Caching, of course, helps alleviate many of the bottlenecks described above. Caching at the database layer with native MySQL query caches (going away in MySQL 8), leveraging the WP Transients API, and/or a Redis Object Cache, saves the PHP worker from having to communicate as often with the database and wait for a response. Caching further up the stack in the webserver prevents the PHP worker from even being asked to do anything. Unfortunately, it’s not always possible due to session cookies or dynamic requests. Caching responses from 3rd party APIs, like the inventory management system that we described earlier, reduces that “waiting” time as well. The more efficiently you can cache and still meet your business goals for the website, the less PHP work needs to be done, which means an overall smaller demand on server resources. Newer PHP Versions are Faster Than Older Versions There are several benchmarks you can view online, and they all say the same thing: PHP 5 is faster than 4, 7 is faster than 5, and 7.3 is faster yet again than 7.2. You get the idea. You may not have any control over what version of PHP your host provides, but if you do, always opt for the latest version. The speed (and security) gains of newer PHP versions are real and quantifiable. How Many PHP Workers Do I Need? There is no universal answer to this question as each WordPress site and workload is different. Generally speaking, you want to tune the number of PHP workers to consistently use 80-100% of your available CPU capacity. Complex workloads may only allow for 2 PHP workers before consuming all available CPU. In contrast, efficient and optimized workloads may allow for 4, 6, or 8 workers per core with identical server specs. Too many workers for the available CPU simply makes everything slow down as they get queued up, and the CPU spends much of its time switching between tasks, rather than getting work done. Too few PHP workers for the available CPU wastes resources, since some percentage of your CPU remains idle, rather than getting work done. A good optimization of workers to CPU cores. 4 PHP workers leverage 2 CPU cores and have ample memory to process each task efficiently with a little (but not too much) buffer before maxing out. How to “Tune” PHP Workers Tuning PHP workers is a fairly straightforward process as long as you follow a few basic rules: You want to run as few workers as possible. You should have a hard limit on the number of PHP workers based on the memory used by each worker, and the amount of RAM on your server – this is very site-specific, as each website may have a different usage profile. Once your CPU is at 100% utilization, adding more workers simply makes each task slower. If your worker CPU usage is low, but your requests are still slow, your bottleneck is in something PHP is making a request to (Database/Cache/API). Increasing the number of simultaneous requests to that component might make it slower, so you have to monitor it. An excellent question to consider is this: why are you trying to tune your PHP workers? Is it maximum concurrency or maximum performance? At Pagely, we always try to understand the customer’s business goals when recommending which “hosting plan” to use. From there, Pagely tunes each plan to the specific customer’s needs. Dozens of small sites have a very different workload footprint than 1 large site on the same spec hardware. Tuning PHP Workers for Many Low Traffic Sites on the Same Server With lots of sites, you have two main worries: memory overhead and noisy neighbors (this can include just your own sites on the same VPS). Memory overhead is mostly static, based on the average memory usage of each site. For simple brochure-style sites, you might plan for 128-256MB of RAM for each site (plus some fixed OS overhead, depending on your stack). At your average cloud provider, you are going to be looking at instances with a higher memory-to-core-count ratio on the smallest size. As you scale, you’ll then switch to a lower memory-to-core-count ratio. As for PHP workers, you are going to want to use dynamic worker limits, generally with a minimum of 1 PHP worker to reduce latency and setting a maximum that only uses 25% or 50% of the server CPU. Setting these parameters lets a couple of sites burst at simultaneously, without causing performance issues on the other sites. Each site gets access to the CPU, but no one site can consume all of it at once. Setups like this tend to have a ton of unpredictability, so you are better off focusing on stability in worst-case scenarios instead of maximum performance and efficiency for any single site. Tuning PHP Workers for a Single High-Traffic Site With a single site, you can match the hardware and worker counts to get the most bang for your buck. You will almost always want to use cloud instances that are optimized for computing power (number and speed of CPU cores). From there, you should use either a fixed number of PHP workers or a dynamic configuration with a high minimum number of workers. If your database is running on another server, a good starting point is to take the number of CPU cores and multiply it by 2. Increase workers-to-CPU-cores when: You are making a lot of database or API queries. Your average response time is minimal (< 100ms). Decrease the workers-to-CPU-cores ratio when: Your codebase has low efficiency You aren’t making many database or API queries You are generating very large responses Just Throw More Hardware At It This is our least favorite solution – and one that we only recommend after we’ve gone through everything else. Sometimes it just has to work, right now, and refactoring poor performing code is time-consuming and not always feasible. Throwing hardware at the problem usually works, but with a major downside – it gets really expensive, really fast. You can typically increase concurrency and handle more tasks, but those tasks will never get any faster until the code efficiency is addressed. As our CTO says, “it just allows you to do more of the slow things”. Here’s the Real Question That You Should Be Asking We get it – several of the hosting companies have trained the consumer base to be concerned about the “number of PHP workers” and to think that number has some magical effect on how their WordPress site performs. We also understand that many of these same WordPress hosting companies have successfully brainwashed everyone to concern themselves with “number of Pageviews” as well. (Pageviews as a bogus billing metric is a topic for another blog post entirely.) These are both the wrong questions to ask when shopping for a scalable and reputable host for your WordPress website. The question you should be asking is simple: Does this host have the skill and knowledge to configure my plan specifically to my needs so that I can get the most bang for my buck (performance to value)? If they keep pushing plan upgrades and telling you that “you need more PHP workers” without any background analysis offered, you already have the answer you need. Don’t Believe Us? Want Proof? We’ve run a full analysis of the impact of PHP workers, including all of the source code for our tests. If you want to take a deeper dive into our data, a full write-up is available within our PHP worker benchmarking and analysis article. Happy WordPress’ing.
It’s the first day of April – 2020 Big Sigh Be stay safe out there, please.
Ten years ago this month, we launched Pagely and kicked off what has grown into the $2-3 Billion dollar channel known commonly as Managed WordPress Hosting. At the time, people questioned the need for the services they now take for granted, and which are increasingly becoming commoditized. Over the last decade, the wider WordPress ecosystem has clearly benefited from faster and more secure websites, better deployment workflows, and knowledgeable, WordPress-specific technical support. I’d wager to say the wider hosting market, in general, has also taken notice and adapted to serve a more discerning clientele that has come to expect more than Level 1 call center upsells when interacting with their host. It’s been an exciting and, at times, terrifying journey for Sally and I as we’ve put our efforts towards building a product and then building a company. We’ve become parents during this time and watched as our employees started or expanded their own families. We’ve seen competitors enter, grow, and dominate wide segments of the market. We’ve also stayed true to our simple philosophy of “business is personal” and have endeavored to interact with every employee and every customer with integrity and empathy. Thank you to all our customers past and present for joining us on this journey. As the Managed WordPress Hosting channel expanded, and the service offerings coalesced around similar feature sets and positioning, we remained laser-focused on moving up the value stack. Our approach was driven in dual parts by instinct and survival. For the type of company we wanted to be a part of, one that put our employees and customers first, we had to seek out and serve the top-tier customer base that would support and value that ethos. It’s not a stretch to say we, a revenue-funded company, were also being squeezed by the venture-funded companies with massive war chests and the overseas players that enjoyed lower expenses on labor. If a company does not adapt, it does not live. I would be remiss to not recognize WP Engine, SiteGround, Pantheon, GoDaddy, and the rest of the now saturated mid-market and B2C WordPress hosting field that have played a significant role in this channel Pagely created. They most definitely have done more than we ever could alone to expand and broaden the landscape… as they continue to bludgeon each other for mass-market supremacy. It’s near impossible to forecast what the next 10 years may bring. At Pagely, we are investing heavily into a new product we feel is the logical next iteration of managed application hosting, NorthStack. As technology changes at a quickened pace inline with the evolving tastes of consumers, we are exploring additional application ecosystems beyond WordPress such as Node.js, Laravel, and Gatsby, while leveraging and building the next generation hosting infrastructure to support it. Hi, I’m Joshua Strebel, CEO and Co-founder of Pagely, a 10yr old profitable “startup” and the innovator of Managed WordPress Hosting. Thank you for attending my TED Talk.