[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, testing secure WordPress hosting, does the marketing match the reality?

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today we have Maciek Palmowski. Maciek is based in Poland and works at Patchstack, one of the companies in the WordPress ecosystem dedicated specifically to security. At Patchstack, Maciek collaborates with other security professionals on industry reports, bug bounty programmes, and solutions for agencies, product owners, and hosting companies aiming to secure their client sites.

I met up with Maciek at WordCamp Europe, and we discussed his presentation there. It examined the claims of secure hosting made by many WordPress hosting providers. He describes how Patchstack set out to test these claims with real world penetration testing, using 30 known plugin vulnerabilities across multiple hosts. Employing standardised methodologies and validating their results independently.

The findings are sobering. The majority of WordPress specific attacks still get through, and there’s a significant gap between the marketing hype and real protection.

The conversation starts with Maciek’s background, and how his journey in the WordPress security space led to a focus on the promises made by hosts.

From there, the discussion gets into the research approach, the selection of well-known vulnerabilities, consistent testing across different hosting environments, and the surprising result that even hosts with identical security tooling produce drastically different outcomes, showing it’s not just about the tools you use, but how you use them.

We talk about the Swiss cheese model of security, every layer will have holes, so you need multiple overlapping defences, and honest communication from hosts about their limitations.

We also explored whether an industry-wide standard, or badge, for secure hosting is feasible or even desirable, given how easy it is for strong marketing claims to outpace reality.

AI also enters the conversation, increasing both the speed and sophistication of attacks, and making patching, and processes, even more important, especially as the volume of vulnerabilities continues to rise and the time to exploitation drops.

If you’re interested in understanding what secure hosting really means, how to ask intelligent questions of providers, and the realities of WordPress security in 2026, this episode is for you.

If you’d like to find out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Maciek Palmowski.

[00:03:56] Maciek Palmowski: I am joined on the podcast by Maciek Palmowski. Hello Maciek.

Perfect. You did great.

[00:04:01] Nathan Wrigley: For some reason, your name has got into my head. A lot of the people that I interview, I struggle with their name, and I continue to struggle, but for some reason, I established many years ago that was how to say your name. And I think I’ve done it correctly ever since then.

[00:04:16] Maciek Palmowski: Yes you did. You’re almost having the typical Polish accent, so you’re doing great.

[00:04:21] Nathan Wrigley: So we are at WordCamp Europe, which is in Krakow, or Krakow, I don’t know how.

[00:04:26] Maciek Palmowski: Krakow.

[00:04:27] Nathan Wrigley: Thank you, that was good. And the reason Maciek is correcting my pronunciation is because Maciek is actually from Poland, which I suppose means that this is a bit of a, well, it’s like a home game to you.

[00:04:37] Maciek Palmowski: In a way so, but it’s also like a bit of a shame because I do like travelling when WordCamp Europe’s are happening. And, you know, just hopping on the train and going to Krakow, it was like a, I mean it’s cool because, yeah, the venue’s amazing, everything is great, but still I’m staying home, so yeah.

[00:04:53] Nathan Wrigley: Yeah, mixed feelings. So Maciek has done, or is going to do a presentation at WordCamp EU. Have you done it yet?

[00:05:02] Maciek Palmowski: I will do it tomorrow.

[00:05:04] Nathan Wrigley: Okay. And are you all set, are you one of these like really prepared people that has all the slides done, or are you last minute?

[00:05:11] Maciek Palmowski: Everything is ready. I already did one version of it at the Checkout Summit in Palermo, so.

[00:05:17] Nathan Wrigley: Oh I see. So you’ve had a sort of dry run of elsewhere.

[00:05:19] Maciek Palmowski: Of course.

[00:05:20] Nathan Wrigley: Excellent. So the presentation, which is going to be the focus of today’s conversation, is called Testing the promise, does secure hosting deliver? And I may as well read the blurb because it was a reasonably short one.

So it says, secure hosting, in quotes, is everywhere in WordPress. What does it actually protect against? We put this claim to the test with real penetration testing. 30 known vulnerabilities, multiple hosting providers, standardised methodology, validated by independent observers. The findings reveal a critical gap between marketing and reality. WordPress specific attacks succeed most of the time. That’s quite an alarming sentence. This talk shares the complete results and explains why generic security fails.

So, we’ll get into that in a moment. But as with all people, when I’m talking to them about security, I guess it’s good to establish who you are, and what your credentials are and what you’ve done, and how is it that you get to talk about security with authority. So over to you really, a little moment to give us your bio and tell us about you.

[00:06:20] Maciek Palmowski: Okay. So I work at Patchstack, and Patchstack is one of those few companies in WordPress space that are doing a lot in terms of security. We are constantly running this bug bounty for the whole ecosystem. We have quite a few solutions for both clients and hosting companies, and I work there right now. My role is, if I remember, the Growth Team Engineer, something like this.

But yeah, I do spend a lot of time working with other security people. So when we are working on all the reports, when we are checking the data, I’m also part of those teams that are working on it. So yeah, I think I know a thing or two about what is happening behind the scenes when it comes to WordPress security.

[00:07:02] Nathan Wrigley: Yeah, thank you. Always good to get that established though, right at the outset.

Patchstack is a company which is not a host though, I suppose that’s important to mention at the beginning. It’s a company which is in the security space, very much in the WordPress space, but perhaps more broad than WordPress, I’m not sure. But not a hosting company.

But obviously your presentation focuses its aim on hosting, I guess because that’s one of the places where the claim about security is most often made. You know, you’ll go to a, the landing page of hosting Company X, and you’ll see somewhere fairly near the top, secure hosting, or something along those lines. And you’ve decided to examine that in fine detail and look at these 30 vulnerabilities.

I guess really just tell us about this test and what it is that you decided to do and some of the items that came out of that.

[00:07:50] Maciek Palmowski: Okay, so maybe let’s start with how it even started, right? Because there was a trigger. At some point we published one report about the state of WordPress security. We tweeted about this. We got the response from none other than Matt Mullenweg, who kind of asked a very interesting question, but isn’t hosting companies taking care of this already?

And this was, kind of at this moment when we were, we thought that we know the answer that, no they aren’t. But to be honest, we didn’t have any broader proof about this.

We knew how it’s working at some hosting companies, but we could say that it was more of an anecdotal evidence that we had. So this was kind of the trigger that made us, okay, let’s check this. But not with one partner or two partners, but with more hosting companies.

So we did this research twice. First we just did kind of a beta run because we weren’t sure about the result and, is it even a good idea to go deeper inside of it? And during our first run, we were already very surprised because like the methodology was very simple. We just installed vulnerable plugins and we checked if we would be able to use the vulnerability. Because if the hosting is claiming that, we got your back, we are making your website secure, we have this and that, this means that they should protect against it. So it was as simple as that.

And when we were doing our first test, we were quite surprised because we saw, if I remember, that 80% of the attacks went through. 80% of the attacks. So our first reaction was, okay, we are doing something wrong. Okay, this was only few hosting companies, less plugins, but still the result were so surprising for us because we thought that, okay, that the problem exists, but it’s not that big of a problem. But it was.

So that’s why we did the second test. And this is about which the, my talk will be mostly when we tested more hosting companies, more plugins. And we saw that the problem still exists.

Of course it was, in some cases 70 few percent. So still, it’s a huge problem, especially if we are talking about some companies that are literally saying, you don’t have to install anything additional when it comes to security on your website. We got your back. They don’t. We found a lot of interesting things, but still the problem exists.

[00:10:21] Nathan Wrigley: So just deep diving into that a little bit, when tests like this are done, there’s obviously, the claim might be levelled, you know, obviously Patchstack would, this kind of maybe benefits Patchstack, if you know what I mean.

So let’s just sort of clear up what the test involved. So presumably the plugins that you chose are ones where it’s publicly known that there’s a vulnerability in this component or this particular file or what have you. So is that the case? This is stuff that, longstanding understanding that there’s a problem here.

[00:10:51] Maciek Palmowski: Yes. We only use the plugins that we had all the proof of concepts. So we know how have the vulnerability happened, what was the attack vector? They were all reported through our bug bounty programme, because that’s why we had the proof of concept. Yeah, and that’s it.

It was, like I said, it was as simple as that. We had a really broad mix of all the plugins. How many? It was 30 something of those plugins, if I remember. Different ones. Some were connected with WooCommerce. So, like a very broad selection of them. Different vulnerability types. So we try to mix it up as much as possible.

[00:11:27] Nathan Wrigley: Was the situation for each hosting company the same though? In other words, was the things that you did in one hosting environment the exact same as you did in another hosting environment? No. You mixed that up a bit as well.

[00:11:38] Maciek Palmowski: I mean we used all the same plugins, like the methodology was always the same. But we got totally different results. Even if, and this was one of the most interesting findings, because very often hostings will put a logo of some company that takes care of security. For example, say, Cloudflare. And despite using the same stack for security, they got different results.

[00:12:02] Nathan Wrigley: Interesting.

[00:12:03] Maciek Palmowski: So it turns out, in many cases, it’s not about the tools that you are using, it’s how you are using them, which was very interesting. And we did everything. We tried to enable every feature, every security features on those hosting, to kind of give them a chance to kind of make sure that they are defending the most as they can.

And the result in most cases was very simple. They were doing quite well with the generic ones like uploads, patch reversal, things like this, which are very generic in PHP. But with those WordPress specific attacks, they just failed miserably.

[00:12:44] Nathan Wrigley: That’s so interesting. The word secure hosting, which you’ll see all over the place, it feels a bit like using the word healthy on food. There’s no real definition of what healthy is. You know, a company selling chocolate could probably pretend that it’s healthy compared to something else.

[00:13:04] Maciek Palmowski: Like here, healthy chocolate is exactly, like in some cases secure hosting.

[00:13:07] Nathan Wrigley: Right. So what do you take from this then? I mean basically, is your survey saying that whenever you see the word secure hosting, be sceptical?

[00:13:16] Maciek Palmowski: Yes.

[00:13:16] Nathan Wrigley: Okay. As simple as that.

[00:13:18] Maciek Palmowski: It’s as simple as that. Because one of the things that we were always promoting, security is not a plugin, it’s not a one button thing. Security is a process. It’s layers.

And that’s kind of why we, especially after this report starting kind of using the term, Swiss cheese layer model. Because every layer will fail in some way. That’s also why you still need all the security solutions that hosting provides, because they do have a lot of interesting solutions against those generic attacks.

Because they’re doing really great when it comes to those generic ones. And that’s great because some of the attacks will be already dealt with. So whatever passes to the second layer, it has less work to do because a lot of it was already stopped at the first layer. The second layer should be something more WordPress specific that understand what is installed. And with this it can catch also a lot of it.

But still, you have to be prepared that, because again, this layer also isn’t perfect. Because there are zero days vulnerabilities, there are custom code, there are a lot of things that can happen, that your website will be hacked. I mean, weak password. Simple as that. That’s why you also need to have a layer, which will be more of what to do if everything else fails. Because you do need to know that you have to inform your clients, all the GDPR related things. How to kind of, I don’t know, use the backups.

In short you need to have procedures. You have to be prepared before the attack happens. Because let’s be honest, asking some lawyers about, what should we send to our clients? The moment when, well, the milk is already spilled. It’s like the worst moment to think about it. Especially that, hey, your website was just hacked. It’s not just a technical problem, it’s also a business problem. Again, with those GDPRs and everything.

So yeah, the more layers, the better. You still need to remember, every layer can fail in some place. That’s why the more, the better.

[00:15:29] Nathan Wrigley: Would you like to see a standard industry-wide definition of something like a badge or, I don’t know, let’s say for example, that you put the word secure hosting on your website, that has to actually stand for something.

Because obviously coming from the background that you do with a broad oversight on what that is, you have a vast amount of data at your disposal. You can see all of this kind of stuff. But every company can make the claim that our food is healthy, our hosting is secure. But I don’t know, in the model that we’ve got where any company can put anything they like on a website, I don’t really know how you do that, but some sort of accreditation or something. I don’t know.

[00:16:08] Maciek Palmowski: Honestly, it’s really difficult because as I said before, a lot of companies using the same tools were failing in different ways. So that’s a problem. On the other hand, like sometimes the, those stupid things like weak passwords. And it doesn’t matter that you had a, let’s call it a certified secure hosting, you still failed because your password was weak, you know? So, also certificates like this can backfire because some people might think I have a secure hosting, I don’t have to worry about things. And then you have 10 admin accounts for everyone.

[00:16:43] Nathan Wrigley: Is there is there something, some mark of that description that you, personally, that you go looking for though? Is there some credentialing system which you think actually does carry some weight? So for example, I don’t know, like the insurance space or the accountancy space or something like that. You have to have that accreditation in order to do business. Is there something like that? Is there a mark which hosting companies can apply for which you could have some confidence in it?

[00:17:13] Maciek Palmowski: Okay. So for sure one of those things would be, and I don’t want to say it as an advertisement, but it is a thing that you see that the hosting is thinking a bit better about security, kind of looking if they are a Patchstack partner. Because this kind of automatically means that they do have this WordPress, the security WordPress layer. So that’s already a good sign.

So yeah, I would start with this. I think that’s kind of one of the simplest ways, but again, Patchstack isn’t the only solution that does it. So looking for partners of such companies might be the best way to start because having those Patchstack aware security solutions built in, into the hosting is a really good sign.

[00:18:05] Nathan Wrigley: Yeah, okay. Now, the inevitable conversation in the year 2026 is AI. It doesn’t matter which area of WordPress you’re talking about. AI manages to get in somewhere. I am presuming that the landscape in terms of security only got more complicated because of AI. Because I’m imagining that attacks that needed to be conceived by a human can now be conceived in a fraction of the time by an AI agent. But not just one, maybe a dozen or a thousand or whatever it may be.

Let’s just talk about that for a moment. It feels almost as if AI and security are like, that’s a real systemic problem for the future of the entire industry. Because these things can happen so fast, a plugin vulnerability is discovered by an AI agent. It then discovers the attack surface, implements the attack all in a matter of seconds, possibly. What’s the position? Like, how do we stay calm basically in the year 2026?

[00:19:09] Maciek Palmowski: So the problem already existed around a year ago, because a year ago when we did our State of WordPress Security Report, we already saw that vulnerabilities are being used after around five hours after kind of being published. So five hours. That’s the first thing, because we still have a lot of people that say, yeah, just update your WordPress weekly and you’re good to go. No, you’re not. Looking at this number, you have five hours.

[00:19:39] Nathan Wrigley: Okay. Let’s just parse that at the moment. So the vulnerability is published. So there’s a whole thing there, like the vulnerability may well have been discovered prior to being published, so that’s a whole other thing.

[00:19:52] Maciek Palmowski: So first the vulnerability is discovered. Then at least how it works on, with our bug bounty. We inform the vendor they have, let’s say around a month to fix it. When they fix it, we publish everything and, yeah.

[00:20:09] Nathan Wrigley: Okay, so from the moment you publish, you can then detect that that is being leveraged within a space of five hours.

[00:20:17] Maciek Palmowski: Yes.

[00:20:17] Nathan Wrigley: Okay, that’s really interesting.

[00:20:19] Maciek Palmowski: But there is a problem. There is a really big problem. So if the vendor doesn’t respond, we still publish it.

[00:20:26] Nathan Wrigley: How long do you give them? Is it like.

[00:20:27] Maciek Palmowski: It is the one month.

[00:20:28] Nathan Wrigley: Okay, thirty days.

[00:20:30] Maciek Palmowski: Of course, if they reach out that there is some problem, they need like extra days. But in most cases, we’re talking about the vendors that just don’t respond at all. We publish it anyway.

But the problem is that, from all the vulnerabilities that were discovered last year, 50% weren’t patched at the moment of publishing about it. 50%.

[00:20:50] Nathan Wrigley: So half of the plugins where there was a known vulnerability, the vendor had been informed, they’d had this 30 day window. Half of them made no amendment to their code.

[00:21:01] Maciek Palmowski: Exactly.

[00:21:02] Nathan Wrigley: Okay. Wow, okay.

[00:21:03] Maciek Palmowski: Again, going back to this classical, yeah, just update your WordPress regularly. No.

[00:21:08] Nathan Wrigley: No, that’s a really different surface, isn’t it?

[00:21:11] Maciek Palmowski: It doesn’t work on so many levels. Because not only the problem is with the fact that, still the famous five hours, which also, it’s five hours now. It was much longer a few years ago. On the other hand, yeah, most of those, I mean around half of it aren’t patched, so the attacks will happen quicker than it get patched. So yeah, there is a lot of problems like this. And also the problem with security is that it’s really difficult to sell.

[00:21:39] Nathan Wrigley: It’s like insurance, isn’t it?

[00:21:40] Maciek Palmowski: Yeah. But insurance, okay, you see your car, your house, it’s real. It’s real, you kind of see it. The only category of websites that it’s much easier to kind of explain is e-commerce.

[00:21:54] Nathan Wrigley: Yes. You can feel the tightening on your wallet.

[00:21:56] Maciek Palmowski: They literally see the money. They can kind of really, okay, one hour of my website not working equals this and this Złotys or Euros or whatever. So that’s easier to explain. But for most people, yeah, security, meh.

[00:22:11] Nathan Wrigley: Yeah. That’s really interesting. So you mentioned, about this survey, you mentioned that fully 80% of your penetration testing resulted in something. What were the sort of, the high level items? Apart from that 80% figure. What were some of the other, because you said there were a few interesting things that dropped out of it. Can you mention anything else?

[00:22:31] Maciek Palmowski: So like I said, one of the things was that we learned that, despite using the same tools, we got different results. That was also a surprise for us.

[00:22:39] Nathan Wrigley: So let’s just figure that out. So at hosting company A, we’ve got a WordPress website with the same collection of plugins in. Hosting company B, exactly the same as far as you can make it the same, but things are different.

[00:22:52] Maciek Palmowski: No, no, they are, for example, they’re using for security the same tools.

[00:22:56] Nathan Wrigley: Right, okay.

[00:22:57] Maciek Palmowski: So in theory, if they’re using the same tools, we should have exactly the same results.

[00:23:03] Nathan Wrigley: So does that then point to a different set of configurations on the backend, or is it more curious than that? You just don’t quite know what’s going on.

[00:23:12] Maciek Palmowski: I mean because it’s not something that they will tell us. But yeah, in most cases, it’s all about configuration because the fact that you’re using a tool, it’s also important how you use a tool.

Also, with security is very often about, is something easy to use or is something secure? And kind of finding the balance. So some of the companies probably had a bit more aggressive configuration, which is better from the security point of view, but probably more often result in some annoying side effects for the user.

Also what, this was one of the most interesting things, but also what was very interesting because we contacted every company afterwards and we informed them that we did the test. Here are the results, what went through, what was blocked. And some of the companies did an amazing job of fixing whatever they could. On the other hand, we saw that some of the companies, because we did some extra tests later just to check what they did with our report, did nothing.

That’s one of the things about security in general, not about the hosting, about even having vulnerability in your plugin. That’s normal that we make mistakes. We’re humans, right? So that’s normal. What’s important is how we deal with them. If you have a problem and you fix it as quickly as possible, as good as possible, that’s great because you learn from your mistakes, you fix it, and you move on. Perfect. Good job. Now you are in a much better position than before. But if you get this, you look at it and you say, ah, this is fine, that’s the worst behaviour from the security point of view that you can have.

[00:24:57] Nathan Wrigley: I’m going to ask you not to name names here, but were some of the companies familiar to us?

[00:25:05] Maciek Palmowski: For sure, because we did test the biggest ones. But there is a reason why we didn’t want to name them, and it wasn’t about that we were afraid that I know someone will get mad or whatever. It was more about this weird side effect that could happen.

Some users would think, my hosting isn’t on this list, so probably I’m secure. Probably you’re not, you just weren’t in the test. Because we also did some site checks and everything. And we saw that a lot of those problems happen at most of the hosting companies. And like I said, the more important part was how did they reacted after getting the report. Like I said, it was a more common problem that we even thought.

[00:25:43] Nathan Wrigley: Do you, obviously, you know, caveat all of this with the fact that you work for Patchstack and what have you, do you see it even as the role of a hosting company to have any position on security publicly? Or would you prefer them not to make grand claims about things that you believe they can’t necessarily substantiate?

I don’t really know where I’m going with that question, but I’m just wondering if there’s just a sense that the language that’s being used is too strong. You know, secure hosting implies we’ve got all the padlocks, and the padlocks are there and you’ve got nothing to worry about. You’ve found a different picture. So I’m just wondering whether or not you would just prefer that the hosting companies stop talking about this altogether.

[00:26:27] Maciek Palmowski: I do think that’s, one of the biggest problem here is about the claims, the bold claims, the whole marketing around it. Sometimes even you can find documentation of some of them that, yeah, you don’t need to install any third party tool because we got you covered. We checked it, no they didn’t. So that’s kind of the problem.

It’s really more about the, how they market it. If they would say, okay, so we have a really performant hosting that does this, this and this. When it comes to security, kind of do it yourself. I mean we are providing this layer, but the rest is up to you. And that’s okay. That’s an honest claim. We are not doing everything for you. We are doing this part, but this is up to you. This would be much better.

I know that from the marketing point of view, it doesn’t sound as good as, we got all the security that you can imagine, don’t have to worry about this. Because that’s kind of the thing that very often managed hosts trying to sell, that you don’t have to worry about things. You just have to focus on whatever you have, writing content, selling stuff. If you have a e-commerce, whatever, that’s it. That’s kind of the only thing you should think of. Not about performance, because we got your back. Not about security, again, we got your back. And if you are paying for a managed hosting and suddenly they would start having like this different way of messaging to, it’s not that obvious that we have your back in everything. That would be very difficult for them.

So now it’s kind of the problem that, because everyone is kind of using this messaging, everyone else also has to. And also if we think about how a lot of those algorithms, look like that algorithms love bold claims. They want something white or black, not grey. And the truth is, most of the things we are talking about, it doesn’t matter, security, SEO performance, it’s everything in the grey zone. That’s why a lot of developers can end their talk with, yeah, it depends. There is no right or wrong. It depends because there are so many things you have to think about.

I could say that, and this is my kind of thing that, most of the websites that people have should be static. They don’t need even WordPress at all. This is a horrible claim if you’re a manager of a WordPress hosting, right? So that’s the thing. But it all depends on so many things, but yeah, the messaging is important.

[00:29:08] Nathan Wrigley: Yeah, if you were, on a personal level, if you were going out there looking and let’s say, if you can somehow put your job hat to one side, what would be the kind of things that you would be looking for? What questions would you be asking related to security if you were to be going to these companies?

From everything that you said, obviously it’s not black, it’s not white, it’s definitely grey. So every setup has some way of being vulnerable. But what are the kind of intelligent questions that you would be bringing to hosts to get some reassurance that at least they appear to know what they’re doing, even if they can’t make the claim that they’re a hundred percent cast iron, water tight? What might be some intelligent questions to start asking?

[00:29:49] Maciek Palmowski: One of the best questions you can ask is just, is there any solution in your security stack that is WordPress aware? Not the general one. Because if they only start talking about some web firewall, things like this, it’s already kind of a red flag. Because this is, overall, if we’re talking about firewalls, that’s not the correct layer about which, this is the generic one.

So this is the main question. How do you take care of WordPress specific attacks? Simple question. And if they will start responding, yeah, that we have this web application firewall that, in most cases this will be a sign that, no, we are not talking about the correct layer. That’s not it. It’s probably not aware about what is happening in WordPress.

[00:30:40] Nathan Wrigley: Okay. So given that this is a WordPress podcast, and we are at a WordPress event, that would be the beginning of your questioning is demonstrate that something in your stack is specific to WordPress.

[00:30:52] Maciek Palmowski: Exactly.

[00:30:53] Nathan Wrigley: Okay. And beyond that, is there any questions that, so let’s imagine that they come back with, yes, we have something specific, it’s WordPress. What would be sort of sensible follow up questions?

[00:31:00] Maciek Palmowski: I mean you can kind of start off about, okay, what exactly you are using? Because there is a limited amount of tools that are really WordPress aware. So if they will answer with kind of a product name, that’s kind of the easy way that then you can check it on your own. But that’s kind of the thing. Is it WordPress aware?

[00:31:19] Nathan Wrigley: Does it worry you in some way that there’s this perception out there that WordPress is insecure? You know, if you ask a thousand people, you’d maybe get 800 saying, oh WordPress, you know, we’re not touching that with a barge pole.

Do you worry that content like this, that you are putting out, that that might fuel that fire? Does it concern you in any way that it might lean into the argument that, I don’t know, somebody can link to that blog post from a rival CMS, or a SaaS platform, which does something similar to WordPress? Where do you sit on that?

[00:31:51] Maciek Palmowski: That’s a really difficult question. And this is one of the questions that when I talk on non WordPress events, I love to ask people. Is WordPress secure? And in most cases, I see that most of the room is, yes, it’s unsecure for sure. And I’m like, no, that’s not true. WordPress is secure. Every year there is just a few minor vulnerabilities in Core. That’s it. The problem is, of course, that WordPress on its own lacks some functionality. That’s why we install plugins.

And here we enter another problem because, okay, every year we have like thousands of those vulnerabilities in general in plugins. On the other hand, we have thousands of plugins. So kind of statistics will always look bad. But that’s why every time when you want to select a new plugin, you need to do some research. Yeah, I know it’s boring and everything but, hey, now we have AI, you can do it much quicker. It can help you a lot.

But looking at all those databases, for example, we have one database, WPScan has. There are those databases of WordPress vulnerabilities that occur to every plugin. And you can see, is the plugin you’re interested in had a lot of vulnerabilities? On the other hand, how it kind of looked historically. It’s not just about the number of them. In general, it requires some research.

And yeah, if we are just like looking at this, and this kind of vibe that right now we have that we are just about really bold opinions stated quickly that will fit one TikTok, yeah, WordPress is in a horrible position because, let’s be honest, it’s like, if you have, I’m not sure how many seconds does a TikTok movie has?

[00:33:39] Nathan Wrigley: I think 30.

[00:33:40] Maciek Palmowski: Okay, let’s say 30. So it will sound much better that you will say, yeah, WordPress is unsecure, which is not entirely true because it depends again. One of the most boring, especially again for those algorithms and everything, it’s a grey zone.

Because we are collaborating with a lot of companies that are making plugins, and we see how their security flow looks like. How they are dealing with vulnerabilies that are discovered. And honestly, I’m amazed how well some of those companies are doing it. They are very serious about it. They understand how important it is. For them it’s something very important.

[00:34:22] Nathan Wrigley: I suppose WordPress is a victim of its own success in that sense. And it would be a bit like, I guess a good analogy might be if you’ve got a car manufacturer and they produce a thousand cars a year and you compare them to Ford who make, let’s say, I don’t know, 20 million a year. And the question is, well, whose cars break down more often?

[00:34:41] Maciek Palmowski: Yeah. Do we look at the percentage of the number?

[00:34:44] Nathan Wrigley: Right. And if you say, well, 400,000 Fords broke down last year, and one of these other manufacturer, you can immediately see why there’s a problem there. And that I think is the landscape in which WordPress is often painted. The reason there’s lots of publications like yours bringing out WordPress information is because it’s the most popular thing. It makes sense to write about the most popular thing and to try to find the vulnerabilities and disclose them in a sensible way. So I don’t know what we do with that. It is just the way it is.

[00:35:15] Maciek Palmowski: I would also say there is one more interesting aspect because WordPress is considered unsecure because of the plugins. But what’s funny, for example, Elementor is also considered unsecure because there are plugins for Elementor. This is a very weird moment when the thing that brought WordPress to its bigger success, security wise, is its biggest problem right now.

Because WordPress did a lot of, I mean it was always great to, being as it’s kind of, let’s call it entry level CMS. For many people, it was also the way how they began the adventure with PHP development because it was so easy. Now we kind of have the, all the consequences of being that easy.

[00:36:06] Nathan Wrigley: Yeah, in a sense, this is going to sound ridiculous, we should be glad that there’s people talking about WordPress vulnerabilities, because it means the project is successful. And it also means that it’s, there’s an industry of WordPress security solutions, and there are people who take this very seriously and dedicate their lives to it. And you may not find that in some of these other ones, you know, some of the smaller CMSs and things like that.

I think we’ve probably hit about the sweet spot for the amount of time. But Maciek, I don’t know if there was anything in that report that you have got lined up in your presentation that I never got to. If there was a particular thread that you wanted to pull. If there is, go for it.

[00:36:46] Maciek Palmowski: No, I think we covered all the important things. And as you kind of said, this AI aspect, this will change so many things.

[00:36:55] Nathan Wrigley: Yeah, we’ll come back in two years and this conversation will be a very different thing.

[00:36:57] Maciek Palmowski: Oh, I think even in few months which will be very interesting. Yeah, so this aspect, it’s really very surprising. And I think that everyone who is right now kind of giving somewhere a talk about AI and security is in a very difficult spot because.

[00:37:14] Nathan Wrigley: Yeah, your content is going to look stale quickly.

[00:37:16] Maciek Palmowski: Yeah because you know it’s like, but a week ago everything changed. Yeah, I have to rewrite everything.

[00:37:20] Nathan Wrigley: Speaking of which, by the time that this goes out, hopefully you have managed to give out your presentation at WordCamp Europe. I will link to it and anything else that we’ve mentioned today in the WP Tavern post. So go and check that out. But I will specifically link to the wordpress.tv version of your presentation, which no doubt will have been created by then. So Maciek, thank you for chatting to me today. Good luck. I hope presentation goes well.

[00:37:43] Maciek Palmowski: Thank you. Thank you so much. Yes. I might need a bit because, you know, it’s WordCamp Europe. It’s a big conference.

[00:37:49] Nathan Wrigley: It is, yeah. Good luck. I hope that you manage to stay calm.

[00:37:52] Maciek Palmowski: Thank you.

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, building trust and collaboration in the hosting industry with the Secure Hosting Alliance.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you, and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today, we have David Snead. David has been involved in the hosting industry since 1999, starting out as legal counsel for one of the earliest shared hosting companies, and going on to work with over 50 others. He helped found the i2Coalition, serve as in-house counsel for cPanel and WebPros, and now leads the Secure Hosting Alliance.

If you’re listening to this podcast, I’m sure that many of you will have worked closely with hosting companies. Perhaps you run an agency, or business, that depends on the reliability, ethics, and security of hosting providers. David is here to talk about cross-industry collaboration in the hosting world, specifically around improving security, professionalism, and communication between hosts.

The conversation focused on why, and how, the Internet Infrastructure Forum, or IIF, is building a framework for real-time intelligence sharing and abuse reporting, aiming to help the entire ecosystem detect and prevent attacks faster than adversaries can adapt.

David talks about the challenges hosting companies face, especially smaller ones, in keeping up with security, and how this evolving project hopes to ease this by sharing actionable, non-proprietary abuse information across registrars, hosting providers, DNS services, and more.

He discusses the growth of both the Secure Hosting Alliance and the IIF, the business case for collaboration, and the nuances of legal and technical information sharing across borders.

If you’re in hosting, run a web agency, or just want to know how the backbone of the web is working to stay more secure and connected, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so, without further delay, I bring you David Snead.

I am joined on the podcast by David Snead. Hello David.

[00:03:20] David Snead: Hello.

[00:03:21] Nathan Wrigley: Very nice to have you with us. David’s got a really interesting background, and a really interesting, I’m going to use the word project. I don’t know if that’s the right word. It feels like it’s got more solidity and it’s got a lot more history than that. It’s something which is, I think going, but we’ll find out a little bit more about it. It’s all about the hosting industry and trying to get hosts to, I guess communicate with each other in ways going forwards.

[00:03:44] David Snead: That is a part of it. There are really two goals and one is to level up the ethics and professionalism in the hosting industry. And the second is to facilitate more comradery and interaction among hosts. Something that folks felt occurred in the early 2000s, and with all the consolidation that occurred went away. And so that’s something that we’re also trying to facilitate.

[00:04:16] Nathan Wrigley: Okay. So given that we’re going to be talking about hosting, I guess it’s a good idea to paint your credentials and find out a little bit more about you. So a short opportunity to just tell us a little about you and your background in WordPress and hosting specifically, I suppose.

[00:04:29] David Snead: Sure. So I have been working in the hosting industry since 1999. As I often say, I was working in the hosting industry when hosting was cool. It is not so cool anymore. In fact most people don’t really pay attention to it.

You know, and I started as a lawyer for a hosting company, and I was in-house counsel for a company that actually owned a hosting company and was one of the earliest hosting companies that specialised in shared hosting. And so I was their general counsel. And for some reason it stuck, and I’ve just kind of turned it into a career.

So after that I had a private practise as a lawyer and I worked with probably 50 different hosting companies, mostly writing policies that nobody ever reads, which makes me super fun at parties.

And then from there, my friend Christian Dawson and I formed the i2Coalition as a response to some legislation in the US that would’ve been kind of the death nail for internet providers. So we started the i2Coalition. I then went in-house for cPanel and worked at cPanel and WebPros for 10 years, and then started the Secure Hosting Alliance.

[00:05:52] Nathan Wrigley: Okay. So you’ve got all all the history. That’s pretty good. You know, if we’re going to talk about hosting.

[00:05:57] David Snead: All the hosting history in one person. That’s kind of a very scary idea, no?

[00:06:02] Nathan Wrigley: But that’s excellent. So do you still offer counsel? Is that still, so you haven’t sort of sidestepped and do half of the week on a sort of more technical basis? It’s still the legal side that you’re involved in.

[00:06:13] David Snead: I do. Right now I’m doing mostly M&A work for, it’s weird. So I don’t know if anybody has ever said this to you before, but web hosting is kind of like the Hotel California. It’s like, once you start in the web hosting industry, you never leave. And so I have all these clients from 15 years ago who are now running like little baby hosts, and they’re talking to bigger hosts and they want to get acquired. So I’m doing some of that now. I am not writing any of the policies that nobody ever reads because that was just, I did that for too long.

[00:06:51] Nathan Wrigley: There were too many moments parties.

[00:06:53] David Snead: Yes, exactly. Yeah.

[00:06:55] Nathan Wrigley: Okay, so I’m going to read into the record the title and the blurb that went with the presentation that you are doing or done.

[00:07:02] David Snead: I did it yesterday.

[00:07:03] Nathan Wrigley: Okay, we’ll get into that in a moment. So the title is coordinating the fight, cross industry collaboration, and the blurb goes as follows. WordPress hosting threats cross company lines. When one provider falls victim, the entire ecosystem suffers. This session explores how the Internet Infrastructure Forum, or IFF, enables hosting providers, registrars and registries to coordinate abuse response through real time intelligence sharing. Learn how operational collaboration helps responsible operators detect and stop attacks faster than adversaries can adapt. And why working together produces results no single provider could achieve alone.

When I read that, immediately was, yeah, that’s a really sensible idea. Why are we separately, as hosting companies, I say we, I mean the hosting companies. Why are they all trying to do the same work over and over again, separately? When presumably this aspect of the work, the security bit is something they all have in common.

[00:08:05] David Snead: Right? So that’s the fundamental question, right? So the IIF is a voluntary organisation that is made up of everyone in the infrastructure stack. So from registrars, registries, DNS providers, hosting providers, cloud providers, everyone in the stack. So it is facilitated by the Internet and Jurisdiction Foundation. They’re based in Paris, and they’re the actually the secretariat for it.

And what it’s designed to do is create a common way for everyone who’s in the infrastructure stack to share information about abuse and abuse issues. And it’s one of the fundamental problems that you referred to is everybody is operating in a silo, right? And that’s mostly because that’s the way the internet is architected, right?

So the internet is architected, so it’s distributed, right? Registrars and registries basically do their own thing with domain names. They might have a small hosting component or maybe a cloud component, but by and large, all they do is domain names.

Hosting providers probably resell domain names, but they’re not part of that industry. And so how do they all coordinate? And that’s what the IIF is trying to facilitate, is more information sharing among the participants.

[00:09:39] Nathan Wrigley: Well I imagine some of the hosting companies are probably fairly good. You know, they’ve got a giant customer base. Let’s imagine hosting company X over there, they’ve got millions of customers. They’ve got a huge budget that they can put over to, let’s say, security things. Well that’s all well and good, brilliant. But then there are other companies who are much scrappier. You know, they maybe have only a few thousand customers. And so their budget for the exact same work is going to be reduced.

How will this work? Is it going to be like a subscription service basically? Will you have a membership, which is in some way equal to the number of clients that you’ve got? Will there be some expectation that, okay, we’ll look at your revenue, your membership will be equivalent to a percentage of your revenue? How will that all work?

[00:10:20] David Snead: We don’t know. This is a very early stage project. Right now we are in a prototype phase where we have just figured out what information folks should submit to the secretariat.

So the way it works is, you submit the information that you collect for a particular abuse issue to the secretariat, who then enriches it with all the other information that’s been submitted and sends it to the right person.

So a great example is, let’s say a registrar reported a phishing domain. They turn off the phishing domain and they have maybe a timestamp, an IP address where it was submitted from. They submit that to the secretariat, who then finds the hosting company who is providing the services for the hosting and says, this came in about this particular site. Can you take action on that? So that’s the way it works.

Right now it’s very early stage. It’s in the first phase of a test, and we’re going to look at whether the way we’ve architected it, or the way the group has architected it, actually makes sense.

[00:11:39] Nathan Wrigley: Is this going to be then a sort of slow on ramp whereby you bring a few companies in at the beginning, hopefully. And then one or two more and iron out the wrinkles, and then some more and some more? Because I imagine, if you just threw the switch, everybody’s in, a lot could go wrong at that point. And I’m guessing there’s going to be more of a slow on ramp.

[00:12:00] David Snead: So you’ve pointed out my particular frustration with the IIF, and the reason that the secretariat is moving slowly, right? So fortunately, or unfortunately, based on my cultural background, I’m just sitting here going, this needs to move faster. We need to have everybody involved, we need to have all the hosts involved, we need to have all the registrars and registries. And other folks who are a little bit more skilled in this type of work say, no, we need to figure out what we’re doing and that requires a small number of people.

The phase that we’re in right now is looking for more folks who are interested in sitting at the table and being part of the discussion. Particularly in the hosting industry and in the web design and marketing industry. Those are folks who don’t generally participate in these kind of industry led collaboration exercises. And that’s the reason that I’m at WordCamp, is to talk to web designers, marketing agencies about why they should participate in something like this.

[00:13:13] Nathan Wrigley: So this really isn’t bound in any way to WordPress, is it? It just so happens that WordPress has a significant chunk of the internet, so this is a good place to start. But if you happen to be a, I don’t know, Drupal user, or you’re just into writing PHP code or whatever it may be, this is still applicable. There’s no real WordPress layer to this. This is just a good place for you to come because, well, there’s probably, what, 30 hosts, 100 yards away from us out there.

[00:13:37] David Snead: I know. And I haven’t seen all of them yet.

[00:13:39] Nathan Wrigley: Yeah, there’s work to do. But agnostic to any platform, basically.

[00:13:42] David Snead: It is completely platform agnostic, yeah.

[00:13:43] Nathan Wrigley: Okay. Okay, that’s interesting. But WordPress is a, is certainly a good place to start.

Now, I’m imagining, if I was a hosting company and I was the chief executive, I definitely have some questions for you in terms of, okay, we’re going to share our valuable intel with you, what are you going to do with that? How can we trust you? How do we know that the sharing is going to be done effectively and what have you?

So I guess really what I’m getting to is, what is the assurances or checks and balances that you, in the end, will hope to offer the host? That you can assure them that, look, if you hand us this body of work, you don’t need to think about it again. You can trust us to do it honourably, effectively, collaboratively. You get where going.

[00:14:26] David Snead: Yeah, yeah. And I suspect that you wanted to be a lawyer at some time, because that’s one of the issues that we’re facing. Information that can be shared freely, as an example, in the United States, might not be capable of being shared so freely in the European Union, or in Brazil, or in India or someplace like that.

So one of the things that’s being done, not by me, but by another group, another working group that’s part of this, is analysing the legal issues around information sharing.

The information that’s being shared, to answer the proprietary and confidentiality question, is not proprietary or confidential information. So it’s things like timestamps, domain names, IP addresses for the initial abuse submission. Things like that that really don’t indicate some sort of company confidential information. And it’s further abstracted into xarf, which is a language that’s used for abuse reporting, that we all can share. And so I think that the only thing that would be of concern is whether that information is personal information that’s subject to jurisdictional restrictions around the world.

[00:15:48] Nathan Wrigley: Would the idea be that this organisation would do the remedial work? So is there any notion that, let’s say for example, some sort of security problem was discovered by hosting company A over there, and they share that intel with you. Maybe the question is kind of asking, will you then appoint people to figure out what the patch is for that? Or is your idea just to, oh, red flag, we’ve got this problem, now you all know about it. Is it just information sharing as opposed to fixes?

[00:16:17] David Snead: Yeah, it’s the latter. So the thing that we’re solving for right now, so there’s just one issue that, one abuse issue, that we’re testing out and it’s issues related to fake shops. And so the fake shop issue is the test abuse issue for the project, and where folks are sharing information. It’s a particular problem right now with credentials harvesting. And so that’s what we’re trying to look at.

[00:16:43] Nathan Wrigley: And how has the conversations that you’ve had thus far, how have they gone? Has this been warmly received or are you facing a little bit of pushback?

[00:16:50] David Snead: So, look, I’ll be very direct with you. If something isn’t just an immediate threat to them, it’s very difficult to conceptualise why you should participate. And I am pretty used to answering that question simply based on the political work that I do with the i2Coalition. But once you talk about, so let’s use fake shops as an example. Fake shops, and you’re providing services to fake shops, actually has an impact on your bottom line.

So if you are providing, let’s say, payment processing to an entity that is running a fake shop, it very easily can make your credit card processing charges higher. It ends up eating bandwidth. It will tax your abuse resources.

One of the things that you referred to initially is, you know, larger hosts have a lot of money. I wouldn’t say they have a lot of money, but they have more bandwidth to handle a vast fire hose of abuse issues. Most smaller hosting companies might only get five or six abuse issues in a month. But if you have a fake shop, that’s going to generate a huge amount of abuse, and it’s taking away resources that you can use to actually grow your business. So that argument actually is relatively persuasive in getting folks to pay attention.

I find that the business argument around abuse is a much more compelling discussion than kind of moral persuasion. I don’t think moral persuasion works in the context of a community that is trying very hard just to keep their heads above water.

[00:18:42] Nathan Wrigley: It feels to me from what you’ve just said, and I could be reading too much between the lines, but it feels to me as if a good target audience would be smaller hosts to begin with, simply because they’re probably going to be more receptive because they have less bandwidth themselves. And so would welcome anything that can make the burden of sharing this information easier. So 10 of the small hosts combined is, well, it’s much bigger than each of them individually would be, whereas I suppose you’ll have to get a critical mass of them on board until maybe some of the bigger hosts start to look at you with favourable eyes, let’s say that.

[00:19:15] David Snead: Well, so we have some pretty large hosting companies who are participating. So as an example, both GoDaddy and Newfold are participating. But we also have smaller hosts. But I agree with you, the information that’s being provided, particularly since it is actionable, realistic information that can be adapted for bespoke systems, is invaluable, right?

So if you only get five or six abuse complaints and you get an abuse complaint, and you can go to the secretariat and say, we got a complaint about this domain, and the secretariat says, here’s what the registrar did. Here’s what Cloudflare did. Here’s the information they provided us. And you can use that to make a decision on how to address that problem. It saved you hours and hours and hours of research time.

[00:20:09] Nathan Wrigley: Technically speaking, what would the conduit of information both toward you and away from you look like? So if I’m hosting company X, how are you imagining that I will supply you with that information? But also, if I’m just looking for information from you on a daily, weekly basis, whatever it may be, how do I receive that? Is this like a, I don’t know, a website or an API or?

[00:20:33] David Snead: It’s an API. So it’s a file. It’s just a general file download.

[00:20:37] Nathan Wrigley: Right, okay. So it’s readily available 24/7?

[00:20:40] David Snead: Right. That’s the goal. Right now it’s not, but the goal is to kind of figure out a way to make something like that possible.

[00:20:47] Nathan Wrigley: Yeah, okay. I also suppose that the hosting companies, whilst this is good for their business if they can minimise costs and hand a lot of this work over to you, there’s a part of them which would also probably like to put some sort of badge on their website to say, this is what we’re doing. We’re part of this alliance, for want of a better word. Is that something that you are looking to develop as well, you know, some sort of credentialing system to demonstrate that you’re in this?

[00:21:12] David Snead: So that’s not something that the IIF is working on. It’s something that the Secure Hosting Alliance does. The Secure Hosting Alliance has a trust seal that we give to hosts who fulfil our Trust Seal Certification provisions. But that’s not something that the IIF does.

Talking about like why, other than business reasons, folks should participate in this, one of the things that is going on that I would suggest that most hosts know about, is there’s a little bit of a moral panic going on in the world about what contents you have. And regulation is actually a very real thing for the hosting industry, who has not ever been regulated. This is the time where you can say, hey, this is what we’re doing, right? We’re dealing with issues. This way a trust seal is the same thing, right? It’s something that you can say, we are actually taking steps to make the internet a better place.

[00:22:18] Nathan Wrigley: I think if you are a general agency owner or, I don’t know, just a freelancer, hosting is one of those things that you, once you’ve done it once, you’re in it for the long haul until something goes wrong. But you’re also browsing around for any tiny indication of why is this host slightly different? You know, what is it that they’re doing that, I don’t know, is faster? What is it that they’re doing that’s more secure? So it feels to me if you had a credentialing system and I began to hear about it and see it pop up again and again, it would be one of the metrics which I would weigh up when looking at hosting.

[00:22:51] David Snead: I would think so. One of the things that a trust seal does is it indicates that there’s been some vetting of the host. That someone has determined the things that are important to the hosting industry and are important to the web design industry. The agency industry are also important to the host.

Great example of that is one of the provisions of the Secure Hosting Alliances’ Trust Seal Certification is that a contract is presented to the customer before they sign up, which is super customer friendly.

One of the things as a lawyer that you hear about all the time when people are dissatisfied with their services is, yeah, well, I never saw that contract. Or it was just a hyperlink in an email that I got. That’s one of the differentiators for a Trust Seal certified host is that the contract is actually presented to them, to the customer beforehand.

[00:23:57] Nathan Wrigley: So in terms of the WordPress crowd, is this a thing that you are pitching only to hosts? Like when you step out of here, are you trying to have conversations only with hosts? Or is there some bit of the WordPress community, the freelance, the agency owners? Are you trying to communicate with them just to scope out what they need?

[00:24:15] David Snead: So for both the Secure Hosting Alliance and for the IIF, it is that. I really enjoy talking to agencies and developers about whether this is important to them, or why it might be important to them.

[00:24:31] Nathan Wrigley: In terms of how long this project’s been going, I’ve only heard of it because of your participation here, but I don’t know if you’ve been banging this gong for a decade or, I mean you’ve been in the industry for long enough to have been banging it for decades. Is this a new initiative or is this something which has a long and storied history?

[00:24:49] David Snead: So the Secure Hosting Alliance has only been active for a year, a little bit over a year. I’ve been talking about abuse for a long time, but the Secure Hosting Alliance has only been around for a year.

[00:25:01] Nathan Wrigley: And have you, in that year, got any intuitions that you’ll be here for another year? Is it basically going in the right direction?

[00:25:09] David Snead: It is going in the right direction. So we started out with two or three charter members. We now have 25 hosting members. We have three security vendors who are members as well. We have, I think, 17 Trust Seal Certified members, and we’re launching in 2027 a trust seal for security vendors who provide services to hosting companies.

[00:25:40] Nathan Wrigley: I know that several owners of hosting companies listen to this podcast. They may very well be the people that you’ve spoken to already, but if they are not, and they are people who would like to investigate this further, I suppose the thing that’s going to be in their head is, okay, Nathan and David, you’ve explained what I’ll get out of it, what do I need to put into it? So is this an annual financial commitment? How does it all work from that point of view?

[00:26:02] David Snead: Yeah, so you become a member of the i2Coalition. And so the Secure Hosting Alliance is a working group of the i2Coalition. So you would be a general member and you would participate in the Secure Hosting Alliances’ working groups. You also have the ability to participate in the i2Coalition as a whole, which is a much larger trade association that represents almost everyone in the internet infrastructure vertical. Mostly doing policy work, primarily in the US and the EU. Although there’s, we’re doing some work in India right now as well.

[00:26:40] Nathan Wrigley: And does membership allow you to steer the future of the project? I know that lots of chefs in the kitchen results in terrible food, but that, I fear, is something that could happen. You’ve got 87 members, 260 members. And then the 260 members all start to bicker and, you know, we want this, no. You see how it goes.

[00:26:59] David Snead: I do.

[00:26:59] Nathan Wrigley: What’s the position there? You know, is there sort of gated levels of membership? How are you organising all of that?

[00:27:04] David Snead: There are not. The membership is based on self-reported revenue. The membership is not horrifically expensive from my perspective. And I think that that, most of our members would say that it is, it’s actually relatively affordable, particularly for the small to medium sized hosts. And registrars or design agencies, anyone who’s participating.

The question about, who’s running the show, comes up quite a bit. We haven’t really faced that issue, particularly in the Secure Hosting Alliance. Folks seem to get along. But the organisation runs on the idea of rough consensus. And so decisions end up not being controlled by one member or not. Some of the i2Coalition has some very large companies who everybody knows about, who get along with startups, and folks against whom they compete directly. And policies still get made. The organisation still moves forward.

[00:28:11] Nathan Wrigley: Yeah, I guess you’re in a space where, obviously all of these hosting companies commercially are vying for everybody else’s business. But in this particular situation, that is not the case. Nobody’s vying for their websites to be less secure. They all want the same level of security. So at least in that sense, you would hope that consensus could be maintained even if, commercially, the two companies that are in the room, the 10 companies that are in the room might be commercially at loggerheads with each other. At least on this they could agree. That would be the hope, I suppose, anyway.

[00:28:47] David Snead: It seems to be, not only the hope, but the actual way that things work. You ask about how compromise is reached. What comes to mind is I have a much different concept of privacy than, particularly when I was at WebPros, than other folks in the i2Coalition had. And another company just called me up and we worked through our disagreements about how privacy should be handled within the i2Coalition and were able to move forward.

The industry I’ve found to be hugely collaborative, particularly the hosting industry. Everybody knows what their competitor is doing. But when it comes to addressing an issue like, how are we going to deal with abuse as a community? Folks come together. CEOs of hosting companies while they compete tend to be relatively good friends.

As I said at the very beginning, it really is like the Hotel California, right? You come in as a CEO of a hosting company, you grow it and you sell it to another company. All of a sudden you’re at the bottom again with a server in your grandma’s basement, you know, trying to start again.

[00:30:08] Nathan Wrigley: It’s a really curious effort. I suppose really at the bottom of this entire podcast is your endeavour to be heard and to reach out and get some conversations going. So with that in mind, where do people find the information about this? So maybe there’s a website that we could mention. But also, is there a specific place where you hang out? Is there a place where you would like to be contacted most?

[00:30:33] David Snead: Sure. So our website is hostingsecurity.net. I’m not too afraid of getting too much spam. So folks can email me at snead@i2coalition.com And the two is the numeral two. So it’s snead@i2coalition.com. And I’m happy to answer questions.

In terms of hanging out, I am at most industry conferences in the hosting industry. In the WordPress industry, I’ll be at WordCamp US. We also participate very heavily in ICANN. So there is an i2Coalition member at every single ICANN meeting.

[00:31:12] Nathan Wrigley: So if you go to wptavern.com and you search for the episode with David Snead, S-N-E-A-D, you’ll be able to find those details. I’ll put everything into the show notes. So anything that I missed? Was there a particular focus that we didn’t touch?

[00:31:26] David Snead: No, this is actually one of the most thorough podcasts I’ve been on recently.

[00:31:31] Nathan Wrigley: That’s love to hear it. Well, David Snead, thank you very much for joining me today.

[00:31:35] David Snead: Glad to be here. Thanks for having me.

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case managed WordPress hosting and AI hosting innovation.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today, we have Malcolm Peralty. Malcolm has been immersed in the WordPress ecosystem for 20 years, starting out as a full-time blogger and working his way through tech roles in project management, agencies, and even a stint in the Drupal space. These days, Malcolm is bringing his experience back to WordPress, serving as a technical account manager at Pressable, a managed WordPress hosting company.

Malcolm shares how he found his way from early forays with WordPress to managing large scale hosting environments. He talks about the lure of the Drupal world, and why he’s ultimately returned to WordPress and Pressable.

We discuss what technical account management means at Pressable, how his role differs from sales and support, focusing instead on long-term strategy for clients, performance optimization, and bridging the gap between customer needs and the underlying WP Cloud infrastructure. We hear how Pressable proactively helps clients, sometimes even advising them to downgrade their plan if optimizations mean they need fewer resources.

We go behind the scenes in Pressable, getting into how hardware considerations, plugin bloat, WooCommerce or LMS sites, and customer handholding, all come together inside one company. Malcolm gives us a candid look at performance challenges, the way hosts interact with infrastructure teams, and why education around WordPress performance is so tough, even as competing platforms prioritise speed at all costs.

We also look into the future. What are the cutting edge trends in hosting? Like database replication, virtual clusters, and especially the rise of AI within the hosting experience. Malcolm explains Pressable’s upcoming MCP, an AI powered control panel that promises to let you deploy, and manage, wordPress sites using natural language.

We explore how AI will impact everything from customer support to site deployment, potential pitfalls, and the challenge of balancing automation with human relationships.

If you’re curious about the state of managed WordPress hosting today, the interplay of tech, support, and AI, or just want to know what’s happening behind the curtain, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Malcolm Peralty.

I am joined on the podcast by Malcolm Peralty. Hello, Malcolm.

[00:03:55] Malcolm Peralty: Hi there. How you doing today?

[00:03:56] Nathan Wrigley: Yeah. Very nice to have you with us on the podcast today. Malcolm’s got a really interesting story. He’s done a lot, a lot of it kind of maps to things that I’ve done in my life. But it’s a tech podcast, generally we talk about WordPress, but I think we’re going to talk about hosting, AI, and possibly other CMSs.

But before we do, a moment for you, Malcolm, just to introduce yourself and give us your potted bio, I guess centering around your relationship with technology, WordPress, CMSs, that kind of thing.

[00:04:22] Malcolm Peralty: Yeah. So first off, I like to always say that I’m Canadian. I think that actually kind of gives us some insight into a little bit about how I think. And I live just outside of Toronto, Ontario, Canada right now, and I’ve been in the WordPress, around the WordPress space for going on 20 years.

I started with WordPress 0.72, so before the 1.0 release. And I was a full-time blogger, talking about WordPress for several years, and kind of stumbled into using some of my tech skills to work in and around technology with WordPress, and then project management. And because of project management, I’ve been able to work with agencies that build like smartphone apps and other CMS systems, and custom CMSs for customers. But I’ve always kind of kept a toe in the WordPress world as much as possible.

[00:05:11] Nathan Wrigley: Yeah, and you firmly landed back in the WordPress world working for Pressable, which we’ll talk about in a moment. But you had a bit of a foray in the Drupal, Acquia world, I think. The word Acquia may not mean a great deal to people listening to this podcast, but it’s kind of the equivalent, I suppose the best mapping would be Automattic over on the Drupal side. What was your experience with Drupal? How come you’re not still fully on the Drupal side of things?

[00:05:35] Malcolm Peralty: Yeah, so that was kind of a strange one for me. I didn’t expect to have a position in the Drupal world. I had done some like Drupal project management before, a lot of like moving Drupal sites to WordPress or like revising a Drupal site, or adding a smartphone app to a Drupal site. But that was mostly, again, as like a project manager or a site builder, not as like someone who really understood the engineering behind Drupal.

But a long time friend of mine reached out and said, hey, would you ever be interested in a job at Acquia working at the Drupal mothership, so to speak? And the position was a technical account manager, which thankfully leans more on my skills as a project manager and someone who understands web hosting than someone who understands Drupal. So I was able to use the combination of 20 years of skills in the space to actually make a good go at it.

And I think one of the big reasons why I was so enticed and interested by the position is, honestly, Drupal jobs pay better than WordPress jobs. And it’s horrible and sad to say, but I think it was a really important factor in my determination on where my career was moving. If it wasn’t for the fact that Pressable came along when it did, and basically offered me a similar kind of pay scale, I’d probably still be in the Drupal space and who knows for how long.

[00:06:55] Nathan Wrigley: Yeah, that’s really interesting. I was a big Drupal user for many years but just found it was, there was a lot of things that I didn’t need that Drupal did, that WordPress could do. And so I firmly moved ship away from Drupal. Well, I think it was when Drupal finally went to version eight, so many, many years ago. Something like 2015 or something like that. And I certainly haven’t looked back.

So Pressable, you may need to go and Google that if you’re listening to this podcast. You may have heard that name before, but it is a hosting company, I guess managed hosting, dedicated hosting for WordPress websites. My understanding is they don’t do anything else. Pressable simply work with WordPress. But what’s your role over there? Let’s begin there.

[00:07:37] Malcolm Peralty: Yeah, so I’m a technical account manager. I’m the second technical account manager that Pressable has hired. They’re trying to build out a technical account management discipline. For those that haven’t heard the term technical account management before, you might think it’s like a sales role or something like that with a technical bent, and that’s not it at all.

We’re basically, you know, like WordPress and WordPress hosting strategists, right? So we’re thinking about like, what does your website look like a year from now, two years from now? What technologies do you need to be aware of? What end of lifes will come up that you might need to develop against? What plugins and tools are you using and how performant are they, and are there more performant options in the mix that might work for you? And so that’s really kind of the role that we take at Pressable.

Right now a lot of it is also kind of the pre-sales, right? Like which tier of service or product will your website fit into? What kind of customisations or optimisations might you want to make in moving over to the Pressable platform? And so we kind of go through all of that with customers of kind of a certain scale and size.

[00:08:36] Nathan Wrigley: So do you, as part of the job description then, do you monitor existing websites that are on the platform already and look for, let’s say things like bottlenecks, where something’s going wrong? The client may not be aware of it, but you can then sort of inject yourself, begin a conversation and say look, you’ve got this suite of plugins, that’s great, but we’ve noticed that improvements could be made here, there, and the other. And here’s a suggestion for something that maybe will get rid of that problem.

[00:09:02] Malcolm Peralty: We do get to do a little bit of that, not as much as I would like. My long-term hope would be that, much like Acquia, much WordPress VIP, TAM would be like a subscription service that customers of a certain tier would be able to sign up for, and have like that consistent access and that consistent monitoring where, like on a monthly basis, you know, we’d go through our client list and like double check all of them.

Right now we’re sometimes a point of escalation for support if need be, where they’re like, this problem’s going to take more than an hour to solve. Maybe the solutions team and the TAMs can kind of take a look at this and dive deep into it. We also kind of monitor the data coming in from our server instances. And, yeah, we’ll sometimes kind of cherry pick some of the ones that are standing out as not working as well as they should be, or using more resources than they should be, just as a point of like general optimisation, right?

It’s funny because our role helps both the customer because, again, we don’t care about the money side, right. So we’ll come in and be like, here’s the optimisations you need to make. Now you don’t need even as quite a big a plan as you have maybe. Maybe you need to downsize your plan now because we’ve helped you optimise your website.

But from a resourcing perspective on the Pressable side, it’s also advantageous because one, it makes the company look good to be proactive in that way. And two, it helps for server resources, right? We have our own cloud, WP Cloud, which is our own server stack. It’s not AWS, it’s not Google Cloud. And so optimising resources can allow us to have resources available for other people who maybe are bursting because of a big sale or front page of Reddit or something like that. So we’re always looking at those optimisations as an opportunity on both.

[00:10:37] Nathan Wrigley: Do you, as part of your role, get to sort of interface somewhere between the customer, the people who pay you to have hosting and the hardware side of WP Cloud? Because presumably on the WP Cloud side of things, there’s a hardware layer. There’s literally people putting boxes into racks and putting the cables in and what have you.

Because my understanding is WP Cloud is owned, well, it’s not AWS, let’s call it that. It’s not Google’s Cloud infrastructure. It’s not any of those other things. It’s managed, known by whom, you can tell us in a moment. But do you get to have a conversation, say, look, we’ve noticed that this bit of hardware isn’t as performant as maybe something else? Or, look, here’s some new thing that’s been released onto the market, can we get a dozen of those and try that out?

[00:11:17] Malcolm Peralty: For sure. And as Pressable continues, try to move towards the higher end of mid market to try to acquire customers that are using WooCommerce or learning management systems, we’re finding those platform opportunities where we’re providing like, here’s what we’re seeing, you know, here’s all this data that we’re collecting. Here’s what we think this means. Here’s what maybe our competitors have done, or what our customers have noticed on competitor platforms. How can we either like negate the advantages of other platforms? Or how can we find ways to make ourselves even better than them? Or, here’s what we’re already doing, great, is there any fine tuning that we can do to like eek out that extra little bit of performance?

We try not to be too prescriptive with the WP Cloud team because they really are the experts in the hardware. But we bring a lot of that WordPress knowledge to bear and say like, this is what we’re seeing from a WordPress perspective, what can you do on a hardware and software on the server perspective to kind of make this work even better?

[00:12:12] Nathan Wrigley: It’s a difficult juggling act to perform in a way, isn’t it? Because on the one hand, we’re always talking about how performant WordPress can be, and on the other hand, we’re always talking about plugins and themes and the fact that amassing those will slow things down. You know, you throw in an LMS or WooCommerce or something like that and suddenly the website is going to be a different animal, let’s put it that way.

And so on the one hand, trying to pitch WordPress as performant, and then on the other hand, there’s this whole bit that you are dealing with where the performance is somewhat under question. I’ve always thought that’s a difficult challenge. And certainly in terms of marketing that and making the public understand that, okay, there’s the performance on one side, but we can manage that on the other side. I think that’s a really difficult thing to do because you’re trying to communicate something incredibly technical to presumably a whole load of people, some of whom aren’t technical at all.

[00:13:03] Malcolm Peralty: And even worse, a lot of other competing hosts will hide a lot of issues and faults and sins that customers have made on their website through like heavily used Redis setups that like just make it seem like their website is so much faster than it actually is. Or they’ll buy hardware that is, you know, has like the fastest CPUs. And so from you as a single user testing your website, you might say, wow, my website is so fast on this other platform, but when I move it to this company, now it feels slow. But you’re not doing a test at scale. You’re doing an individual test, right?

So you go on that hardware and you put like 25, 100, 1,000 users going through a checkout process, and all of a sudden your website is slow as molasses and starts falling over. Whereas on the platform that quote, unquote, seems slower, it’s so much more resilient and able to handle that load.

So there’s so much nuance here and so many things that we’re dealing with and a lot of the job ends up being at customer education because it’s very easy in the commodity hosting space to be like, I’m going to move to this other company because they seem faster. And that really shouldn’t be your single goal. It should be understanding your website. But a lot of small business owners, medium sized business owners, even large business owners don’t really necessarily want to understand how their website is built and how their pages are built and these kinds of things.

And it’s funny you mentioned about the WordPress performance thing because sometimes I want to be like, just do this one thing for me, right? On our platform, turn off all your plugins, go back to the default theme, tell me how fast your website loads because guess what, it’s probably going to load pretty darn fast, right?

The problem I have is the customers that have 50, 60, 70 plus plugins, and two of them are different like builder tools, which is unfortunately the bane of my existence. No offence to like Elementor and Divi and Beaver Builder and all these companies that are making these tools to help people have their dream website on the internet. But man, are they ever heavy and slow when you’re trying to create a performant website these days?

And so, you know, I’m often having these conversations about, what is most important to you? And understanding as well that search engines like Google, and search engine companies believe that performance is a big deal because that’s how they manage their own infrastructure, right? If a website is slow, then they can’t really crawl it effectively and understand what’s going on with it. So that plays into a lot of the conversations that I have as well. And it’s never easy.

[00:15:23] Nathan Wrigley: Yeah, I imagine it’s not. I mean, I don’t know if the goal of Pressable is to make it such that you show up with your website, pay your monthly subscription, whatever it may be, and kind of that’s it. We will take it from here. I don’t know if that’s the goal. Or if it’s more of a, we will have a conversation with you, we will make recommendations and over a period of time, we will come to some sort of happy medium where, you know, what you’ve got is what you are happy with and it’s also performant from our side.

So I don’t know how much of a conversation is there. Any website that I’ve ever brought to Pressable has been fairly straightforward. I’ve installed it, it’s worked exactly as I had anticipated, and so I’ve never really had to get into it. But, you know, a website with 10,000 SKUs, and a million visitors a day, presumably there has to be some handholding going on there.

[00:16:09] Malcolm Peralty: Yeah, I think the big point of delineation is the cacheability of a site, right? So the ability for us to serve it without building the pages from scratch. If you have a brochure site, if you have a marketing site, if you are, you know, the only thing on your website that’s like a real user interaction is some buttons and maybe a form to submit, like a contact form or a marketing related form, your website is going to run perfectly on Pressable without any kind of handholding, without any kind of consultation. You’re going to be able to upload it and know it’s going to be resilient to whatever traffic you receive, and even like power outages in entire halfs of countries won’t bring your website down.

If that’s the kind of experience you want, those plan tiers exist and they work great. And we have agencies that throw thousands of websites on Pressable’s platform in that kind of umbrella without any kind of issue or concern or question.

I think the consultative part comes in when you’re starting to do things like I mentioned before, learning management systems, e-commerce systems, merch drops, custom contests. If you’re doing anything that basically has a different user experience based on adding something into a cart, or like completing a module of learning that needs to be tracked and following the user, typically this means that it’s going to be uncached, which means that it’s going to rebuild that page from scratch, and that requires a fair bit of resources.

We’ve optimised a lot of things to make sure that we can do that effectively, but again, the conversation comes into play, if you add in Facebook for WooCommerce plugin that breaks cache on every page load, then we have to work with our customers to understand like what that means, and what the trade-offs are, and what replacements might exist to make it so that we can cache the majority of sessions so that they can stick within their resource utilisations that we expect them to use.

Most companies, including Pressable will sell on like the number of visits to the website, but also another piece is the amount of workers, right? So these are the little pieces of software behind the scenes that actually complete all of the things that users are requesting, right? Serving up images and web pages and shopping carts and stuff like that.

We have a really cool model where we have one worker per one VCPU, which basically means you get your own dedicated highway for that worker. He’s his own little car on his own little highway lane. Where a lot of companies will do like 40 workers to one VCPU. So imagine 40 cars on one lane highway, versus five cars on a five lane highway. So the way that we process things is a little bit different as well, and so that requires a little bit of education on our side.

[00:18:32] Nathan Wrigley: I think there’s this whole mysterious scientific laboratory kind of impression to hosting, if you know what I mean? I’m imagining a room, a laboratory, sort of white walls and everything, with a bunch of people wearing white overalls with pens neatly lined up in their top pocket, and obsessing about these acronyms. Well, this isn’t an acronym, but you mentioned workers.

But you’ve got things like Redis, you’ve got things like edge caching and all of this kind of stuff. And honestly, to me, a lot of that is a bit of a puzzle. And I don’t know how you educate the public about those things other than just saying, just don’t worry about it. We’re here for you. We’ll deal with that complexity.

But also, I’m curious to know what kind of innovations are there still to be done? Now obviously we’re sort of crystal ball gazing a little bit here, but I am curious about where is the bleeding edge of server technology and hosting technology? What are the things which are just a little bit over the horizon, but are of interest, which may drop in the next year, two years, three years, something like that?

[00:19:34] Malcolm Peralty: Yeah, I would say we’re seeing a lot of web assembly type efforts, which is kind of interesting, which is, yeah, I don’t know if anyone’s ever seen, there’s a WordPress Playground site where you can have like WordPress basically running in a browser. You don’t have to install it anywhere. It just exists in your browser as like this ephemeral install of WordPress that you can play with and do stuff with, and then export to a real install of WordPress if you’re interested.

I think that is a super impactful and interesting technology, and we’ll see probably more of that in the next little while, and how hosts can kind of play into that. I think that we’ll also see better caching technology, better database technology, but also I think better replication technology. So everyone knows that a lot of WordPress kind of exists within the database, and so if you want to have high availability, you need to be able to have that database exist in multiple places. But if you’re doing transactions on your like primary database for like e-commerce, you’re like buying products and you have, Malcolm bought a t-shirt from my website, he wants this size and he wants it shipped here, we need to now replicate that to any other like high availability databases that we have. That replication right now is very old technology in a lot of ways, and it’s not as optimised as we would like it to be. So there’s a latency that exists there in replicating that to other places.

Acquia and some of the other companies I worked for, that latency could be really high or really low depending on how it was configured, right? How long do we kind of keep that data there before we send it over?

We try to do as much real-time streaming at Pressable as possible to make it so like, you know, within like two seconds, the data is now in that replication. And so if your primary goes down, you’ve lost maybe a second or two seconds of data. On some websites, even that can be really bad, right? Because if you, let’s say you’re doing a big product drop and you have 10,000 people wanting to buy tickets to your concert, and you lose two seconds of data, that could be hundreds of transactions that just evaporate into the ether. So better ways of syncing that data across, and managing that relationship between multiple servers I think is going to be a big transition that we see in the marketplace.

We’re already seeing the idea of virtual clusters. So multiple data centres pretending to be like one local server. So then we don’t have that same feel of migrating or syncing data between locations, it just pretends it’s all kind of in the same place. So I think that will be kind of interesting to see because again, that adds more resiliency. And I think, everyone that I’ve ever talked to, if you say like, how long are you okay with your website being down? Even if it’s not a moneymaking website, you’ll hear them say something like, I don’t know, maybe an hour at most, right? So finding ways to make websites more resilient is going to be important.

And then I think just a better understanding just from top to bottom on what’s happening with a website, right? So we have a lot of logging, but it’s not necessarily the best at auditing. So, for example, if Nathan came on my website and got access to it and deleted a plugin, I might not have the best tools right now to be able to say, oh, it was this IP address at this time, he logged into this user, he did this action, and have that complete picture to be able to kind of quickly and easily reverse.

We kind of depend on backups right now a lot of the time, and I hate that. Or we depend on like trying to fish through logs and make those connections using our human brains. All of that is just a really poor solution and I think AI will hopefully help with some of that, and I’m looking forward to having more of this like very specific picture of every action that has on a website without, again, adding a whole bunch of load to the server environment or a whole bunch of data storage requirements that makes it really impossible for organisations to kind of have all this information, right?

Because if I start auditing every action that I’m taking on a website that I have access to, and you think of Pressable having multiple thousands of websites, hosting platforms, you can imagine the amount of data we’d then need to record, right? So data compression becomes super important, or the ability to kind of infer things based on data that we’re seeing becomes important. The amount of work that I do in like looking through logs would make your eyes kind of pop out of your head. It’s brutal sometimes. And logs have never been very user friendly.

So again, another area that AI has been helping us with is like, okay, pull out the things that are potentially the most impactful, the most interesting, the things that stand out over like a statistics, probability kind of system.

[00:23:48] Nathan Wrigley: Yeah, I think what’s really curious about everything that you’ve just said is, so there’s this kind of impression for people who are just casual users of WordPress that you go to a hosting company, it’s a bunch of files and it’s a database, how hard can it be?

And then you’ve just given us a bit of a window into, well, this is how hard it can be, because there’s so many scenarios. And the typical mom and pop store where, like you said, an hour’s downtime might not be the end of the world, and most of the things can be cash and all that kind of thing. Well, that stands in real contrast to the, I don’t know, the gigantic megacorp .com company that’s doing 8,000 transactions every couple of minutes and there’s millions of dollars going through. And there’s just a whole other layer of things going on there.

And so you see the word Pressable and you think, hosting company, pretty straightforward. And I think it’s really interesting that you get an opportunity to come on and say, well, actually, no, there’s this other layer. There’s all this stuff going on in the background. There’s all of this technology. We’re thinking about the future. You know, we’ve got different geographical locations where things are housed, and we’re trying to speed that up so that there are all these different clusters. It sounds complicated, essentially. I’ll boil it down to that.

So I am a Pressable customer and when I go into the Pressable admin, I sort of log in and, you know, I’m presented with the usual array of different options. I would say that there’s more than probably somebody like me is requiring, but there it is anyway. You know, there’s lots of different options for tweaking this, that, and the other thing.

What I’m trying to sort of draw an analogy to is that it can be a little bit overwhelming if your day job isn’t to deal with a website. You log in and, what is this? What does this menu even exist? There’s probably ways of Googling it and finding it out. But I know that in the near future, Pressable is going to be launching sort of like an AI component to the hosting side of things. An MCP, you’ve described it as Pressable’s MCP. And then in parentheses, get AI to do things related to your hosting, whether that’s WooCommerce or WordPress or performance optimisation or whatever it would be.

So this is interesting. And I’m just curious as to how deep are you going to allow the AI to go? We all know that the AI, any AI can hallucinate. So I’m curious as to know what kind of things are you unleashing for the AI? Is it just a case of, okay, I would like the light theme now, please? Or does it penetrate much deeper than that?

[00:26:10] Malcolm Peralty: So it’ll be in phases over the next little while, we’ll unveil these features and what connections that we have. But eventually the expectation is, anything that you could do or click on as a user in the control panel, an AI could also act on and do as well. So a great example that we’ve been giving our agency partners is if you, let’s say, are working on code for a customer’s website, you could say to the AI built into your Visual Studio Code or your GitHub or whatever, hey, spin up another sandbox site, push this code, update the database, pull from production, all the files, and let me know when this is complete.

And the MCP will go and it will spin up a new sandbox site, a new WordPress install, with a new domain name attached to it. It will grab your code and push it up to that website. It’ll go to production and grab the files from the wp-content uploads folder, and sync it over to this new staging site or sandbox site that you’ve asked for. And then it’ll say, hey, by the way, it’s now ready for testing.

And you’ve done this all with natural language as a command behind the scenes. Or, let’s say you’re running a thousand sites, tell me all the websites that need like a Gravity Forms plugin update. And it will go and it’ll check all of your websites in the Pressable platform and give you a list of like, hey, here are the ones with Gravity Forms updates. And you could say, okay, update them for me please. And it’ll go back and it’ll do that job.

[00:27:24] Nathan Wrigley: So I guess the goal is to make it straightforward to use natural language to do a variety of tasks. Now obviously there’s got to be some serious guardrails around this because, you know, it would be very easy to inadvertently type, delete all of my, that’s a bad example but you get point. You know, what are the contraints?

[00:27:43] Malcolm Peralty: Yeah, please don’t use dangerously skip permissions, for example. So a lot of the AI tools that already exist have some human in the loop questioning. Are you sure you want me to do this? Are you sure you want me to do this kind of thing? And kind of seek their approval. We’re also talking about what, if anything, we’re really going to do on our side about that? We have pretty solid backup solutions put in place. So maybe if you, you know, accidentally said, clear out all of my platform, and it deleted all of your websites, you could then hopefully say, can you actually restore from backups all of those sites and have it restore from backups all of those sites.

So, you know, we keep hourly backups of database, daily of the WordPress file system, so there is that. Also our main WordPress install is simlinked, which means that you can’t actually change any of the core files. So even if you told it to delete WordPress, it can’t actually do that piece of it. So your WordPress install would still exist, but all your plugins and uploads and database would all be gone. But you could just restore them again using natural language.

So there are some guide rails that we can put in, but at the end of the day like, you’ll be able to connect whatever AI tool you’re using. Maybe you have Ollama with a local AI tool on your computer. Maybe you’re using Claude or Codex or something else. You’ll be able to use any of those AI tools. And so some of it is really on the person using it to put in some of those guardrails and those human and loop things. And I would recommend having a like system prompt that basically says like, before you do anything destructive, check with me first. Not that it won’t automatically do some of that, but it’s just good to have a secondary layer.

[00:29:13] Nathan Wrigley: And how are you exposing these capabilities to, let’s say Claude or whatever it may be? So what does that interaction look like? How is it that certain capabilities are available, but others are maybe not, and so on.

[00:29:25] Malcolm Peralty: Yeah, I mean I like to think of an MCP kind of like USB/API for AI. So we’re basically just making those kind of endpoints available to the MCP, or making like those API endpoints available to AI, so that it can undertake things on your behalf. So like our whole control panel is basically APIs all the way down, so to speak. So it’s not very hard to kind of hook those things up.

I think the harder part is making sure that the AI understands what these controls, what these APIs do, what they expect to receive, what they expect to give back, and what that all means. And once all of those kind of definitions are in place, then it’s pretty easy.

[00:30:05] Nathan Wrigley: I think one of the curious things for me is being inside, let’s say the Pressable UI where I’m navigating with a mouse and I’m clicking on things, everything is very intentional. You know, I go to a thing, and I do a thing, and I get a prompt to say, are you sure you want to do this thing? And I say, yes. And so it goes. And so every single thing that I do requires an interaction with me.

I suppose, with an AI, you could concatenate a variety of things. Maybe the AI has some sort of misunderstanding along the way, or you type things in such a way that it’s not entirely clear. And then kind of unpicking, okay, what just happened? It’s really easy to unpick that in the UI because you can say to the support rep, well, I did this, and then the site died. Okay, we know what happened there.

Whereas with this cascade of things, which is done with natural language, presumably this is where your logging, that you described earlier, comes in. There isn’t really a question there, but I’m curious as to what that process is. The capacity for many dominoes to fall from just one simple prompt, I suppose as a point of concern for you guys, because you are going to have to be unpicking all of this on the backend when things, which they inevitably will, go wrong.

[00:31:16] Malcolm Peralty: For sure. And I mean this is one of those areas though where we’re ahead of the curve. I think a lot of companies will be adding these kinds of things. But from an AI perspective, I mean, since October or November of last year, we’ve seen the skills and abilities and understanding of the top tier AI tools just jump exponentially. So the number of mistakes or concerns that we have have gone down in that same vein.

Our support team has also been trained up in a lot of these. And we’ve been testing a lot of these MCP pieces for a long time now. So we feel pretty confident that those that enable this and that have a good understanding of what this means and how to use it won’t make too many mistakes or have too many concerns or issues.

You know, again, we’re targeting a lot of our agency partners that are developers that already kind of live and breathe this stuff. So they’re also used to being able to untangle and knot if they tie themselves in one. So I don’t expect someone with their like first WordPress website on Pressable to enable MCP and start using it.

I really think this is most valuable to agencies or companies at scale. You know, if you’re running one website, you probably don’t need this, but if you’re running like 10, 100, 1,000 websites, then this tooling becomes very helpful. Because you can have like a, maybe do it on one site and now then replicate that same thing you just did across all of the sites I manage.

[00:32:33] Nathan Wrigley: I don’t really know how to phrase this question, but I’ll give this a go. At the moment, presumably you have a fairly solid relationship with your customers. You know, if something goes wrong, you log in, you enable the chat widget, you have that conversation. There’s this backwards and forwards, okay, great. And maybe there’s lots of clients that you get that you never have that interaction with.

But I’m just curious how that relationship over time might change with the advent of AI. And what I mean by that is, it’s almost like you’re not talking to humans anymore. And because of that, you start to have a different impression of the company that you are dealing with. Okay, it’s just some sort of AI entity, I don’t need to worry about it so much. Maybe loyalty starts to come into question because there’s no humans there anyway.

So again, it’s very hard to encapsulate what I’m saying, but presumably from a marketing point of view, there has to be some moment at which you say, okay, there’s too much AI now. We’re no longer a bunch of humans presenting ourselves to the world. We just look like a bunch of robots. Do you know what I’m saying there? Does any of that land?

[00:33:34] Malcolm Peralty: It does. I will say, we have those conversations internally. The expectation is always going to be like, when we add a new feature, it’s going to be added for humans first and then added to our AI tooling. But the only way that you can compete in the modern marketplace is to take advantage of some of the tools and opportunities we’ve been given with AI. As difficult as it is, there’s probably a business case, you know, I’m sure there will be businesses that will target people saying like, we don’t use AI for support, we don’t have AI integrations, we’re a completely human business. But I think the difficulty will be like scaling and competing in the modern marketplace.

And like a lot of the agencies we’re talking to are expecting this. They’re pushing us towards this because they’re looking to reduce their time to delivery, right? They want to be able to sit in a coffee shop with a customer, get a brief of the business, give that brief to, you know, an AI tool that transcribes their voice to words, and then have it go through this whole system of setting up a hosting sandbox for the website, set up WordPress, select a theme that matches their expectations, set up the brand colours, and almost have like a proof of concept at the end of a meal with a customer, that was assisted by AI.

And if they can’t do that first step of setting up a sandbox or a staging site for the customer, then we’re not part of that conversation at all. They’re going to go where there is that feature and that functionality, and Pressable won’t be part of that conversation at all.

And as end users, I mean, having AI assist with the things that agencies or higher touchpoint customers need, gives us that flexibility now to be available for the $25 a month customers who actually need the handholding and support from a human that we just couldn’t do otherwise, right? It just doesn’t scale properly at that price point.

So I think this could be advantageous to both sides if it’s used right and done right. But I definitely agree, there’s landmines that we have to kind of be cautious of and avoid, and we have to be very careful about how we apply this. And I think the key thing is always making sure that everything that we do is human first, and then AI enhanced, rather than AI first and human supplemented. It’s just a hard line to walk.

[00:35:37] Nathan Wrigley: It’s so interesting that conversation you’ve just described in the cafe where, by the end of the cup of coffee, you’ve got yourself a website based upon a conversation you were having moments before. The collapse of the timeline there. You know, we used to think that this five minute install was a big thing. Now it’s like the five minute website that’s fully ready to go, you know, or at least some simulation of a website. May not be the finished one but, you know, you’ve got a staging site ready, with a theme that’s adjacent to what you want to do, with some content that might replicate what you want to do. And it all took place in less time than it took you to finish a single coffee. And that’s so interesting. And you have to armour yourself against that.

That raises another question of course, which is how far you, your tentacles go into the website itself. Because traditionally hosting companies really didn’t concern themselves with the website, apart from the fact that the website was available and, you know, we can see what your plugins are and yada, yada. But it does sound like we’re straying into theming, and possible content creation and things like that. So I don’t know if that falls into the roadmap a bit as well.

So maybe there’s a future where you can, with the AI sort of say, I’d like to swap out my theme. It’s Christmas time, give me a Christmas theme. But we’re doing that in the hosting environment. We’re not necessarily having to log into the website. Again, do you sort of see where I’m going with that?

[00:37:03] Malcolm Peralty: Yeah, and I foresee for sure, but the integrations with AI that WordPress 7.0 already has, and the discussions for 7.1 make me believe that Pressable’s MCP will be able to talk to WordPress’s AI integration and do that from end to end. So, I mean we could already do it with the MCP, like adjusting database values and stuff like that, but that’s not what I would consider an ideal way of doing this.

But like I said, with the changes that are happening in WordPress Core, I definitely foresee like a complete end-to-end solution. You know, one AI talking to another, who then carries that task forward, reports back to the Pressable MCP and lets us know that theme change is done, those plugin updates are done, the content change is done. And again, all from that initial prompt, you know, maybe in your Visual Studio Code, which is just crazy to me.

[00:37:45] Nathan Wrigley: I am so used to basically not going back to the hosting until there’s a problem. You know, I go to the login URL for the website in question, I log in, I move around the WordPress UI, create a post, publish a post, schedule something, whatever, upload some assets. You get the idea.

And the idea of that not being the modus operandi for everybody will be so interesting, because it’s going to shatter that experience of, you know, you could watch a YouTube video to figure out the thing because everybody does the thing in the same way.

But it feels like we’re heralding a future where no two people are going to have the exact same experience. You know, you may be creating content through a text editor, which then somehow gets uploaded, or the text editor merely creates a prompt, and then the theme is swapped or amended because you’ve typed in some prompt.

So, you know, my UI, my IDE, my text editor, my version of WordPress, maybe I might build my site entirely differently to you. So that’s fascinating and slightly worrying at the same time because, how do you support that? Not just Pressable, but how does the community support it when we’ve got an infinite number of ways to create a blog post?

[00:38:55] Malcolm Peralty: And not just a blog post, but everything.

[00:38:57] Nathan Wrigley: Yeah, right, everything. Yep.

[00:38:58] Malcolm Peralty: Maybe you say you want this Christmas theme. Maybe it doesn’t select a theme and change the colours, maybe it writes a whole new CSS for the theme you have. Or maybe it writes a whole new theme, or maybe it writes a plugin that automatically switches it around Christmas time. Like it doesn’t have to pull off the shelf from the theme marketplace or the plugin marketplace that already exists. It can create something wholly new and specific for you.

Maybe it writes a whole new block for you, rather than trying to pull together three or four blocks to be able to create the output that you’re looking for. And some of these things for sure are not going to necessarily be super performant or super secure, especially initially, right? Maybe a year or two from now, once the AI is even smarter than it is today, or has a better understanding of WordPress than it does today. Maybe it will kind of think more about security and performance than it does right now. But you’re going to have these people deploying things that are not the ideal outcome, or ideal solution, or ideal anything. It’s just works for them right now.

And it’s funny, I always hear people talk about maintenance, right? How are we going to maintain all this AI code? We, humans are not going to maintain all this AI code. AI is going to maintain and update all this AI code. And so the joke of it is, if you come along and your host comes back to you and says, hey, your website’s running like a dog. You’re not going to spend half a day or a day trying to troubleshoot anymore. You’re just going to say, hey, AI, why is my website running poorly? Fix it or give me a list of things that need to be fixed, or what have you.

I at Pressable am already like using AI to basically write scripts that run through like two dozen WP-CLI commands, another two dozen like database commands, and some like full code searches. Give me a quick report on anything that needs to be optimised, right? So I didn’t write that script from scratch, I didn’t write that code from scratch to do that. I directed an AI to be able to create that for me. And now as the human in loop, I’m interpreting the data that it’s collected, but I can foresee a future very near where I say, hey, AI now interpret all this data you’ve collected and send a summary to the customer on what they need to change or do. Go and act on my behalf and make these changes.

[00:40:49] Nathan Wrigley: That’s so interesting. So there’s a couple of things. The first one is that it feels almost like we’re heralding in a future in which the WordPress UI maybe is not seen by everybody. So a good example would be, I have a Mac. I rarely use the Mac. I use things on the Mac. You know, I’m using a browser. I use a text editor. I use the application that we’re using to record. I’m not really using the Mac. I hope that lands, if you understand what I mean. I switch it on, but the Mac kind of just goes into the background and I use a bunch of things, which, they’re on the screen because I’ve got a Mac.

[00:41:25] Malcolm Peralty: And I would say like 90% of it’s probably a browser at this point, right?

[00:41:28] Nathan Wrigley: Right, right.

[00:41:30] Malcolm Peralty: It’s a website that you go to. You can do Slack in a browser. You can do what we’re doing today in a browser. Pretty much most things that I do live in a browser. There’s very few applications that I actually need to load on my machine day to day because everything can exist in a browser. I think that paradigm will just be for the next generation, or for the transition that’s happening now, the new paradigm will be everything just lives in an AI application. Whether it’s installing your computer or whether it’s also in a browser. It’ll just be AI.

[00:41:54] Nathan Wrigley: Yeah, so it is analogous to that. It’s just this idea that the WordPress UI, that’s the only method that anybody has had, maybe that will be something that a bunch of people use, but it won’t be familiar to everybody because there’s no need for it.

And the other thing that you mentioned is, I suppose I would use any of the stuff that you’ve described, but there’s the one caveat. And the one caveat is I have to know that I can walk it back. I have to know that there is a way for me to undo every mistake that I just made because I got carried away. I sat down, got a bit carried away on a Saturday afternoon, made a bunch of tweaks. I really regret it. I want to know that I can go back and unpick that stuff and for it to be a seamless unpicking. So backups, I guess is the most straightforward way of doing that.

[00:42:40] Malcolm Peralty: And audit logs, right? So like one of the things that I’ve done is, in my system instructions, I do put, before you do anything else, backup the file system, backup the database and create a, like a markdown file that’s going to be step by step, everything that was done, everything that you thought so that I can then review it. And that really helps me kind of get an understanding of the tasks it took and maybe why it took them, to help me refine future attempts, right?

So going back to what we’re doing in hosting, like we’re always trying to think through, like you mentioned, everything is very specific and clickable, and we want to make sure that the AI understands exactly kind of what to click on, or what to select. And having that auditing is super important for that.

[00:43:19] Nathan Wrigley: And that’s the point, isn’t it? It’s a human readable or parsable log of everything. Something where, you know, you’ve got millions of data points in the audit log, but I can actually drill down into that in a meaningful way. Because it may be that I only want to undo a portion of what I did. I’m happy with some things, but I would like to go back. An audit log, as you’ve said, it’s fairly mind numbing stuff.

But we are going to be producing so many more amendments if all we have to do is speak because you can easily, you know, imagine it. I want the Christmas theme. No, not that one. Try something else. No, there’s too much red in that. Swap the red for the blue. And Father Christmas, I’d like him on the homepage but, no, a different one. In 12 seconds we’ve got thousands and thousands of things that have happened.

[00:44:06] Malcolm Peralty: I will say though, how much of that do you remember doing manually, right? Like I’ve gotten to the end of that kind of thought process and gone, wait, there was like a theme like two or three themes ago that actually was, a little bit of customisation could have been cool. What was that theme?

Even as a human, I’ve had lapses in memory when I’m quickly producing outcomes where I can’t necessarily roll it back so easily. So at least with an audit log, you’ll have a much better understanding of what was done and when. Human memory is also failable.

[00:44:30] Nathan Wrigley: Yeah, and I guess it’ll be interesting to see how much of that burden companies like Pressable take on. Like, you mentioned backups, maybe it will become de rigueur for you every few seconds whilst there’s interactions with MCPs. Look, we’re just going to go belt and braces. Every time you do something, which we detect is fairly sizable, we’re just going to take a backup, even though you never asked us to just in case. You know, those kind of things.

And have a UI to surface information so that the audit log is readable and those kind of things. And that’s all ahead of you. So it doesn’t exist moment, but it’ll certainly be things that will need to be tooled and invented in the future, I would’ve imagined.

[00:45:10] Malcolm Peralty: I mean, one of the hard parts, this might be transitioning the conversation a little bit, one of the hard parts is, you mentioned that AI is creating all these artefacts, and now all these potential backups. AI is already like indexing all of these websites and creating a lot of web traffic, and a lot of load on servers, for example. We had a recent instance where an AI bot went to a website and kept on adding different products to the cart and removing them. Well, every time it added a product to a cart was now an uncachable session.

And it did this millions of times over the course of a day. So we were like, okay, we got to block this bot. This is crazy. So we blocked the bot and about like 10 minutes later we start seeing the exact same traffic pattern from a completely different IP address with a completely different user agent. The bot had figured out an end way around our block and was now doing that same task again to try to, I don’t know, understand this website better, right?

The problem is, as an industry, we don’t know how to pass these costs on to customers because they think it’s kind of unfair in a way, right? Like, why should I have to pay for additional storage for all these audit logs and all these backups? For more bandwidth for my website or more resources for my website, to host or send all of my pages to these different AI bots? And it all kind of comes on us where we either have to like comp all of this technical effort that’s existing, or we have to convince clients to be okay with paying for it. And that has been a really interesting change in the dynamic with a hosting partner.

[00:46:24] Nathan Wrigley: That is so interesting. All those hidden costs, all those hidden things going on. Maybe there needs to be a luddite toggle in the UI somewhere where you just disable all of it. I want the WordPress UI, I want to do things manually. This is my preferred way of doing things.

[00:46:38] Malcolm Peralty: Block ChatGPT. Block Claude. I don’t want any of them viewing my website. Forget them.

[00:46:42] Nathan Wrigley: But it will be curious to see if there’s a subset of people who are, as you’ve described, unwilling to pay for that stuff because it’s simply something that they don’t use. They have no anticipation of using. It will be interesting to see if there’s a subset of people.

And also how clever these technologies become to disrupt things like that. You know, malicious actors out there who managed to come up with a million different ways to circuit around the blocks that you put on. And it will be interesting to see if just the cost of being online does rise with the advent of AI.

I mean, certainly the storage of all of these things is certainly going to rise. The conversations with the AI is certainly adding a financial cost. You know, there’s lots of hardware being built at the moment and there’s a cost to that. Certainly isn’t cheap. But whether or not we can cope with that, and whether or not your price points can keep up with that, and whether customers are going to pay for it.

Okay, there we go. That is so interesting. There’s so much stuff to dive into there. We could probably talk for another hour or so, but there we go. So, Malcolm, if anybody wants to reach out to you or learn more about Pressable, I guess, where would we reach out to you? Do you do social media or whatever it may be?

[00:47:51] Malcolm Peralty: I try not to. For Pressable, it’s pressable.com. For myself, I’d prefer you go through my personal website, which is my last name, .com. So peralty.com. And if you do want to get me on social media, honestly, really the only one I’m ever on is LinkedIn and I only kind of connect with people that I actually connect with. And then Twitter or X or whatever it’s called, I passively view from time to time. But honestly, the best other places would be, you know, you could probably find me on one of the WordPress Slack communities, for example, if you’re really interested.

[00:48:18] Nathan Wrigley: Okay, so Peralty, peralty.com. If you are driving a car listening to this and you can’t write it down, then go to wptavern.com, search for the episode with Malcolm Peralty in it, we will have all of the links that were suggested and talked about during this episode right on the episode show notes. So, Malcolm, thank you so much for chatting to me today and peeling back the curtain a little bit on the hosting over at Pressable. Thank you.

[00:48:42] Malcolm Peralty: I appreciate it. Appreciate it so much. Thank you for having me.

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, how CloudFlare outages impact the web, and WordPress performance solutions.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox and use the form there.

So on the podcast today, we have Saumya Majumder. Saumya is the lead software engineer at BigScoots with a deep specialization in high performance WordPress engineering and advanced CloudFlare powered architectures. Throughout his career Saumya has built large scale systems ranging from custom caching engines, to migration tools, worker based automations, and edge computing solutions. He’s played a pivotal role at BigScoots overseeing enterprise customers, and developing scalable developer friendly solutions that push the boundaries of hosting for WordPress.

We begin our conversation with a timely discussion about a major CloudFlare outage that recently rippled across the internet. Saumya explains what happened behind the scenes, the nature of these kind of global infrastructure hiccups, and why, even with the most robust systems in place, some downtime is simply inevitable. He offers valuable insights into how BigScoots is able to mitigate these issues for their customers, even automating rapid failovers to keep sites online during outages.

We then move on to explore some of the innovations that the team at BigScoots have been working on. They focus upon site speed and reliability. This includes CDN level page caching, and their close integration with CloudFlare Enterprise. Saumya breaks down how this caching differs from traditional server based caching, and how it ensures that users around the world get fast, local access to website content.

If you’re curious about how hosting companies manage such advanced caching strategies and how CloudFlare might fit into the hosting jigsaw, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Saumya Majumder.

I am joined on the podcast by Saumya. Hello, how are you doing?

[00:03:04] Saumya Majumder: Hey, I’m doing well. How are you doing?

[00:03:05] Nathan Wrigley: Yeah, very well, thank you. So this is going to be an interesting conversation. I got put in touch with Saumya via Tammy Lister, who has been communicating with Saumya over the last period of time. I don’t know exactly for how long. But the idea is that we’re going to talk about what they’re doing over at BigScoots and the interesting innovations that they’ve got.

By pure coincidence, the day before we recorded this, the Cloudflare, I’m going to call it fun, the fun that Cloudflare had with the entire internet happened. And so I think we’ll digress for a bit at the beginning of the podcast and talk a little bit about that as well, which was unexpected. But given that you are working heavily based upon Cloudflare, it’ll be interesting to talk that through.

Would you mind just spending a moment though, just introducing yourself. Just tell us who you are, what it is that you do at your current role, that kind of thing, and then we’ll get stuck into our conversation.

[00:03:55] Saumya Majumder: I’m Saumya. I work as a lead software engineer at BigScoots, specialising in high performance WordPress engineering and advanced Cloudflare powered architectures.

I also build large scale systems from custom cache engine to migration tools, worker based automations, edge computing and whatnot.

I also look after our enterprise customers, all of our internal WordPress projects and plugins and IPs. And I also build scalable, developer friendly solutions for our clients to ensure that they are getting the best service product out of it.

[00:04:29] Nathan Wrigley: Thank you very much indeed. Now, I’m just going to dwell on that for a little bit. A lot of that seems extremely technical, but also it kind of feels like that you went very much down a particular road very early on.

How is it that you ended up doing all of that interesting, but quite specific stuff? How is it that that happened? Is it something that you pursued out of college or something like that? How is it that you went down that path?

[00:04:51] Saumya Majumder: It’s an interesting question actually. So I remember, back in my second year of college, I started doing projects, like outside projects. So I started dabbling with PHP, like at the very early days of WordPress. So I get into the WordPress and I was like doing coding, changing things, pushing things to the core, tinkering with the WordPress. That was like way back in the days of the WordPress ecosystem.

From that, I was dabbling with PHP and other stuff. So that was like back in the days when I started, and then slowly I started seeing problems and how to solve the solution. So for example, a lot of the companies today, like CDN page based page caching, in today’s 2025 it’s like a very, pretty much common thing across the world. If you go to any premium hosting or any premium package, you kind of expect like CDN based page caching.

You know that that wasn’t the case, even like a few years back. It’s like this level page caching or RAM level page caching, like it’s all on the server. So me and one of my friends, whom we met online due to the WordPress coding things, we actually invented the CDN level page caching. So it wasn’t a thing before that. So there was a plugin that we created called Super Page Cache for Cloudflare that got later acquired by a different company called Optimal.

In that plugin we actually looked at like, okay, all the current solutions, like if you break down how the request is happening or how internet works, like you make a request from wherever in the world, that request then travels through across optical fiber cable, blah, blah, blah, to the ISP data center. Then from there it goes to the data center, well, then it reaches the server from there on. If you don’t have cache, then the server has to populate the entire thing, get the response, give it back to you, if you have the cache.

So we were saying that, you know, this is adding like a huge amount of latency, especially if you are, like the distance between the server and you is larger. Back then there was like MaxCDN, KeyCDN, and all of this provider who are like focusing on static files being served from the CDN.

So that was like already a thing, but we were like, okay fine. But like if static files coming from CDN, that’s great, but the main leap frog forward is if we can move the page. Like, literally serving the page HTML from the CDN itself. So if you are in Australia, the request doesn’t have to come to the US. Like, if it’s cached, it’s literally coming from your neighborhood.

So caching was one of the most complex problems that I kind of always loved solving because it was one of those unsolvable problems in the computer engineering world. So that’s how I like get into it, and then started. I broke a lot of things and fixed them and it’s like a journey. It’s hard to explain, but it’s like a journey of a lot of failure and a little of success, I guess.

[00:07:37] Nathan Wrigley: Yeah, I can imagine. Do you ever get the sense that you are approaching the destination or is this whole thing just, I’ll do this and then I know that in a week’s time, there’ll be something else that I can optimise. Is there ever a moment where you’ve thought to yourself, okay, that’s it, we cracked it for now? Or is it always just, no, there’s another thing?

[00:07:55] Saumya Majumder: It’s always a process, right? The technology is evolving. There’s way, way more to dig deeper. So one of the things we recently released was end DB protection caching. I’m going to talk about it in a moment and also login user caching. Both of these things were in my bucket list for years, and I have done like R and Ds, and R and Ds, and R and Ds to figure out exactly the way to do things. So again, you know, like it’s a process, right? And it takes time.

[00:08:20] Nathan Wrigley: Yeah, that’s lovely. Like you say, we’ll get into those bits and pieces. But as I said at the top of the show, by pure coincidence, we had this, let’s just call it a real collapse in a sense of what Cloudflare provides to the internet as a whole. And I think, depending on where you were and when you were awake in the world, I think for Europeans and maybe the part of the world where you are, it hit us right at the time when we’re all awake. I think maybe if you’re in North America, especially on the West Coast, you might have missed much of it.

But for most of the day here, everything on Cloudflare just declined to work. And it was really interesting how profound that was. And we’ve all heard this problem before. We’ve seen the little drawing of the great big tower built of Lego bricks, and there’s the one little brick at the bottom holding the whole thing up, and it’s called Cloudflare, or it’s called AWS or what have you.

Can you explain to us what the heck happened yesterday? Are you able to sort of get into, do you understand it at this point?

[00:09:15] Saumya Majumder: Yeah. So internet is a magical thing. It works by magic. If I get into explaining how it works, it’s going to be another thing. But the way it works is, and especially in case of Cloudflare, right? Like, a lot of people look at Cloudflare, that it is a CDN provider, like MaxCDN or Akamai or like any of these providers. But CDN is just one bit of Cloudflare. Cloudflare is like a, such a gigantic service that is like built on top of it.

So as a result, what happens is, when you have such a big system working together, there are lots of critical dependencies that happens. You have all these boxes, but all these boxes are depending on one of these config file, or one of these things that is coming from the layer below that, right?

And if anything happens in that one thing, the things at the top are working fine, but it cannot work because the one thing that is below it is gone.

I would also like to say there is no such thing in the world of internet that just works. Everything is supposed to break at some point in time. There’s no such thing. Be it Google, be it Azure, be it AWS, Cloudflare, anything it is. Even if you have your own data center and everything like that, like we have, there’s no way that, like a lot of things can happen even after you are prepared to mitigate all of those things, like you have follower, and a follower, of follower and all this backup system, still things can go wrong. Maybe that didn’t turn out, maybe that didn’t happen.

I saw a lot of memes yesterday on Twitter, like a lot of people was posting like, hey, I just joined as an internet Cloudflare. I pushed a code and that happened. And I understand that it’s funny, but when you look deeper into it, it is actually not funny. It is really like a code red scenario. And trust me, no one, no company wants to get into that code red scenario. Because you have to understand, all of these companies also dealing with a lot of enterprise customers to whom they have promised like 100% percent SLA or 99.99% SLA. And so when they don’t meet that, they have to pay a hefty amount of credit back to them.

So it’s not just the downtime and bad reputation and marketing and all that, it’s literal money being bled out of the company because of that. And it’s like all of those systems.

But at the same point in time, the way technology works, things can mess up. You can do multiple tiers of review of the code, you’re still going to miss a certain edge case scenario, which will only occur if this happened and that happened. And the probability of that happening is probably 0.00001%. But that 0.00001%, it’s not zero. It can happen.

In the world of engineering, we call certain things that are super low priority, like it’s never going to happen. I’m not saying that it cannot happen, it can happen, but the probability of that is so low that spending engineering hours on that at this moment, where we have much more critical things to do, it doesn’t come up, right?

But sometimes things happen. And as a senior engineer, it happens like this. And in case of Cloudflare, what happened is as this is like a such a big system, even if they identified the root cause, let’s say that takes some amount of time for the engineers to figure out, and they push that. And you have to understand, a lot of people are sending requests, requests are going down, and they figured out the root cause. They’re pushing the fix and then like a boatload of requests is coming to Cloudflare.

So it takes time for everything to stabilise, you know? So it is bad. It is bad, but anyone who is thinking like, oh, Cloudflare is bad, if I move from Cloudflare to, I don’t know, X, Y, or Z, or something like that, it won’t happen. I haven’t seen, like a Tweet yesterday where somebody said, send cold emails to people saying, Cloudflare is down. But we don’t use Cloudflare, we use our own VPS and dedicated server for that. And I was like laughing out loud. I’m like, I understand that, you know, your data center did not go down, but that does not mean that it can never go down.

[00:13:06] Nathan Wrigley: It’s kind of guaranteed. I think one of the interesting things that I saw was in the mitigation, the sort of summing up posts that Cloudflare created, there was this whole thing about this unexpected file which kind of doubled in size. It was supposed to be this size, but it doubled in size, and that got propagated. And then for a period of time, the ripple effect of that was that it looked like a DDoS attack. For a period of time it looked as if it may have been malicious actors.

And so the Cloudflare engineers, I think kind of went off, as it turned out, wrong headedly. They went off in the wrong direction, searching for the problem, which probably added a number of hours to the mitigation, and then kind of figured out what was going on. And then, like you said, the whole ripple effect is, it’s not like you turn off a computer, switch the computer back on, and Cloudflare is restored. There’s this whole propagation thing where you find the problem, mend the problem, the problem mitigates, and that is presumably going to take hours and hours and hours. And then you could just see the sort of downtime reports slowly repairing themselves over the internet.

[00:14:08] Saumya Majumder: And you have to understand that, as I said, Cloudflare, people think of Cloudflare as a, either a security company or a CDN company. But Cloudflare is way, way, way more than that, right? The CDN backbone that they have, it’s literally their backbone, the powerhouse on top of which Cloudflare builds their own thing.

So anytime they find a fix of which they call their control plan, you know, pushed the fix to their control plan, that has to get propagated across all of their end edges. And Cloudflare has the highest number of CDN PoPs, you know? So it has to get pushed across all of these places, rebooted and all of these crazy things has to happen in order for everything to go properly. And then all the burst of traffic that is coming on that it has to handle that. It is a crazy thing.

But one of the things that I liked about Cloudflare is that, it’s not that this is the first time Cloudflare had a global outage. They had global outage before as well. There are two things I really love about Cloudflare.

Number one is that they’re super transparent. So anytime things go wrong or situation like this happens, they always push like a detailed blog article explaining exactly what happened, what they did to fix it, and how they’re making sure that this does not happen again in the future. And it never happens in the future.

So if you look at the previous global outage that they had, I think back in June, it was caused because there’s a thing called Cloudflare KV, which had a dependency on GCP. So when GCP went down, so KV went down and as a result the system went down. And from there on, they’re now working on to remove that dependency, building things internally in house to make sure that doesn’t happen.

Previously, there was another, I think last year or something like that, another global outage where the entire main data center went down. There was like multiple failover but the generator didn’t start and then this didn’t start and that didn’t start. And that caused like a huge failover scenario, I think, if you remember that, right?

And from there on, they make sure that, okay, we now have to make sure that we have multiple, that scenario is never going to come back. So they always work towards to make sure everything that happening never happens the second time. And it really does that. But at the end of the day, in the world of technology, things can go wrong. It’s just how it is.

[00:16:11] Nathan Wrigley: What’s kind of curious though, from an end user’s perspective, and you are going to explain to us some of the complexities of the inner workings of BigScoots and how it combines with Cloudflare in a minute, and that’ll be really interesting. But from a non-technical user’s point of view, it just feels like the sky is falling in because so much of the internet has collapsed, so many things that they’re familiar with.

So just a couple of examples which many people would be familiar with. So for example, if you were a user of the social network X, that completely failed. There must be a dependency on Cloudflare at some point there. Also ChatGPT, which is now becoming almost, it’s just a thing which almost everybody at some point of the day is plugged into, that went away.

But then it just rippled out across so many other things. News organisations go down. The ability to log into a variety of things went down. So it may be that your platform itself worked, but you might have had the the Turnstile sort of capture system, which Cloudflare run, enabled, and nobody could log into the proprietary platform that you got because the Cloudflare portion, the Turnstile wasn’t working and so on.

So it just had this enormous effect. And the sort of chilling effect of that is that people then, erroneously I think, sort of view Cloudflare in some way as a bit of a, I don’t know, a giant that needs to be brought to heal in some way. You know, we can never let this happen again, there’s too much dependencies on these small group of massive organisations and what have you.

But by today, everybody’s forgotten that, you know, they kind of moved on with their lives and we’re back to what it was like on Monday. And so there’s no question in there, but I think there’s some insight that I’m sharing.

[00:17:41] Saumya Majumder: Oh yeah, absolutely. So there are a couple of very important things to understand here, right? So first of all, as you said, the people who talks about these kind of things on the social media, trust me, either they’re not engineers, senior engineers, or they don’t understand the problem.

And so these are the people who talks about this exact same thing where a few weeks back AWS went down, and then a couple of months back, GCP went down. And then they were like, well, Facebook went down, they literally just use this exact same word every single time something goes down. But things can go down. That’s like, you have to accept that and move on.

And that’s why when you get onto these enterprise deals with these big companies, they have this SLA agreement, like where they say, we grant to you, as I told you about earlier, right? So all of these companies, GCP, AWS, Cloudflare, if you are like a big enterprise customers of them, you have like an SLA agreement with them. Where they say, okay, we are going to guarantee that we’re going to give you 100% uptime, or 99.999999% uptime. And anytime they miss that mark, they have to pay back a huge sum of money as a credit to the customers saying, okay, we missed on our contract, so this is that credit back to you.

So you have to understand that anytime situation like this happen, it is not only a bad thing on the companies, on the marketing front of it, but it is also a bad thing on the financial side of things. Because you have to understand like all of these big companies, there are these smaller clients who are dealing with companies like, there are smaller clients and there are like giant clients, the enterprise customer who companies are really worried about. And for these giant clients, they have to pay huge amount of money back as credit because things didn’t come back within time. So it is not something that they are not worried about to fix immediately. They’re literally trying as hard as possible to fix that.

So that being said, now talk about the other points that you brought up, the turnstile, the WAF and the other things, right?

So as I said, Cloudflare is not just a security company. It’s like a huge thing. Cloudflare has a thing called Developer Platform where you can literally deploy your own APIs, your AI workload, your workflows, your entire React or entire application on Cloudflare, which is amazing. I use it. I love that platform.

And then that is one side of using Cloudflare, and then there’s another side of using Cloudflare like, for example, using BigScoots. You have let’s say a WordPress website that is hosted on BigScoots, but it is being proxied via Cloudflare to leverage their CDN, their security and all of those features.

So in a scenario like a WordPress site where you are not using Cloudflare as your host, so your Cloudflare is just there as a proxy, making sure that your origin IP is not there, your site is super protected and performance and CDN and whatnot. In that scenario, anytime this kind of problem happens, you can kind of, when this outage was there, the API was still working and we actually, for all of our customers, we leveraged our API to make sure that any request does not proxy via Cloudflare, but instead it just goes directly to our server just for the moment in time until Cloudflare is back in the game.

[00:20:42] Nathan Wrigley: Oh, so you could turn the proxy off via the API.

[00:20:45] Saumya Majumder: Via the API, yes.

[00:20:46] Nathan Wrigley: Right. So the fact that the rest of us couldn’t log in because Turnstile was down, we couldn’t authenticate into the Cloudflare network on the web. The API was still available, so you could turn the proxy off for a variety of your customers, and the domains and the websites that they had.

Oh, that’s really interesting. So they had a few minutes of downtime. Okay, that’s fascinating.

[00:21:04] Saumya Majumder: So what we did is when we saw this outage happening, anytime requests are coming in, it was a code red scenario on our end as well. All hands on deck. So anytime requests are coming in, like people are having problem, we immediately turned on the proxying API to make sure that this site is up and online.

So that way the request is not going via Cloudflare anymore, it’s coming directly to us for the moment, until CloudFare is back on track. And that helped us to mitigate the downtime as much as possible for the customer, even though Cloudflare was technically down.

But if you would have been hosting your Nuxt or React or Next.js kind of application on Cloudflare, where you are using Cloudflare workers and things like that as your host, in that scenario, you couldn’t push anything.

[00:21:49] Nathan Wrigley: Yeah, the API is not going to help you.

[00:21:51] Saumya Majumder: Yes, yeah. It was bad but it’s going to happen. It can happen.

[00:21:54] Nathan Wrigley: Yeah, I think that’s kind of the message, you know? Nothing that humans create is immutable. Everything has a moment of breaking. But, you know, if you were to cast your mind back until, well, just Monday when everything was, you know, just plain sailing, Cloudflare was working as normal, then everybody was entirely happy. We had this period of time, it was maybe something like 8 hours where everybody’s kind of throwing their arms in the air and, you know, moaning on whatever social networks are still working.

But now we’re onto Wednesday, that whole thing is long behind us. That ship sailed, whatever, move on. Confidence, I think basically what you’re saying is you can be confident in Cloudflare. They’re going to have hiccups because they’re like any other company, things will go wrong.

[00:22:33] Saumya Majumder: Everything can have hiccups. So it’s not just, so you have to understand this, right? Again, I’m saying that Cloudflare is not just a CDN provider, but if you look at Cloudflare and all the things that they do, the complexity of it is like mindbogglingly crazy, you know? Like it’s immense, immensely complex. It makes things super easy for you. Okay, you just toggle this on and it’s done. But if look at under the hood, and all the things and chains it has to go through, and that happens in a blink of milliseconds, it’s crazy complicated.

As I said, right, like I’m not saying that Cloudflare is bad. I think Cloudflare is amazing because two things, they have super transparency, so anytime anything happens, the blog article that you are like referencing here, they didn’t hide behind anything like, oh, it was not my problem, like not doing the blame game thing. No, no, no. Like, it was our problem. This is the problem.

For example, in that blog article, they could have completely, don’t talk about the DDoS thingy, right? They could have just said, oh, this was the configuration file problem. We fix this, it’s done. But no, they actually literally walk you through how exactly they process the problem, which is really great. And then they actually learns from their mistakes to make sure that particular mistake never happens again, while they are like growing rapidly and building things, pushing things like crazy, like always pushing new things, which is like amazing to me.

[00:23:50] Nathan Wrigley: I think the article even started, if it wasn’t the first set of words, it was definitely in the first couple of sentences. It was something like, we let you down. It was full ownership, I think. So bravo to them.

And you’re right, the complexity behind it, you know, like you said earlier, the internet, the fact that anything works on the internet is an utter miracle of engineering, of computer engineering.

You know, the fact that we’re on a platform that we are staring at each other. I can see your image, you can see my image, you can hear my audio, I can hear your audio. You are on the, a different side of the planet, but it’s happening like you’re stood next to me. And the millions of packets of information that have flown during the course of this conversation, it’s insane. And Cloudflare add a whole layer of other stuff on top of that, which makes it even more insane.

[00:24:33] Saumya Majumder: Yeah. And you have to ask the question, like, why all these big companies are using Cloudflare like if it is so bad. Because they are doing things that nobody else even think about doing at a scale. And it’s like mindblogglingly crazy. It’s crazy.

[00:24:46] Nathan Wrigley: Yeah, yeah, it really is. So we’ll leave that for another day. But obviously over at BigScoots, you’ve really attached your wagon, if you like, to Cloudflare. And when you agreed to come on the podcast to talk to me, it became obvious to me that the pay grade that you are at is very different to the pay grade that I’m able to keep up with.

So we’re going to talk about what you’re doing over at BigScoots. I’m going to try to keep up, but if I misunderstand something, or I have to ask you to repeat something, I hope that’s okay with you. But I’m just curious because Tammie Lister, like I said at the beginning of this episode, she’s somebody whose opinion I respect a lot, and she said that you are doing some really innovative, interesting things with your connections to Cloudflare at BigScoots. So just lay out some of the interesting engineering work that you’ve been doing. I’ll try to hold on.

[00:25:30] Saumya Majumder: First I’m to Tammie is great. Tammie is amazing. But yeah, I mean, I think BigScoots have been one of the first to utilise Cloudflare Enterprise in the hosting world. I know we didn’t do any kind of huge marketing like other hosts, but we have been the first to leverage Cloudflare Enterprise in our hosting ecosystem. And it was such early days, like back then, all of these things, this market wasn’t there. So we were building things that people didn’t even test it out.

So as I said in the beginning, like I, along with one of my colleagues, we invented the CDN level page caching. This is way before APU and all of that. So all of those things actually build upon the architecture systems as we build on, including APU and the workers and stuff.

So at BigScoots, the Cloudflare thing, especially the Cloudflare Enterprise thing opens up a whole new door for us because it now allowed us to provide CDN level page caching for every single user at a super high cache hit ratio. I mean it’s like, every time you hit a page, chances of that getting, coming out of cache is much higher, compared to if you are, or like a free plan or any other plan, right?

So that was the beginning. And on top of that, we build our own proprietary plugin called BigScoots Cache, which allows you to not only leverage and take advantage of the Cloudflare page caching, but giving you the ability to fine tune every aspect of page caching that you would like on webpage.

[00:26:56] Nathan Wrigley: I’m going to pause you right there. Firstly, because I’m sure that almost everybody in the audience, because their WordPress aligned, is going to understand what a cache is. They’re going to understand this process of kind of, okay, let’s remember something for next time so that when we need it next time, it’s kind of ready. But they may not understand how Cloudflare does this on their Enterprise plan.

So what is it that’s different? Because we may be familiar with, I don’t know, a WordPress plugin and we’ve got some idea that there’s a cache. It’s sitting on the server somewhere in a file, it’s an HTML file or something like that. You are describing something not in one location, but like really just spread globally so it’s ready at the point of least distance from wherever somebody is. So tell us a bit more about that.

[00:27:35] Saumya Majumder: So let me explain that with like an analogy, right? So before CDN level page caching, I think pretty much everybody would remember, like we used to have caching plugins. I’m not going to name anything, but they were caching plugins. So when you turn them on, what they essentially did was they would create like an advanced-cache.php. You have everything of that file inside your WordPress installation.

What that used to do is, when you send a request, let’s say you are in Australia, right, and your server is in US, so you want to open example.com, and that requests flows through under the ocean, it goes to the data center, it goes to the server, the server receives the request, it started processing that, run all the database queries and all of that, and then it got the HTML to show it to you.

Back then what it used to do is then, advanced-cache.php would kick in, it would create a copy of the HTML, store that locally on the server so the next time if someone requests for that page, instead of asking the server, hey, please process the PHP and database and all of that, it would require much less amount of server resources because it’s just like, WordPress is like warming up. The request goes to advanced-cache.php, then it says oh, I have that cache file, sends that cache response back to you.

But even in this scenario, if you are making this request from Australia and your server is in US, you have to understand that the latency is very high, because the request has to go from Australia to US and then whatever gets there is, you know, response from there and come back from US to Australia. So the traversing time is pretty high.

From there on, and back then we are thinking about MaxCDN, you know, KeyCDN and like putting static files on the CDN so that, yes, the page is being generated by the server, but the static files are being served literally where you are. Like, if you are in Australia, in Sydney, so maybe the CDN PoP in Sydney is like, when you make a request for that, the static file is coming from Sydney.

That’s where we thought about, what if we can put this page HTML, instead of in the server, we can put it on the CDN? There were two benefit out of this. First, it is in insanely fast. Because if this page HTML is across the world, so if you are in Sydney making the request and the request is like, oh, okay, I have this page cache to me, here you go, the response, you get that in like less than 100ms, you know?

Same thing happens for someone sitting in India and Germany and some other places of the world, because it’s cached across the globe. So it’s not just coming from a single place. And anytime it is not cached, the request goes to the server, HTML processed, and by the time the response is sent out, it got cached. It’s cached across the world.

Now, that was the page caching part of it, right? And then there’s other things, the object cache and OPcache, that’s like whole another different level. But I’m not going to get into that. I’m just going to stay with, because then it’s going to get way too long.

So that’s where this object caching and Cloudflare Enterprise came into play, right? Cloudflare Enterprise then allowed us to make sure that we can cache all these pages across the globe with a very high cache hit rate. Cache hit rate means, when something gets cached somewhere, let’s say someone makes a request to that file and that cache is expired from there and it’s not there. So the request, again, has to go to the origin and get processed and come back to you.

So that is generally the case with the lower tier plans with Cloudflare. So with Cloudflare Enterprise you get a very high cache hit ratio. So when it’s getting the cache, it stays on the cache for a very long time. On top of that, we got tiered cache and regional tiered cache and all of those crazy things.

Which that means is, we have tiering systems. So when you make a request, the request first gets cached in the upper tier. And when a lower tier, so let’s say, how can I explain this to you? So let’s say you are in Phoenix, okay? And in Phoenix there’s a data center, or a PoP that is called, in case of CDN, a PoP is there in Phoenix but the upper tier PoP is Chicago.

So let’s say someone made a request from Chicago, the page was cached in Chicago data center, okay? Now, as we have this tiered cache system, when you, from Phoenix, is making the request, instead of that PoP directly sending the request to the origin, it would first internally within the intranet of Cloudflare, not the internet, okay? The intranet of Cloudflare. The internal network like, hey, does anyone in the upper tier has this page cached to you? And if they say yes, they would fetch it from the upper tier, which is like crazy fast because there’s no traffic, and it’s like a internal network of Cloudflare.

And if it does not, then it pass on the request to the upper tier, because the upper tier is the only one who has the power to pull the request from origins. It goes to the upper tier. Upper tier pulls it from the origin, creates a copy, and it’s upper tier, and then send it back to the lower tier. So in that way, in the tiered architecture, it makes sure that the cache hit ratio is insanely high.

[00:32:24] Nathan Wrigley: Let me just sort of read that back to you just to make sure I’ve understood. And I’m imagining that, the simplest way my head is understanding that is a bunch of concentric circles. So in the center is me, and I wish to find something on, let’s say, the outer circle. So the first thing I’m going to do is go to my inner circle, and if the inner circle doesn’t have it, we need to go to the next circle out, and the next circle out, and the next circle out.

Now in the old world, if you like, or the non-enterprise version of Cloudflare, at some point we have to go further out of the circles in order to find what it is that we’re looking for. But what I think you are saying is that on the enterprise level, that outer circle is constantly pushing things towards the inner circle on a much more local basis. So rather than having to go out circle, another one, another one, another one, it can just hop one circle out, get what it needs, and then hop right back. In other words, every single thing is always closer, geographically, than it would be in any other setup.

[00:33:22] Saumya Majumder: Yes, and on top of that, if you look at the opposite architecture of this, right? So imagine you are in Phoenix, Phoenix doesn’t have it in cache. Phoenix sends a request to origin, now someone from Mississippi makes a request, they don’t have it in cache, their PoP makes a request too.. So all these PoPs are making requests to the origin because they don’t have it in their own local cache, which is bad because that would then mean the request to the origin would increase dramatically, which we are trying to reduce.

But in this sense we have, imagine like a fixed set of upper tier data center, then we have like a middle tier and then the lower tier, right? So if lower tier doesn’t have it, it asks the middle tier, middle tier checks if any of the middle tier across the world have it. If they do, immediately send it. And that’s happening within the internal network of Cloudflare and not on the open internet, okay? It’s like crazy fast.

[00:34:11] Nathan Wrigley: Right, okay. So again, forgive me, I’m going to make a leap of faith here, I could have this wrong. I’m guessing that on the Cloudflare side, they have their own bespoke hardware to route all of this stuff. So like you said, you described it as an, it’s like an internet intranet, almost, the scale that they’re on. But they’ve got their own hardware, which will be able to route that information presumably more quickly, and with less, I don’t know, less latency than you and I might have.

[00:34:36] Saumya Majumder: Yeah, it’s a intranet, it’s not internet. It’s a private channel, right? So no one talking there except for Cloudflare. And the best part of that is, so imagine let’s say you are making a request from Mississippi, and there is like a upper tier data center in Mumbai, India, right? So what happens is, even though it’s not cached in US, it’s going to see that, okay, I have it cached in Mumbai, let’s take it from there instead of making a call to the origin, reducing the call origin, yeah.

[00:35:05] Nathan Wrigley: Okay, that bit I didn’t understand. So the entire network is aware of where the closest thing is even before it needs to have it. I got it. Okay. That’s fascinating. And do they own the cables? Do Cloudflare own the cables connecting these things?

[00:35:18] Saumya Majumder: Yes. Yes, they have their own data center, their own backbone, all of that. And on top of that, like at BigScoots we even have direct physical connections to Cloudflare service. That’s called CNI. That’s like a next step. So again, let me kind of paint a picture. This is you as a user, right? This is Cloudflare sitting in the middle, acting as a reverse proxy, and this is origin, okay?

So the way it works is you make a request, right? So let’s say you, a request is received by this in a reverse proxy Cloudflare. Then it process that thing, whether it has to show you a WAF page, whatever the logic is, right? Does it have it in cache and all of that? You know, if it is not being blocked or challenged, do I need to show it in cache? Do I have it in cache? You’re talking to the internal network, all of that. And that’s happening in this middle tier, right?

And this middle tier is now connected to their entire Cloudflare chain, right? So if, let’s say Mumbai has it, and it pulls from Mumbai, give it back to you. So the request never goes to the origin, right?

Now, for whatever reason, you make a request to Cloudflare, Cloudflare checks it’s internal network, it doesn’t have it itself, so it has to make a request to the origin, right?

There’s the interesting part. This bit of connection that is you and the Cloudflare, that’s happening over the open internet, right? Because like you making and the request goes by the open internet and lands to Cloudflare, right? And then this is your origin, so your Cloudflare to origin, right, that also generally happens by open internet. Cloudflare then makes a request, and that request goes by the internet and, you know, lands on the data center.

But here’s the magical part that we have done. As we run and own our own data center, what we have done is we have connected a physical cable, like literally optic fibre cable with super insanely high bandwidth with the Cloudflare servers, with our servers. So what happens is, anytime Cloudflare has to fetch something from our origin, instead of sending that request by the open internet, which could be slow, there could be congestion and whatnot, it then sends via that private network that we have created, that private optical fiber cable and lands directly to our origin. Like, oh, this is hosted on BigScoots. We need to talk to BigScoots. Okay, send via this channel, which is not part of the open internet. And boom, it gets there, comes back, it’s like insanely fast.

[00:37:32] Nathan Wrigley: Okay. How did that happen? Like, is that some sort of agreement that you have struck up directly with Cloudflare so that you can tap, you know, in a sense it feels like you’ve become a third party piece of their network infrastructure almost.

[00:37:47] Saumya Majumder: Think of like, if Cloudflare is like a one gigantic network, our systems are also plugged into their network so that they can use the intranet system to fetch data directly from us, instead of using the open internet, which is much slower, there could be congestion and whatnot. To making that request between the Cloudflare, the proxy and the origin, making that instantly fast.

[00:38:10] Nathan Wrigley: So how did that whole thing come about? How is it that you fell into this agreement? Because I don’t know if many other organisations do this, you know, outside of the web hosting space, maybe this is a typical thing where you could follow a roadmap from another company that had done it. I’ve not heard of this, so that’s kind of interesting. How did that relationship come about?

[00:38:26] Saumya Majumder: If you don’t run your own data center, it is very hard to do this.

[00:38:29] Nathan Wrigley: Yeah, I do not.

[00:38:30] Saumya Majumder: Yeah, because you have to literally connect your servers and routers and everything to the Cloudflare network, you know? So most of the hosting companies out there, they don’t run their own data center on their own space. They actually lease, what I call lease their hardwares and services from other cloud providers. Whereas we run our, you know, our private cloud, our private system, our own data centers, you know?

So like, for example, some company could use AWS or GCP or Azure and then create their own flavor of it and run Cloudflare through it. So they actually don’t have physical access to those data center’s other servers. Whereas we do. If we see something, we can literally pull up the drive, we can do things at our data center, we can change things, we can attach those things physically, which pretty much none of the hosting provider that I know of has access to.

[00:39:19] Nathan Wrigley: It’s so interesting. Honestly, we could go on about this for absolutely ages. But basically, the long and the short of it is, you’re making things as fast as it’s possible for electrons to be. In a distributed network where some things don’t know things, and other things do know things. It’s all an enterprise in trying to figure out how to make it so that everything knows everything as fast as it is possible for electrons to fly around through the optical cables that there are spread throughout the world.

[00:39:47] Saumya Majumder: I haven’t even described the servers.

[00:39:47] Nathan Wrigley: I’m nowhere near finished because I want to get into what it’s like for somebody using, we’re a WordPress podcast, so I guess at some point we need to sort of grind it into that. So how would it benefit just some normal human being who’s got a WordPress website? What does all of this clever technology that you’ve created and that you’ve combined with Cloudflare over at BigScoots, what does it bring?

[00:40:09] Saumya Majumder: It brings insanely fast speed. Insanely fast speed, super improved Core Web Vitals, and super DDoS products and all of that. It brings all of that. And I don’t want to talk about this kind of things, which I know the audience might not be interested about. I want to talk about more other interested things that the users can use.

So I was talking about BigScoots cache, which is our own IP, right? So we created our BigScoots cache plugin, top two are manage this entire Cloudflare caching system to work with that. And not just that, it gives you, if you are an advanced user, it literally gives you the ability to fine tune and manage every aspect of caching system that you want, every aspect of it.

So let’s say for example, we by default set the cache TTL, CDN cache TTL to let’s say X, but you have like a bunch of pages where you want, I want the TTL to be lower. There’s a hooks for that. You can use that.

Or maybe, let’s say whenever we have intelligent cache purging systems. So whenever you push up to create a post or update a post or something like that, what happens is anytime you push that button, like publish or update, behind the scenes the BigScoots cache plugin intelligently, not only clearing cache for that particular page, but it also knows all the other important pages like taxonomy pages, like archive pages and all that, like author pages that are linked to that article, and then clearing cache for those as well.

So you can also use other hooks. So let’s say you have some fake archive pages that we have seen a lot. Let’s say you are using a theme where you are showing list of articles on a page, which is like technically a page where you are using like a short code, which is not like a real archive page. So the system doesn’t recognise it as an archive page, but you want to clear that page cache whenever something of this tag or this category is published. There’s a hook for that. You don’t have to do that yourself. If you come to us and tell us like, this is our problem, this is the problem, we can actually write the code for you and do it for you. Like, we can literally just set that up for you. We provide like fully managed system.

[00:42:10] Nathan Wrigley: So I’m guessing that the level that you’re at there is you’ve got to have a fairly deep understanding of the sort of caching infrastructure, or would what you are offering be available, not necessarily to deploy, but could anybody understand this with a rifle through your documentation or is it fairly, propeller hat, tinfoil hat stuff?

[00:42:28] Saumya Majumder: We have like a proper documentation for every single hook there is. At the very top we talk about, like this is for the advanced audience. And if you don’t know what hooks are and things like that, it is going to be hard for you to understand what’s going on. But if you know, if you are familiar with actions and filters and things like that, it is going to be pretty straightforward for you.

So that’s why I said, if you don’t know, but you have a problem, and that happens a lot of time, people come to us, we just literally just write a snippet and just make that happen for them.

So you don’t have to know all of that crazy things, you know? It’s there if you are an advanced user, the documentation is there, but if you are not, it’s also there. On top of that, BigScoots cache has its own REST API, which you can use to clear cache, like you can literally use BigScoots cache REST API to clear cache. Imagine you have built like a Laravel system, or some backend system where you are adding something to your e-commerce site and you want to clear cache. When that happens, you can literally leverage BigScoots cache REST API to do that. So that’s like the, on the end of BigScoots cache. Then inside our BigScoots portal.

[00:43:34] Nathan Wrigley: Ah, that was where I was going next actually. Go on, yeah.

[00:43:36] Saumya Majumder: Yeah. We have, I think we have the most advanced and fine grain control to Cloudflare Enterprise that no one else in the industry provides. So I don’t know if you got a chance to look at our enterprise settings page. We really allow users to fine tune things exactly the way they want. So for example, let’s say you, do you want to protect your login pages from bad bots and actors, so that they can’t DDoS that? There’s a toggle for that. Turn that on, it’s done.

You want to enable our own advanced hardening production, which is not using Cloudflare hardening production, it’s using our own proprietary algorithm for that. You want to use that, feel free. Turn on, that toggle is there.

You want to change your image optimisation settings, do that. You want to enable Rocket Loader to every single thing starting from cache settings, speed optimisation settings, there are like bunch of things that you can play around with. You want to block AI bots, do that. You want to block bad bots, like manage, challenge bad blocks altogether, just turn a toggle, it’s done.

So we have so many settings there. I think, if you go take a look at just that settings, you would be blown away. Like, all the things that we allow our customers to customise and fine tune.

Let’s say, for example, you want to block requests from certain countries or continents, and now settings is there. Just choose the countries or continents, requests are blocked. You want to manage, challenge, you don’t want to block, you want to challenge the request from certain countries and countries, you can just go to the settings inside our portal, choose the contains and countries from where you want to challenge. So you could have a combination. So you want to block requests from these countries and continents, challenge from these continents and countries and don’t do anything for the rest of them. So you can play around with this to a whole new level, like you can just do anything you want.

[00:45:19] Nathan Wrigley: It’s absolutely fascinating. And it kind of makes me feel that your target audience would not be really the bricks and the mortars shop, the mom and the pop website?

[00:45:27] Saumya Majumder: There actually are. Yeah, like you you won’t believe how many times we have got a request like, hey, you know what? In our analytics, we are seeing that we are getting a lot of requests from Thailand, and that’s like broken our tools like that, so I want to either challenge or block that. So we are like, you go to the settings, choose the Thailand, click save, it’s done. So it’s like as simple as that.

[00:45:45] Nathan Wrigley: Yeah, I’m kind of imagining though, that you are kind of ideal customer, for want of a better word, maybe that’s the wrong wording, but would be kind of agencies, WordPress agencies, that kind of thing, who could obviously make use of this. They’ve probably got teams of people who can dedicate time to figuring out how BigScoots works, and maybe having a constant conversation with you to optimise the websites that they’ve got and, you know, maybe some of their clients are what we might call enterprise clients and things like that.

If that’s the case, there’s always this merry dance of agencies trying to find the perfect host and kind of figure out, okay, which company do we want to go with this year? And all of that. Do you make it straightforward for people to sort of come to you and say, okay, we’ve got 150 websites, it’s really important that we don’t have any downtime? Do you have some sort of onboarding, migration, something along those lines?

[00:46:30] Saumya Majumder: So we have a lot of enterprise customers, and for every single one of them we have a proper systematic onboarding flow. So that’s making sure that they do, we do migrations with zero downtime, have multiple peer reviews. Then if they have taken our performance optimisation packages and things like that, we would actually optimise their performance and speed metrics for them. And then if they have taken our engineering and services projects, then we would actually do all the, like if they have any technical problems, we would actually go on write code for them, solve their problems.

So we go very hand in hand with our enterprise customers doing onboarding call, making sure they’re happy from end to end. And whether that’s agencies or just normal enterprise customers, it’s for all of them.

And I also want to talk about the settings that you just talked about. So we build all of these things, keeping in mind that they are dead simple to use for anyone. But that doesn’t necessarily mean that they have to do it. A lot of the times customers comes to us and like, hey, we want to do this. As we provide managed support, we actually go into the exact same settings and do that. And that actually solves the problem a lot because now anybody can go to the settings and just do this. Be it our own team or, because it doesn’t have to be escalated, it doesn’t have to come to a specific team. Anybody can do that. And we are constantly growing the more things that people can do to leverage that out. And yes, agencies and enterprise are taking huge advantage of that.

[00:47:54] Nathan Wrigley: Yeah, honestly, it’s absolutely fascinating. You never know, hopefully you and I, our paths will cross at some point in the year 2026. Maybe I’ll see you in Mumbai or something like that.

But what I’m going to do is I’m just going to say, if you’re curious about any of this, I will provide links to everything that we talked about. So if you head over to wptavern.com and you search for the episode with Saumya, so S-A-U-M-Y-A, you’ll be able to find it over there. Honestly, I feel like we’ve just scratched the surface. I feel like there’s another 8 hours in the pair of us, really could get into the weeds of it.

But thank you so much for peeling back the curtain a little bit on what you’re doing and how it all works with Cloudflare. Thank you so much.

[00:48:28] Saumya Majumder: No problem. Thanks for having me.

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case how AI is taking on the burden of troubleshooting website issues, and making suggestions for improvements.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox and use the form there.

So on the podcast today we have Arnas Donauskas. Arnas is a product manager at Hostinger, with over five years of experience in the web hosting industry. His journey began during college while working on his bachelor’s degree, when he needed to create a website and discovered WordPress as a beginner.

His first foray into website building sparked his interest in the industry, eventually leading him to a career where he now develops products that help others launch their own online presence. Recently he’s been working with a team tasked with delivering tools and improvements to WordPress users to ease their journey on starting and maintaining websites.

In this episode, Arnas shares insights from his presentation at WordCamp US in Portland, Oregon, where he discussed the future of fixing and optimizing websites with AI. For many WordPress users, managing site performance and troubleshooting errors can be time consuming and complex. Arnas and his team have been developing AI based solutions that not only help onboard new clients by automating website creation, but also proactively monitor and remediate website issues as they happen.

We get into the details of how Hostinger’s AI tools identify, and automatically fix, critical website errors such as HTTP response issues, and how they’re pushing site optimizations through automated performance enhancements.

Arnas explains the engineering challenges involved, the current state of success with automated fixes, and how user feedback is shaping the roadmap for new features like SEO analysis and accessibility improvements. He provides a behind the scenes look at how Hostinger tests and iterates on AI models, what kind of data is fed to those systems, and how the team balances automation with user control.

If you are curious about how artificial intelligence is transforming WordPress hosting and site management, and what this means for the future of the web, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast where you’ll find all the other episodes as well.

And so without further delay, I bring you Arnas Donauskas.

I am joined on the podcast by Arnas Donauskas Hello.

[00:03:41] Arnas Donauskas: Hello. Thanks for having me today.

[00:03:43] Nathan Wrigley: You are so welcome. We’re here at WordCamp US in Portland, Oregon. It is day two of the, kind of the conference, but it’s the first day of presentations and things like that. You are one of the presenters, and during the presentation you are going to be talking about fixing and optimising websites with AI.

I wonder if we begin the podcast with an introduction to you. So I’d love to find out more about what you do, what your role is at Hostinger, and how you’ve got yourself in the whole AI space.

[00:04:12] Arnas Donauskas: Yeah, would be glad to give a short overview. As Nathan introduced me, I’m Arnas Donauskas and I’m a product manager at Hostinger. And the whole web hosting industry, creating a website, I’ve been for more than five years. Well, I think my first interaction with WordPress was actually in my college when I was writing my bachelor’s degree. I needed a website at that point of time and I thought, okay, what should I do? What should I use? And I was very green back in the day. Everyone has to start somewhere.

And the WordPress came in as one of the first results that I searched on Google. I gave it a go. At first there were some challenges, interesting cases, what should I do with it? But then website got up and running. I finished my bachelors degree, so that was nice.

And at Hostinger I have a team, a squad, where we build various tools for clients who are using WordPress to make their journey smoother, to make their websites management easier, to make a whole, interacting with the online presence easier. So they would have tools that could assist them, you know, on day to day basis, how to get things done and how, you know, to get their first website started and running as fast as possible.

[00:05:24] Nathan Wrigley: So it seems like the hosting space, this is a really perfect fit for AI, because you presumably are onboarding clients and they have no website. I mean, in many cases maybe they have and they’re migrating something from one place to another. But I imagine a lot of your clients are brand new, they’re starting a new project, a new business, or whatever it may be, and they want to get a leg up in building something quickly.

And five years ago, no chance. You had to hire somebody, everything had to be done by a human being. And nowadays we’re seeing the rise of AI in these kind of onboarding processes where you go through some kind of wizard, and at the end it will spit out some approximation of a website which is suitable for your niche or what have you. And then you go in and you tinker and you make sure it’s exactly what you want.

Is that the kind of tooling that you are doing, or are you doing something slightly different to that over at Hostinger?

[00:06:12] Arnas Donauskas: Yes, we do have tools that are able to, and capable of, creating a website with AI prompt. You would tell what your website would like to be, and we have like a WordPress AI website builder that will build you a blog, an e-commerce based on a given prompt. So this is already a really head start of all of the things.

But also looking from another perspective, it’s totally understandable to see people who don’t want to build the website with AI, but would like to get guidance how things get done. From one perspective, you can get guidance, how to build the website itself. From another, do I need to make any DNS zone changes on my website? And at this point of stage, AI can help all the way through. You just simply ask what you would like to do, what are the settings you want to tweak? And AI can give you a really, really detailed step, you know, how to change those things.

One of the really nice examples I have, at Hostinger we have a Kodee, it’s a chat interface assistant that helps clients with various questions, and it does have information about the client itself and, you know, what actions it can do. And what trend I started to notice that clients know it’s an AI, and they start asking specific questions. Like, hey, here’s bulk text, can you edit that for me? Or can you give me more detailed steps how to do this and this? And the AI just gives those steps and clients just like, thumbs up, thanks. Have a nice day. And they just go on their thing.

So I see this trend, and it’s really nice that the users like utilising these tools, because at the end of the day, it helps save time, maybe additional money and, you know, it’s a win for the user.

[00:07:44] Nathan Wrigley: So I’ll just read the first sentence of the blurb. So the title of your presentation here is fixing and optimising websites with AI. And then the first sentence goes like this, and it encapsulates exactly what you’ve just said. This talk explores how AI can be used to automatically fix detected website errors and boost overall site performance.

So we’ve got this whole side of AI, which is the onboarding, we’ll help you build the site. But then it sounds like you’ve also now got tooling to, okay, you’ve got a website, let’s fix it up. Let’s make the improvements and adjustments along the way.

So, okay, then if we are allowing AI to crawl our website in some way, how does that actually work? What is going on? What is your platform doing to find the errors? I realise that’s a very broad question, but I’m going leave it like that.

[00:08:31] Arnas Donauskas: Yeah. So actually why this idea to create such tool came into the light, it was actually one of the feedback points we gathered from one of the WordCamps. Maybe it was Europe. But then to add up to it, we saw the problem when clients, let’s say a website starts receiving an error, or it starts to load slowly, they are not sure where to start troubleshooting this. And we have thought, why not make this process automatic and remove this hassle step for the client?

So how this tool, for troubleshooting the error, how it works. So at all times we are tracking all of our clients’ HTTP status. So basically, if there is no error, it’s 200, in most of the cases. There can be a permanent redirect HTTP status. But at all times we are tracking if it changed to an error code or no. If it did, then we are promptly informing the client, hey, we found an error on your website. It could be a 403 forbidden access, or 500, or a critical error. And we start informing the client, hey, an error was found, you can use our AI troubleshooter to automatically fix it.

So when the client lands to the interface itself, we already gathered all of the logs, we removed all of the information that should not land for the AI, that he’s not using it to troubleshoot the error itself. And then AI has a list of actions it can do, whether it’s troubleshooting or optimising.

And then based on the logs and our AI custom given prompt, it determines, this is the most likely action that will fix the site’s error. Or when it comes to optimising, here are like the listed settings you need to tweak to make that website go faster. And then at the end of the day, the client gets the error fixed or the website optimised.

[00:10:21] Nathan Wrigley: So that’s really interesting. So here we’re talking about some sort of critical error. So your tooling is going out, in the same way that an uptime monitor would’ve done in the past. But the difference here though is that the uptime monitor traditionally just tells you the problem. You might get an email or a phone call or something, but then you’re kind of on your own. You do the troubleshooting.

So the difference here is the AI then, it determines there’s a problem and then it offers suggestions. So you log into your control panel and it’s saying, okay, this is the most likely cause, here’s some things that you can do to remediate that problem.

[00:10:53] Arnas Donauskas: Yes, but those suggestions are also being applied automatically because it’s totally normal, you could just go to ChatGPT, you say, here I have this error, what could I do to fix it? And the AI troubleshooter however, it does not suggest, it gives the action that can be applied on the spot. So if you had a one o’clock, 403 error, at one o’clock, five minutes, you could have it resolved without your actual manual input. So the tool itself automatically applies those fixes and does that for you.

[00:11:26] Nathan Wrigley: Okay, that’s really curious because traditionally, I mean, obviously, I guess website hosting companies have had tooling around uptime monitoring and things like that in the past, but because your identifying piece, and the remediation piece, can access server logs and all of the infrastructure that you’ve got, it can identify the problem, figure out if that’s true, and then just crack on and do it.

So you can implement it, well, without implementing it. You just wake up at eight in the morning, maybe get an email to say, well, at one o’clock this thing happened and then we did this so you were able to have another seven hours sleep, that’s fine. Yeah, that’s really interesting.

[00:12:02] Arnas Donauskas: So one thing that we are also constantly working on is what automatic fixes we are capable to do. Because those are the ones where, you know, our developers work and make them so AI would have more, let’s call it options to pick from, based on the data it has, what went wrong. And this is, you know, where we have a mini roadmap, what we want to implement further, so we could increase the success rate of the fixed websites automatically.

Because this is something we also track about. And I will mention this in my speech. So at this point of day, we have 70% success rate on fixing the website. And how it’s being calculated, that when a first fix was applied, it was an actual success and that error got resolved. So at this point of day it’s 70%, and roughly, in absolute numbers, we are fixing per month 16,000 of the websites.

What’s the nicest part for me is that for 16,000 of websites some time was saved. Clients did not have to dig through a lot of information, and they got the problem resolved on the spot. Because imagine you have like a working business running, or you expect clients to come in and you get an error. What is the first thing you do? Like, it takes time. So this tool, you know, can prevent these problems and shorten the fixing journey.

[00:13:20] Nathan Wrigley: Yeah, not just time, but it presumably stops you losing revenue, and the sort of slightly unquantifiable emotional distress that comes with having a website which isn’t working. And obviously if that’s your industry and your business is, I don’t know, e-commerce or something, it’s very important that comes up.

So 70% sounds good, but obviously it means that 30%, there’s not the ideal outcome. What do you do in those scenarios where the thing was not solved? Do you log that and presumably your team then look at that and figure out over time, okay, how can we get that 30 to 20 to 10 and so on? And do you kind of roll back the remediation so that the thing which didn’t work, we unpick that and we just go back to where you were when the error occurred?

[00:14:00] Arnas Donauskas: Yeah, so very good follow up question on this. So with the 30% that we do, we still run additional fixes. So when we do the first fix, we tracked what changed, and then the further success rate can happen, that the fact the was fixed either on the third try or like the fourth try, so that 30% lowers.

But there are cases that none of the fixes helped, and it’s totally normal. Bigger website could be more complex problems, things like that happen. So then we proactively forward the user to our success specialist team who will assist on the spot. And they have all of the logs, what happened, what was tried, and what fixes were applied on the website on the spot.

In any case, there are backups that can be reverted without any of the fixes applied. So those 10 to 15% that nothing helped at the end of the day, gets a direct help from our success team so we could still solve, or help solve, the problem for the user.

[00:15:03] Nathan Wrigley: It’s kind of incredible that if we were to just rewind the clock five years, the stuff that you’ve just mentioned was nonsense. It could not happen. And yet we’ve got to the point now where you’re saying there’s a 70% success rate. I’m quite surprised it’s as high as that, so that’s amazing. And presumably, the ambition is to drive that up to 80 and 90 and what have you.

But just the mere fact that it’s possible is pretty remarkable, that there’s a technology which, it’s kind of got your back, it’s this agent running in the background whose job it is to figure this stuff out and you don’t have to think about it.

And I guess for your industry, you know, hosting in general, I presume a lot of the other companies are doing these kind of things. Over time, this will become the norm. It will just become a laundry list, one of the ticket items on the sales page. It’s, you know, we’ve got your AI agent monitoring the uptime, remediation is guaranteed. Maybe you’ll even get to like 99% of fixes or something like that in time. And it just kind of pushes what we’re going to expect from hosting companies like you. That’s fascinating. Really interesting.

[00:16:04] Arnas Donauskas: Yeah. And as you’ve mentioned, five years ago, it could have been a lot of, let’s say problems or issues making this happen, because at that point of time you need to chew up a lot of information and, you know, do the thinking on that received information. But now when AI does have quite a powerful approach on this, and it’s able to handle such high amount of information, that’s when you know the heavy lifting is taken to that part, the end user is now getting the fixes done.

As per norm on all of this fixing, I really would like to see that happen because it just helps out. You can spend your time on expanding, moving your business further, thinking of the new ideas what you could do, instead of maintaining the website. You know, there’s like a saying, it’s more fun to buy new parts to your car than replace the old ones or do the maintenance parts. So this is, I think, the same thing the website itself.

[00:16:57] Nathan Wrigley: Yeah, it really does feel like this is going to be the future. And obviously you’ve now got these technologies which can make, well, it’s approximating intelligent decisions. Whereas before it was just sort of, I guess you were going through a binary, is it this? Yes. Okay. Move to the next step. Is it this? No. Okay. Go back to this step. Whereas now there can be this whole load of things that you can throw at it.

And that brings me to the next question really. So you’ve just talked about all the critical things, so the website collapsing. So we do something to remediate that. What about the more, I don’t know, let’s say soft things.

So for example, maybe it’s SEO. You know, we have gone around your website, we’ve scraped it a little bit like maybe Google Bot might do, and we’ve identified SEO problems. Or it could be accessibility problems, or it could be, goodness, I don’t know, you’ve just used inappropriate language here, we’ve got a better idea for a UVP at the top of the webpage. Does it stray into that as well? Is it more than just critical failure problems?

[00:17:50] Arnas Donauskas: At this point of day, it’s more critical problems when the website is just full on down. But like, how I like to view the tools that we are building is whenever you build one tool, you receive clients’ feedback, you receive WordPress community feedback, where you can build more tools on top as a continuation to the first one. This is what I really like about all of this feedback culture.

This is the upcoming thing, and I think it’s only a matter of time when our troubleshooter and the optimiser will appear in the WordPress admin panel, where it will be able to tell you, I see an image has disappeared on your website, just upload it to me, I will fix it to you. Or I see some SEO problems. Or like you’ve mentioned, accessibility problems, or that some of the grammar mistakes were found in some of your posts. Something like that. So this is only a matter of time.

And why such approach was taken at this point of time is, we want to give users a tool that they could trust and be comfortable on using when it comes to the most critical problem or critical matter with the website related errors. So they know, okay, I can trust and use this tool, and fix my problem right away. And when that’s put on, then we can move to extensive features to the troubleshooter and optimiser as well.

[00:19:09] Nathan Wrigley: Would it be fair to say that you are developing solutions like that, though? Is that the kind of thing which is on your product roadmap to get those kind of tools, the SEO, the image fixing, the alt text identifier, the I know, the accessibility identifier, those kind of things. They’re in the background? You are building those? They’re roadmap items are they?

[00:19:26] Arnas Donauskas: I would say they are currently planned. Right now, what we have in the more recent backlog is how to reach my personal goal on this is 90% fixed rate. If you already have some plans, how it’ll be done. So a short sneak peek on it. We basically want to build like a way back machine on our AI troubleshooter, so it would know at any given time what happened to each of the file the customer has on their website. And it would be able to tell you, okay, I see that on this specific date, this single file was changed and that’s what led to a 500 error. I have a safe backup copy for it, I will restore it for you. User confirms. We do the restoration.

Or AI will be able to determine, I have a fully working website backup of your site, these are the orders that could be potentially missed if that is an e-commerce case. And if you want to, we can go ahead and restore the website to a fully working version and get your site back up and running again.

[00:20:26] Nathan Wrigley: We do live in interesting times, that’s for sure. You mentioned in the blurb for the talk, and I read the bit at the beginning, but I’ll just read it again. So your talk explores how AI can be used to automatically fix detected website errors, I think we’ve covered that, and boost overall site performance.

Now that’s a different piece, isn’t it? So if we’re now looking at site performance, presumably we’re talking about from slow to fast. Something wrong to fix. So basically, I’m asking the exact same series of questions, but from a performance point of view, not the site has collapsed and there’s an error. What are the things that you’re looking for there?

[00:20:59] Arnas Donauskas: To be fair with you, everything. So we look at everything when it comes to website performance. So we do like a benchmark result where we have our starting ground when it comes to optimising the website. And we are using Google Page Speed scores. I think it’s one of the most popular tools to benchmark the website to see what is loading slowly on it, what could be the potential problems with it. And then for each website individually, automatic fixes to images, JS, CSS minification are being applied, and the client then sees the improvement, whether it’s 10%, 20%.

So right now what we currently have from the data itself, I believe it’s been running for two to three months right now, and we’ve been gathering data, how the websites are being optimised. So on average, mobile page speed score is being increased by 20, and the desktop is by 10%.

But there’s a catch to it. These optimisation steps are safe. It means nothing bad will happen to the website after the optimisation steps, and the next step would be introducing risky steps that can affect how the website looks.

What I have in mind by that is, lazy loading sometimes can mess up one of the images, it appears slowly or after a while. So these things could happen, but this will be like a separate step informing the client, hey, we did the safe part, but we could push this further with some of the risks. No worries, you will be able to revert everything on the spot if something bad happens. So this will be the next step of it, and I’m really intrigued to see how fast the websites can be.

[00:22:35] Nathan Wrigley: Can you modify your hosting environment to be specific to my website, if you know what I mean? So if my website, for example, is, I don’t know, a brochure website, I’ve got five pages, you could cache that entirely. Really easy to do. But, okay, this website over here, a different one that I’ve got, it’s a WooCommerce website, there’s a whole different load of caching that might go on, there’s a whole different load of optimisations that go on there. Do you take that burden on, or is it more of a, okay, we’ve got this thing, you tick a box and now we’re going to do the performance thing? Will it figure all that stuff out, or are there tick boxes where I can go, do this but don’t do this, do this but don’t do this? How does it work?

[00:23:13] Arnas Donauskas: So each optimisation step to increase the performance is being applied to each website individually. It checks loading slowly. Right now, there is no possibility to customise the optimisation steps that you can do, but we are planning to integrate logic to the AI, or like past information for each type of website type. What caching should be applied on specific pages if the image is a landing one, or is it like a product image? So to give more extensive knowledge to the AI so it would be able to better determine how to approach different website types. But for now, what we check, still settings are unique to each website, but not to such extensive customisation.

[00:23:56] Nathan Wrigley: You’ve laid before us a really interesting engineering challenge. These problems exist in terms of performance, we’ve got to put a bunch of engineers on it, and they’re going to figure out this AI way of solving that. But how do you communicate the work that the AI is done to the people that want to know it’s been done?

Because in a way, I kind of want to know that’s happened to my website, but at the same time, I kind of don’t. I don’t want to be getting six emails a day saying, okay, we updated this image, oh, and then another email, we did x, and we did. But you’ve got to let me know that that’s happened. In some way, you have to communicate the value to me that, look at all this fabulous stuff we’re doing. But I kind of want to know, but I kind of don’t want to know. So it’s a difficult tightrope to tread. I’m just wondering how you manage that.

[00:24:36] Arnas Donauskas: Yeah, yeah. So at the end of each optimisation, client is getting an impacted result, did it increase, and by how much? And they are getting a full log, what was done on the website. And we are also trying to display that log to as most simple things as possible to understand, because some of those settings could sound, you know, very big words. But there’s actually very simple things that were done on the website. So we’re communicating that part to the users at the end of each optimisation as well.

[00:25:05] Nathan Wrigley: Okay, so you’re kind of making it easier to understand basically. You’re hoping to use normal language to explain something fairly technical. Yeah, okay. And summarising it, not sending an email for every single thing. And presumably over time the email’s become less and less anyway because, let’s say I migrate a website to your platform, the AI gets involved, and I’m imagining there’s more at the beginning, it’s front loaded. Oh, look, there’s this and this and this and this. And then slowly over time, oh, there’s less. We did it. It’s done. But, oh, new plugin, new thing. I’m guessing that you communicate less over time.

[00:25:37] Arnas Donauskas: With such optimisation things, yes, via email. I would say it’s less via email, more via interface. And I would say that at this point, it’s enough for a user to grasp the idea of what was done.

Why I say this? Because the amount of time the clients spend in the interface reviewing the optimisations and how many of them interact with it is quite high. I believe with optimisations it’s 70% of the users that actually started the migration, completed, you know, all of the interaction with the interface. And they’re spending approximately like from 10 to 15 minutes with it.

So I would say these are pretty good numbers. But you gave a very good point for the users’ clients who are more advanced. And perhaps it would be a good improvement point to give them an option to download all extensive logs, what was done, to see just what happened actually in depth, not just rephrased wording for some technical parts.

[00:26:36] Nathan Wrigley: Yeah, I think it’s a really difficult tightrope to tread because every time that your AI does something and it had a beneficial impact on my website, that’s good for me, but it’s also good for you because it builds that relationship, doesn’t it? You know, oh, look what the platform’s done. It’s brilliant. I didn’t have to lift a finger. Just came as part of the package. Fabulous. I’m happy with that.

But you just don’t want to overdo that communication because at some point it’s like, oh, you lose sight of it. And then the critical one will arrive where the website’s collapsed and, yeah, it’s another one, it just goes in the bin. So I guess there’s a tightrope to tread, which is kind of interesting.

How do you actually find these errors then? Do you have something akin to Google Bot, which is going and looking at the front end of the website as a human being would see it, if you like, and sort of scraping around inside the DOM, looking at screenshots and, you know, okay, yeah, we see that image isn’t, I don’t know, so just an open-ended question really.

[00:27:28] Arnas Donauskas: Since each of the website that we are troubleshooting are hosted with us, we are able to, you know, detect. Because the primary source that we are using to determine that something bad happened is the HTTP response.

[00:27:41] Nathan Wrigley: Right. That’s straightforward. Yeah.

[00:27:42] Arnas Donauskas: Yeah. So whenever that changes, we are able to know because each of the website is hosted with us on our infrastructure. So this is the most, the quickest and most straightforward approach we can use to determine that something bad happened. So this is the one we are running with. And quite good accuracy, unless there’s like a, some CDNs in that case. And this could be sometimes a problem because not always the true error will come out. But yeah, this is the method we are using.

[00:28:09] Nathan Wrigley: But on the performance side, presumably that’s slightly different because, you know, you mentioned lazy loading images or something, you’ve got to have some metrics and telemetry to say, we’ve got lazy loading images, okay, how do we deal with that?

[00:28:20] Arnas Donauskas: So with the performance part, clients are able to, you know, at any given time to initiate the optimisations. We will do the performance test to see if it actually needs an optimisation, because sometimes clients have very perfectly optimised websites, and they’re working like a speed. But we are occasionally running page speed performance tests, on weekly basis, I believe. And if we detect, okay, this website could be improved, then clients are being informed that, hey, you can do some optimisation steps that are automatic and you can go ahead and start the optimisation process.

[00:28:53] Nathan Wrigley: Okay, got it. Thank you. Curious thing that you are in this game of tennis, I presume, with the AI models. I’m presuming, I could be wrong, but I’m presuming that you are using AIs that we are familiar with. So I’m just going to drop a few names that I know. Things like Gemini, Claude, ChatGPT and things like that. I’m presuming there’s some connection that you’ve got with those. Maybe you have your own, I don’t know.

Given that they seem to change at a breathtaking pace, and in some cases the changes that they seem to ship kind of seem to degrade their capacity to do things. We’ve had a recent ChatGPT 5 update, which I think many people felt perhaps in certain scenarios was a backward step. How do you keep up with this?

[00:29:33] Arnas Donauskas: Testing, straightforward testing, but very good point on the whole different models and the providers on it. We simply do tests with each of the models. We scout around, we see, or it looks very promising, we test how it performs, and there are several points. How fast it can grasp the information and return back to us. So how long the request took time. Some of the models took like 10 seconds, some of them took 5. So we want the client to get the faster result as fast as possible.

And then there’s the second part, it’s the accuracy of the returned information. Because one of the learned lessons I will be sharing in my speech is that, we noticed that when newer models came in, how their accuracy was way better and the time to handle information was very shorter. So since we have like developers who are working on the AI models itself, we just always test to see if there’s something better that we could ship to our users so they would have better outcome on their end as well.

[00:30:35] Nathan Wrigley: Yeah, it’s fairly straightforward, isn’t it? It’s testing, testing, more testing, and go with the thing which provides the best tested answer. But curiously though, you must have applied a ton of engineering time into this endeavor. So there’s a load of people on the ground, that must cost Hostinger quite a bit of money. And then presumably there’s quite a lot of money being sent to these AI agents. But I’m guessing it’s hard to justify a price increase to your end users.

So it must be kind of a fairly difficult business decision. How much of this can you do? Because you could AI forever, you know, and just keep going and going and going and endless cycles. So I’m guessing from a business point of view, there’s a, again, another tightrope to tread. How much can you do? Or is this more a case of, is this stuff a premium thing that you offer? Do you have to pay an additional fee to get access to this stuff?

[00:31:21] Arnas Donauskas: No. No additional fee. AI troubleshooter and optimiser is pre included with all of the hosting plans we offer for our clients base. And the price for that did not change because this tool was introduced.

You’re right, it took some time to deliver final versions of the products, approximately seven to eight months. But it was all worth it, I think, because clients can now automatically do things and don’t have to spend time themselves.

And from a company point of view, we just want to deliver best user experience they could have and, you know, that they could trust us even when the website is down with an error and how we can solve it, and what we can do the quickest or how to, you know, assist user on optimising the site.

[00:32:08] Nathan Wrigley: It’s the market at work, isn’t it? Essentially. You’re trying to make your offering different and unique and offer something which adds value, and so you take the hit, I guess.

Do you want to get to the point where everything is completely automated? I mean, is that a desirable outcome? Would it be something that you’d like to see where the human is completely out of the loop? Or do you always want to have an option for a confirm button or a roll, not rollback, we always want the rollback.

But it always feels like the light at the end of the tunnel here is that the human doesn’t need to be involved at all. It would be desirable if I could get up and be a hundred percent confident that my website, for all of the things that you did overnight, is better. And I don’t have to involve myself in that at all. But equally, there’s a bit of me which always wants the confirm button. I want to be able to see, well, not that one. Yes, that one. We’ll do that.

[00:32:56] Arnas Donauskas: I think confirmable actions will be there all the time, or most of the time. Because at the end of the day, this is the user’s website that the changes are being applied to, and the user is in control. Would you like to do those changes, would you not? One of the thoughts, I believe we discussed with our colleagues, what we have 100% fixed rate? Should we give users an option, just run everything, I trust this completely? It could be an option. But still, at the end of the day, this is the user’s website. It’s their business, it’s their blog, and we want to give best suggestions, but the user is the one who’s saying, yes, I would like to do that, or, no, I don’t want to see this.

[00:33:39] Nathan Wrigley: I guess you’re trying to get to the point where the confirmed decision is just really obvious. You want to go in and be entirely confident that, yep, I’m going to confirm it because I have this trust, but equally, there’s an option to not confirm it. That seems to be where the whole AI thing is going. The humans are always in the loop somewhere and it’s always that final confirmation step. And I think if we lose sight of that, we’re probably in a bit of trouble.

One of the questions I have as well is about WordPress, obviously, we’re at WordCamp US, this great big open source thing. And it brings to mind the question about these models, and the fact that they are entirely proprietary, you know, ChatGPT, Gemini, Claude, and all of these things. They’re having a lot of our data, we’re allowing them into the backend of our websites, but they, I don’t know if they have any open source models which are using. Are you shipping data to them? How does it align with the whole open source thing that WordPress is so keen to promote?

[00:34:31] Arnas Donauskas: Oh, very good question I can say. And it’s true that different models look like different silos. Different companies, they have different approaches what they do. But I really liked one of the comments, I believe I read on the Reddit, on all of the AI stuff. And it applies also on such websites. So for example, you’re a user who likes to explore things, and you want to try and fix websites with AI and do that automatically. A free model for the ChatGPT or any other AI model will be more than enough to run, as long as you have your prompt.

It will take some experiment times, that’s for sure, but everything could be actually run free on this part. So this is more, you know, into the open source area. But of course, when there are paid models and stuff like that, this could be, you know, one day could be tricky.

Perhaps we will have a fully open source that anyone could be willing to use without any additional charges. Time will show on this. But now, a lot of companies, people are creating tools that they allowed to do free trials or free for some time. So I think this is a matter of question on this as well, yeah.

[00:35:40] Nathan Wrigley: Yeah, I mean it really does seem like a really exciting time, in tech in general, but also WordPress in general. But it’s kind of really interesting to see the way that WordPress and hosting company’s interfacing through AI. And it does seem like there’s a lot of interesting stuff happening on your side.

Yeah, it’s been fascinating talking to you today, trying to explore this a little bit more. Where can we find you, Arnas? If we want to reach out and discover more about you or Hostinger, where’s the best place to go?

[00:36:05] Arnas Donauskas: So if you want to reach out directly to me, I’m always happy to do that via LinkedIn. I have my full profile set up so we can reach out through there. If you’re a Hostinger client and you have some feedback, just drop it to our support chat. I’m the one who always reads them, and I might even get directly in touch with you via one of the forms because I always keep an eye of our client’s feedback and I try to contact them as often as possible to follow up on some of the feedbacks they share.

[00:36:32] Nathan Wrigley: Well, Arnas, thank you so much for chatting to me today and prizing open this subject. I feel that this conversation is going to get more and more in depth, and more complicated as the years go by. But in 2025, good to know where we’re at. Thank you.

[00:36:43] Arnas Donauskas: Yeah. Thank you for inviting me. It was an honor.