In this episode, we chat with Brandon Kelly and Brad Bell from Pixel & Tonic about Craft Cloud and its potential to revolutionize web hosting. Learn how Craft Cloud simplifies infrastructure with built-in optimizations, handles scaling seamlessly, and eliminates the headaches of managing third-party services. Whether you’re a marketing director, IT leader, or developer, this conversation breaks down the practical benefits of moving to Craft Cloud and why it’s a game-changer for Craft CMS users.
[Music] Welcome to the Solspace Podcast. Thanks for listening.
Mitchell: Hey everybody, welcome back to The Solspace Podcast. This is Mitchell Kimbrough, founder of Solspace. We're going to talk about Craft's Cloud today, and the guests on the podcast, Brandon Kelly from Pixel & Tonic, Brad Bell from Pixel & Tonic, John Henry Donovan from The Solspace team.
I've assembled this group because on the Pixel & Tonic side, these two guys probably know the best, most up-to-date information about Craft Cloud and the intent of it, sort of the bigger strategy behind it. And on my side, John Henry Donovan is in the middle of deploying a couple of Craft Cloud websites for clients. So he's sort of fresh in there.
And by the way, you two, John Henry just posted in Slack a day ago, maybe yesterday, pretty high opinion of Craft Cloud. Like he's been using it now and been putting it into production for somebody, and we're both really pleased with what you've deployed there. So I just want to start this off with a compliment.
Brandon: Awesome.
Brad: Thank you. We're proud of you too.
Mitchell: So I want to set a little context. You know, a podcast is not just for fun, there's some marketing intent behind this. I want to create some value for the types of people that look to Solspace for a certain kind of expertise on the web.
We have many years behind us working on Craft, and we have many years behind us in deploying Craft in production at an enterprise level. Now that Craft Cloud is on the scene, all that stuff is suddenly going to be easier. So maybe one way to set the context of what I hope we can talk about here is to set it in the shape of a client that we're serving right now.
And probably the best way to distill what matters right now for us is just to kind of recount the kickoff call we had with this client and who was on the call and the sorts of things they asked about with respect to Craft Cloud so we can talk about those different pieces. On this kickoff call with this client, now there's a client who has a pretty big, complicated Craft website. They're big fans of Craft, their editorial team really loves it.
They enjoy using it. They're trained up. It's effective.
It's doing what they need it to do. It adapts to their needs over time. All those things are five by five.
Everything is good there. On the call was the VP of IT, the VP of Marketing, the CEO, and their in-house full-time web developer. Each of those four people had a specific set of things they needed Craft Cloud to be able to do, and it answered all of their concerns very well.
So for each of those roles, I think it's useful to talk about what concerns they had and how Craft Cloud meets those. So I'll just start with the person who really led and owned that phone call, that kickoff call, which is the VP of Marketing. He was sort of the driver of wanting to get Craft Cloud in place.
This business was running their website through their internal IT team on internal servers, and those internal IT people, they have other stuff to do. They have core primary tasks that they want to do. They don't want to be dealing with a marketing site, but they were owning it just for legacy reasons.
So the VP of Marketing was wanting to make problems go away. At one point, he said in a sales conversation I had with him, I would love to just be able to write one check to make this problem go away. And for a lot of people that I'm hearing from, Craft Cloud is doing that.
So let's get into that. So from the marketing VP's point of view, what is Craft Cloud going to be able to do to make problems go away on the web with the website, specifically performance, scale, the ability to sort of package up a bunch of the technology stack into one unit that they don't have to worry about anymore? Brandon, can you speak to that at all?
Brandon: Yeah. I mean, that's absolutely correct. There's a number of people in that person's shoes where they want a Craft site, they don't want to host it.
They don't want to deal with hosting. They want to know that whoever is hosting the site is a complete expert at doing so. They know the system inside out.
And they're giving them the best possible service they could to ensure their website is performant, secure, and everything else that we strive for. So that was kind of the pitch with Craft Cloud is, you know, it's like, look, every single Craft site in the world needs someone to host it. Who better than the people that wrote the software, who know it inside out, and who have spent the vast majority of their time over the last 10 plus years supporting people in various hosting environments, know what to avoid, know what works, and can kind of build this service that is just incredibly optimized for brand new Craft sites.
So we are certainly the experts there, and we're putting our expertise to good use here with Craft Cloud.
Mitchell: What are some examples of those optimizations that you guys know to make that other either developers deploying on a standard shared hosting environment wouldn't know, or other developers in-house like that in-house IT team wouldn't have any clue of what to optimize on Craft that Craft Cloud does now?
Brandon: So there's two components to that answer, and I'll let Brad speak about the performance side of it. But one thing worth mentioning is, it's not even just knowing how to optimize the service. It's knowing what components need to be in place.
Craft out of the box is trying to cater to the lowest common denominator. So it's doing a bunch of work that arguably PHP should not be doing, like running queues, and doing image generations, and sending emails, and all these different things that don't really make sense. PHP was probably not the best tool for those jobs, but we have to do our best because we don't know where this thing is going to be deployed to.
But if you're building a site at scale with a significant user base, you want a dedicated queue runner with like SQS or something like that. You want your assets stored on S3. You want all these different tangential services.
And the goal with Craft Cloud is we're coming in there and providing all these different things out of the box without you having to go through and set them up, create 10 different accounts with 10 different vendors, static page caching being another huge one. You don't have to worry about creating a Fastly account or dealing with Varnish or Blitz or anything like that. We're just going to do that for you.
We're going to set up a CDN for you. We're going to set up all this like automatic CloudFlare, Firewall rules, and all these different DDS protection rules, whatnot. And there's all these different settings that you wouldn't have even known necessarily you had to set up in the first place with your own hosting stack.
Brad: Yeah, another one off just to CICD pipeline. So you get your own, like you don't have to set up GitHub actions or buddy works or anything like that to deploy your site. It's a very GitOps workflow.
So connect your repo, make a change and configure deployments on a when pushing to a branch and then the pipeline kicks in, runs any tests if you have them. And it's a very seamless, seamless process. As far as the speed side, static caching is great.
It's mostly seamless. You know, we cache every possible request that we can and the ones we can't, we've got documentation on how to make those pages cacheable if that's possible. And on the scaling and infrastructure side, two of the big features are Craft Cloud relies heavily on serverless architecture.
And that's what processes the web requests as well as the database side too. So when you get spiky traffic, things scale up automatically to handle it. And when traffic is on the lower side, things kind of scale back down for you.
So it's definitely a lot more efficient that way. And so you're not over provisioning and under provisioning and dealing with trying to manually scale these things up and down. Like it all just happens for you.
John Henry: Is that like the technical term, vertical scaling, or is there any horizontal scaling at all?
Brad: As far as end user is concerned, it's all horizontal scaling. We have some knobs we can pull on our end if we see it would actually help us to scale a little bit vertically here as well.
But yeah, so far we haven't had any of that on any of the vertical side.
Mitchell: What's the difference? I need to unpack some of the technical speak for my marketing director audience out there. What is vertical versus horizontal scaling?
I will also go back on a couple of other technical pieces to clarify, but on this vertical horizontal, what's that?
Brad: Sure. The simplest terms, you have a server serving web requests. It gets a lot of traffic and your response is to increase the memory and CPU and disk available on that server.
That's called vertical scaling.
Mitchell: Bigger box.
Brad: Bigger box. Throw more money and resources at it. Horizontal scaling is you have a box, it gets a lot of traffic. Now let's add a second box and just split the traffic in between those two or a third box.
Without increasing any memory or memory, you can scale vertically and horizontally at the same time. Increase memory and increase the nod boxes. But it's just the direction you...
John Henry: Good example would be for an increase in traffic for, say, Christmas sales, e-commerce sites. You're selling tickets for an event and they're coming out in a particular day or something like that, that they would handle that increase in traffic and scale appropriately.
Brandon: You’re sending an email campaign. We have at this point several clients on Cloud that have very specific, incredibly high spikes in traffic. And it's kind of great to watch on the resource side of things.
These massive spikes that are very clearly affecting the number of Lambda instances or whatever, but do not have any impact on the performance for the site or for any of the other sites.
John Henry: Quick note, just on your consolidation of services, which I'm calling it for your hosting. So you take care of deployments, everything's under one roof. And to use Mitchell's phrase, the client just wants to sign one check.
One of our core strengths at Solspace has been taking on clients who've had different vendors and giving them all the ownership rights back to their different third-party accounts. It might be under a different web development, email addresses, like it's a nightmare sometimes to consolidate everything together. We usually get there in the end, but this is like a huge leap forward that saves us a lot of time to put without having to sign up for a second deployment service, another AWS account, all these other services that we can put everything under one roof again, which is a great achievement in itself.
Brandon: We actually take that one step further in addition to it all being under basically one roof. That roof is an organization in Craft Console, which could just have its own ownership transferred over to your client if you're leaving. Or it could start with them being the owner and you just having administrative rights to it.
So there's never a point where the project needs to go through any kind of technical transfer process whatsoever.
John Henry: Yeah. Excellent.
Mitchell: That's one of the biggest sources of friction that we've seen for many years with clients is because of the problem John Henry just described of who owns what and, oh, our current developer owns the hosting account. It's on his or her credit card. And I don't want to talk to them because they're not answering me and they haven't phoned me back in a week.
And let's forget the whole marketing campaign we had in mind because we can't make a change because we're blocked. That's removed now. So you've unclogged that pipe, right?
That's a really big deal that at a business level, you have that set up. All the technical stuff is awesome for geeks like me, but at a business level, that one check where you just transfer the ownership, it's a big deal because they, in the future, can fire Solspace and go find someone that they like better. They can make that decision and do it right then.
They don't have to wait for the ownership to be transferred over and all that nonsense. So that's a big deal. I did want to unpack a couple of technical things.
The four of us, it's just normal language for us, but stuff like GitHub and repos, for example, full page caching, that sort of stuff is not necessarily fully understood. So GitHub, it's a way for managing the files that make up a website and they're in one place and you can have versions of those files in different, what they call, branches. And you can pull down the entire repo, the whole set of files that make up a website and work locally and the other developers on the team, a distributed team, maybe inside the client site, maybe outside another agency, everybody can work on that in a central place.
And the cool thing about a platform as a service like you guys have is all you do is plug into that repo and you get what you need to deploy it to production. So that's something to unpack. Another thing that was really important to unpack was the concept of caching, full page caching and purging that cache.
So the nature of the Internet, static HTML is the fastest thing to serve across the web. And it's even better if you can serve it from a computer that's sitting right next to the user who's requesting it in the same town or just general region of the world. So all these are caching concepts.
Now something in Craft Cloud that's actually quite elusive to execute well in production on websites is the purging of cache effectively when changes take place in the CMS. Let's talk about that a little bit, because that's one of the biggest pain points of the marketing directors we work with. Hey, I made the change. I don't see it on the homepage.
We're trying to launch the big campaign. The email is about to freaking go out. Where is the change, right?
How do you guys handle that?
Brandon: So when you make a request to your Craft site from your browser, the first thing that that request does is it goes to the closest Cloudflare server. We have something called a Cloudflare worker deployed that takes that incoming request and decides what to do with it. One of those things might be if it's already cached, it'll just respond with, okay, here's what you're looking for.
End of story. No need to talk to Craft. If the page is not cached, it's going to go off further to Craft CMS itself.
Craft will serve the request, respond back, but that response will still go back to the worker before it goes back to your browser. The worker intercepts that request and can decide what it wants to do with that. And so thanks to that worker being kind of this middleman between the browser and Craft CMS itself, we can do things like when you're in the control panel and you are editing content, Craft is able to reply in its response to be able to include certain headers that knowing those headers are going to hit the worker before going back to the browser gives the worker a chance to look at the headers and determine what data, which content was just updated or deleted or whatever else, and can then go off and make sure that all the appropriate caches have been invalidated at the same time.
So it's basically an invisible process to the user, but just by using the control panel, just by editing content in the save response or whatever, we are automatically going in and clearing the appropriate caches. It's very intelligent. And it's all kind of just tag-based.
It's actually using, it's piggybacking off of the same internal caching feature that Craft has out of the box through its template cache tags, which have like a kind of a tag-based invalidation algorithm. And so if you're, you're actually able to kind of test and see how it would work locally just by using cache tags if you wanted to. But yeah, it all kind of works automagically.
We err on the side of clearing more caches than we necessarily need to, just because the most frustrating thing in the world is what you just described, expecting the cache to get cleared, and it's not, and you're not really sure why. So we'll err on the side of clearing things.
John Henry: Is there a way to warm your caches?
Brandon: Is there a way to warm your caches? Not built into CraftCloud, no.
Brad: There's external ways you can do it.
Brandon: But there's also just not as much of a need to do that in the first place.
Mitchell: Exactly.
Brandon: Because the individual requests are handled pretty quickly, even when they hit Craft.
Mitchell: So you have a pretty aggressive caching layer in front of the whole infrastructure. And John Henry's question is like what he and I have been dealing with for 20 years. But that's also gone away because the underlying dynamic serving of content, when that's necessary, when the cache doesn't have it, or when it's a page that you never want to cache, that's coming out of a serverless Lambda instance.
And that's another technical thing I want to unpack for those people whose job isn't this, but they are relying on this technology. So let's talk about what serverless means. And anytime someone asks me, I understand it.
When I try to go to explain it, it starts to elude me. So who wants to own that?
Brad: I will attempt.
Mitchell: You want to take a shot first?
Brad: I will attempt to come up with an analogy everyone can relate to. And I will probably fail. Okay, so you have a server or a computer that's got all these parts in it, and it's serving request and that server is running 24 seven, no matter what, because it doesn't know when a web request comes in, and it doesn't know when it needs to service, so you got to keep it on all the time.
In a serverless architecture, there's another layer of abstraction. So yes, technically, there is a server on AWS or Google Clouds or anyone that supports it. But when a request comes in, you are given a tiny little slice of that server to serve the request.
And then when the request is done, your slice goes away. So it goes back into this massive pool on the back end that is abstracted away to everybody. So it is a way for your application to consume as little resources as possible as quickly as possible.
And the more requests that come in, the more little tiny slices you get to scale up and handle those requests. And the less that comes in, or slices, go away and go back into the more generic. How is that?
That's good.
Mitchell: No, that's really good. That's really helpful.
Brandon: Wasn't really an analogy, though.
Mitchell: So John Henry asked about cache warming, which is to say, is the thing sitting in cache ready to go? And with Lambda, you have the same problem. When I messed around and I tried to get Craft working on Lambda and saw how difficult it was going to be, so I didn't stick with it.
But I did get it running. And the biggest problem I had was, oh, I have to wait for the cold start. I have to wait for Lambda to boot up.
And I'm running PHP inside this Lambda instance, which is very foolish on my part. But it works. How do you handle the cold start?
Like if the Lambda instance on a website that doesn't get a ton of traffic until they send the email marketing blast out, and now it really needs to respond to thousands of requests from zero, how is it ready to handle those requests quickly?
Brad: I would say Lambda cold starts are not as much of an issue as they used to be. Like they're actually much faster now. But even in order to mitigate that on Cloud, when you go and create a Craft Cloud project under the environment settings, you can mark that as the production environment.
And when that checkbox is checked, we will basically ping your production Lambda function every, I forget, five or 10 minutes, just to keep it in a constantly warm state for you.
Mitchell: Oh, cool.
Brad: That does not happen on non-production environments.
So those will actually shut down and you might get hit with an extra 100 millisecond latency for cold start once.
John Henry: What if I have a very poorly written template and I'm hiding all my crimes about eager loading, queries and stuff, and I'm hiding all those crimes with caching, and I'm relying on warming for that?
Brad: Well, you should fix your templates.
John Henry: True that.
Brad: But broadly speaking, adding multiple layers of cache doesn't usually end up well, because you're like, this one invalidated, this one didn't, blah, blah, blah. So I think on a per project basis, I think you would want to decide, do I want to rely on Craft Clouds, native static caching features here? And for the requests that miss that, does the template perform well enough?
Is it worth adding the complexity of template caching there on top of it? Probably not, I would assume. But maybe eager loading is the right thing to do.
John Henry: Well, I never describe caching as a solution. I always described it as a strategy, and it's going to be different for every project you take on, in other words.
Brandon: Yeah, to Mitchell's point earlier, you want the HTML to be readily available, and the closer it is to you, the better. One of the biggest advantages of the static caching is that it goes into our CDN, and it's going to be geolocated all over the world, wherever the visitors actually are. So I would say the benefits to static caching are less to try and hide your crimes, as much as just to make the content as readily available as quickly as possible all over the world.
And there really are some real benefits to doing that. So you want to think of it like that. It's a way to get extreme performance out of something, not necessarily a way to hide that code.
John Henry: One thing I came up across, and there may be a marketing thing, and this isn't coming down to you, was I wasn't sure if Craft Cloud was just for Craft 5, or I can take my existing Craft 4 project and not have to upgrade straight away. I could put Craft 4 on Craft Cloud. And that wasn't immediately obvious to me when I went to the Craft Cloud website.
I presume it's Craft 4 and above ready, so that I can wait and upgrade to Craft 5 my own time.
Brandon: The exact version changes every now and then. It changed a lot more in the earlier days, but I believe it's 4.4 right now.
Brad: Might be 4.5, I forget.
John Henry: But I don't need Craft 5 to sign up to Craft Cloud.
Brad: The one slightly awkward part there is, since Craft CMS team edition did not exist in Craft 4, you cannot run Craft Cloud team edition on Craft 4.
Mitchell: All right, so going back to the kickoff call with this client we're working with, we're talking about the VP of marketing set of questions, which is, can you just make the problems go away? And we talked about how the answer is yes. The problems that marketing directors and the VPs face, you have found ways to make those go away with respect to the website.
Also on the call was the VP of IT. And the VP of IT on this call is with a bunch of other calls like it. They drop in and they say, I have a hard stop in 10 minutes.
I have two questions and I'm out of here. And so this person, John Henry, you may remember or not, but this person had the two questions of tell me about security, tell me about like scans, tell me about intrusion, that kind of stuff, and backup recovery, right? So something crashes somewhere, some database dies.
What happens? How do we get it back? So can we get into the concerns of the VP of IT?
Brad: Yeah, we'd love to. Security, multiple levels. And in Craft itself, in our knowledge base, we have two articles, how to secure your Craft site and the security fact.
And so those go through the myriad of ways you can configure Craft. And if you're self-hosting and configure your self-hosted Craft install to make sure it is as secure as possible. Back to one of Brandon's earlier points, since Craft CMS has traditionally been self-hosted for a decade plus, we had to pick some lowest common denominator settings because we didn't know where it was going to be called.
Maybe not necessarily the most secure, although we tried to just err on the side of that anyway. Definitely check those articles out and Craft installs get audited all the time by clients. And frequently those results are kind of shared with us and they either need help interpreting them to see if it's something on the front end versus the control panel and something we need to address.
On the Cloud hosting side, so all of our Cloud infrastructure is protected by enterprise grade Cloudflare WAF. And we have a relationship with them and we have a broad, good default set of rules that apply to every.
Mitchell: That's a web application firewall (WAF).
Brad: Yeah, firewall. The IT guy would know this. And so we have a broad set of security rules in place across everything based on Cloudflare rules, based on OWASP rules.
But on an individual basis, we can go through and apply custom firewall WAF rules to specific sites to mitigate attacks. And Cloudflare's thing is they're kind of known for mitigating DDoS and bot traffic and all this stuff. It's kind of their bread and butter.
So on that side, every Craft Cloud site comes out of the gate with a strong security posture.
Mitchell: What about recovery?
Brad: Multiple layers there.
Every production Craft Cloud environment gets a database backup every 24 hours. You can trigger manual ones as often as you want, and we keep those for 30 days by default, and then they start to get cleaned up. That's the first layer.
And of course, you can connect externally with whatever tools you want and run whatever custom backup scripts that you need to offload them to multiple places. There's nothing stopping you from doing that. And then more on the infrastructure side, like we have extra redundancy on our side that's not very user-facing, but entire cluster snapshots that happen very frequently.
And you can always, obviously, since you've got access to your database, you can restore it anytime you want to.
Mitchell: So structurally, back in olden times, even before we had adopted our repos, GitHub and so forth, we were working directly on servers. And the server dies, somebody unplugs it or spills coffee on it, you're toast. So maybe you have a backup of the database, but wherever those files were, it's dead.
The whole structure of Craft Cloud, as well as platform as a service type tools, so much is distributed. So the core files that make up the website and the templates you've been working on for years and all those sort of components, they're sitting in a GitHub repo. It's distributed across multiple developers, local machines, as well as in GitHub itself or whatever repos system you're using.
And then it's deployed out to Craft Cloud. And those are ephemeral, right? So you have a Lambda instance spinning up to serve that thing.
And then it's cached. So you have all these layers of distributed redundancy compared to how things used to be. To create what you have maybe 10 years ago, the cost would have been incredibly high.
How much does this thing cost? This is the CEO's question on the kickoff call is how much does this cost? And the interesting part was, because it was hosted internally by internal IT, it was thousands of dollars to them, but they couldn't put a number on it because it was internal IT.
You know, if Mike has to come in on Sunday, how much does that cost in overtime? How much does that cost in disruption from other stuff he's supposed to be working on or whatever? So how much does this cost and how does it compare?
Brandon: So there's two plans. First of all, we have the team edition, which is a feature comparable to the Craft CMS team edition as well, limited to five users, but otherwise pretty much feature comparable. And then there's also pro and each of those have monthly prices and annual prices.
So if you're good with team, you're looking at $130 a month, or I believe $120 a month if paid annually. And with Cloud pro you're looking at $260 bucks a month or $240 paid annually. And that covers the full set of features.
It covers some base level asset storage. There's asset storage upgrades available as well, but it covers all your support. It covers site outage on a Sunday calling in and we'll have someone ready to look into it and everything else.
Mitchell: Okay. So the cost is competitive, especially if you bothered to set up all the components yourself.
Brandon: Oh, I mean, if you were setting up the same S3 and Lambda RDS and Cloud flare, and if you were set up all these services, you're looking at just in service costs, thousands of dollars a month. If you're looking at it from an apples to apples comparison, trying to set up the same infrastructure for yourself from a one-off basis, the cost comparison is beyond competitive. It's a no brainer.
Brad: It's quite a deal.
Brandon: It's quite a good deal.
Mitchell: The third tier of cost is enterprise level. So how often are you guys working with companies who need their own special SLA? So they need an enterprise contract with you.
Is that frequent or is that not too frequent?
Brandon: Yeah, it's pretty frequent. I would say in a given month, we're getting one or two new enterprise clients, maybe. And some percentage of those are beyond just a custom SLA.
They're actually a hosting agreement. And sometimes those are going to something that looks pretty similar to the Cloud infrastructure. Sometimes they are a little bit more custom.
Just depends on their needs. But we've actually been in the hosting business on the enterprise side of things for six, seven years. Much longer.
Mitchell: Some years ago, I had someone from Cloudflare on the podcast. And one of the best things that I learned from them was as a business strategy at Cloudflare, they try to reduce the amount of custom enterprise work they do. They would rather fold something into the core product that an enterprise client has requested so that it's available for everybody than to do this one-off stuff.
Even though those contracts look pretty lucrative, over time, from their point of view, financially, it's much better to make it part of the core product. Do you see any of that push-pull in your work? Would you rather be able to build something extra into Craft Cloud so that it answered the enterprise requirement?
Brandon: So the times when we need to do a custom infrastructure setup for an enterprise client, it's going to be more of a resource requirement problem. This client is beyond needing a serverless architecture. We know that they're going to need a certain number of visitors every hour, and it just makes sense to give them dedicated resources.
On a feature perspective, at least with Craft CMS, we've never built anything for an enterprise client that didn't just make it into the core product. We've certainly added core product features that were painfully, obviously, needed, thanks to an enterprise client. But we definitely agree.
We don't want to support a bunch of different custom plugins and modules for various enterprise clients. So the more work we can do centrally, the better.
Brad: There is a world, because we have an enterprise client look at the UI of Craft Console and the UI of Craft Cloud and Craft Console. Although it would be great if we had that. So there is a world in the future where we do start to bridge these two worlds together, not just UI-wise, but potentially infrastructure-wise, too.
We'll just have to see where it makes sense and what are the common things we can do there. The enterprise clients do tend to have the most custom requirements for all this.
Mitchell: So the last person on this kickoff call that we were going to talk about was the actual in-house web developer who owns the website day-to-day. So there's two questions from this person's point of view, and they're kind of the same. When you guys were working on Craft Cloud some years ago with a previous concept, like a previous iteration of the idea and the strategy, our first question to Solspace was like, hey, can we sell plug-ins on it?
That's a big revenue stream for us, Freeform Calendar. Is it compatible? And the answer was, maybe.
I don't know. We'll see. But for sure, totally, 100% on the current iteration of Craft Cloud, it's a no-brainer.
This web developer who's going to be asked to solve a problem by the marketing director, VP of marketing, or whoever, sometimes the answer is, yeah, there's a plug-in for that, and I don't have to spend all weekend writing code. I can just $30, $100 for a plug-in. We got the solution here.
So let's talk a little bit about how easy it is for someone working comfortable with Craft as a development environment to switch over and do it all on Craft Cloud. And the other piece that is connected to that that I was really interested to hear you guys talking about on another podcast was how you've seen a lot of new opportunities for Craft itself based on the Craft Cloud infrastructure. So you've apparently opened some doors for things you couldn't have thought of, or it could not have occurred to you to do with the platform itself without this platform as a service infrastructure.
So let's get into both of those, because the web developer, my team's made up entirely of those people. That's what they think about. And when they choose Craft versus WordPress versus something else, this is some of the criteria.
Brad: I can take the first one. If you go to our knowledge base, Craftcms.com slash knowledge dash base, we have a whole knowledge base article for plug-in development for Craft Cloud. There's really only a couple of things to consider, and most plugins will just work out of the box anyway.
The areas that plug-in developers might need to adjust is if you're relying on a long-lasting file system. So you write something to disk, and then an hour later, you expect it to be there. That's not going to happen because Lambda is ephemeral, and at most, you're guaranteed, I think, 15 minutes.
So adjusting where things might get stored if you have to write them to the file system. And that includes logs, like some plugins. So in Craft Cloud, logs get streamed out to standard out, standard in, and there's a UI for it.
But some plugins are just writing logging files to the file system too. So that might need to be adjusted. There's a couple of things if you deal heavily with assets, uploading to the S3 buckets and stuff like that.
But otherwise, most things just work. And in the plugin store, if you're curious if a plugin works on Craft Cloud, go view the plugin details. And on the right-hand side, there's a, hey, works on Craft 4, works on Craft 5, has GraphQL support.
Another little checkbox there is tested on Craft Cloud.
John Henry: Is that tested by yourselves, Brad, or?
Brad: No, no. So this is plugin developers will test, and we give free Craft Cloud sandbox accounts for plugins. So anybody that wants to test their plugin on Craft Cloud, just write into us, and you'll get a free account, and you can test it.
But even the ones that don't have it, they'll probably generally just work. But that's just a good checkbox to have too.
John Henry: And I don't know if we mentioned it, but you have your own plugin that kind of makes everything in Craft Cloud and Craft work together and just makes everything work behind the scenes. And do you want to talk a little bit about that?
Brandon: That's the Yee extension, I think we're referring to. Yeah, it basically injects the correct file system driver that you can use.
It generally kind of configures Craft for best use within Craft Cloud. It also aids the builder. So one of the things we do when you're deploying, we will scan your whole project for all of the different asset bundles, which is the Yee term for it.
But basically any images and CSS files and JavaScript files and all the sort of stuff that's used to render the control panel, to render plugins. And we scoop all those out, and we throw them on S3 pre-rendered, pre-deployed. And so that's aided by that extension.
And there's a few other things it does as well. Basically, yeah, it's just there to make it a really seamless experience. You don't have to worry about things.
Brad: It helps with the queue interaction too.
Brandon: There was a second part to your question.
Mitchell: Yeah, the second part to my question was, so let's go back and think about this web developer. And in our case, this kickoff call was for a client who already was invested in Craft.
It had already won them over. Everybody was happy. They loved it.
Sometimes an internal web developer is saying, all right, we need to get off of this POS whatever it is. We need to get on something better. And now we have the opportunity because the budget has been freed up to do it.
I want to use Craft. And here's why I want to use Craft. The reason I want to use Craft is I want to put it on Craft Cloud.
And here's the reason why I like that. That combination of things, Pixel and Tonic is going to be developing on that platform and releasing capabilities because of Craft Cloud that they wouldn't have been able to do otherwise and other CMS providers can't do. What are those things?
Brandon: So I don't think that there's anything on our roadmap that is specifically going to be a Craft Cloud exclusive feature, but it does certainly just looking to the things that it's already doing out of the box with providing an SQS-based queue and S3 support and all that sort of thing.
Mitchell: What is that?
Brandon: SQS stands for a simple queue service, but it's Amazon's service for basically managing, running these kind of background jobs on your site to update search index keywords or do various things like that. In larger sites, you want that to be kind of done through a dedicated service as opposed to just like being handled over an AJAX request in the control panel, which relies on someone actually being in the control panel with the browser open.
So like Craft had support for SQS and different queue drivers forever, but it's one more thing you have to set up when you're deploying. It's something that might not even be obviously needed if the site starts a little bit smaller and then the content grows over time. And so Clouds, one of its killer features, I think, is the fact that we are just anticipating those needs and building them into the product.
So there's less configuration, there's less accounts you need to set up, stuff like that. I would say as far as where we could take Craft Cloud going forward, where Cloud offers us a unique opportunity that we didn't have before, that would be in the areas of automatically spinning up a project so you can test things without needing to create to get repo ahead of time and deploy and figure all that stuff out. If you just want to kind of see how everything's together, go play with Craft Cloud.
You'll create a simple project and start writing content on it and stuff like that. That's the direction we want to take things. So simpler onboarding.
Then there's additional features like the SQS example that maybe we want to add down the road, like better scheduling support. So if you have certain routines that you want to run every day at midnight, for example, that's something that you can hook up right now with Craft CMS, but it requires a bit of work, requires setting up a cron job, it requires adding a library that would handle those requests. And that's an opportunity for us to add this functionality to Cloud where we kind of handle all that stuff for you.
There's several things like that, but down the road, Craft could continue to gain features. And if you're on Cloud, you're just going to get them for free. You don't have to worry about setting up another service.
Mitchell: How much trouble is it to have a staging site alongside the production site? I mean, this is one of the friction points for a lot of clients is they don't have staging. They don't have a development environment.
And we really, really want them to have that set up. So we have to add that to the proposal. And it's a line item and all that stuff.
What's going on with that with regard to Craft Cloud?
Brandon: So every Craft Cloud project comes with two or three environments, depending on which edition you're running. If you're on Craft Cloud team, you get one additional staging environment. And if you're on pro, you get two.
Those are just built into the cost. All of the asset storage and cron job support and everything else is all just kind of like duplicated for each of those environments. So you don't have to pay extra for those.
And you can attach each of those extra environments to a specific branch in your repository and just have it automatically update whenever, let's say, you have a staging branch and you have a testing branch or an experiment branch or whatever it is. Anytime those branches get updated, we'll just automatically deploy them to the configured environment. You can point domain names to them or subdomains to them.
And we also will give each of those environments what we call a preview URL, which is just a subdomain.Craft.Cloud URL that you can use to preview the environment as well.
John Henry: That was handy recently. recently I've one question on your security or CDN and everything is built on Cloudflare.
But if we're coming from a client, normally we'd install Cloudflare on the client side anyway. We would add all the kind of WAF rules. We might add a few workers, one for security headers on the website.
Do we still have the option to do that?
Brandon: Yeah, you sure do. You can have your Cloudflare project be basically a proxy for Craft Cloud itself and have basically two layers of Cloudflare.
Brad: Yeah, so Cloudflare calls this the orange to orange scenario. And they have a whole page on their docs for this. And there's a surprising number of Craft Cloud projects just do this already, maybe 50%.
So they'll have their own pro or business or even free plan. And they kind of put that one in front of ours. And it doesn't work for all of Cloudflare's products.
But if you go to that page, it will show you all of the products it does work with and the ones it has caveats with. But for every product that Craft Cloud uses, it is a supported scenario. The one place it gets awkward and is still totally doable is just with DNS and SSL certificate verification.
You just have to jump through a few extra hoops.
John Henry: Okay, yeah. Okay, because I can imagine this being a scenario for a lot of our clients who would be on Cloudflare already and we'd have specific, they'd be using Cloudflare access and things like that.
Brad: Yeah, yeah. People have their own workers. They've got their own firewall rules already.
And so in the firewall example, that hits your zone first. Your rules apply. And it gets passed on to our zone.
And then our rules apply past that.
John Henry: Okay, so orange to orange.
Mitchell: Do I have to renew my SSL certificate every year? Does the marketing director have to remember to do that? Is that baked in?
Is that just part of the flow?
Brad: We take care of that for you. All handled. And on the back end, it's all handled basically through Cloudflare.
John Henry: Like that's encrypt servers and whatever.
Brad: Yeah, yeah. I mean, they have different certificate authorities and things to use.
Mitchell: So some clients out there running Craft websites are doing so on shared hosting environments, or there's a lot on AWS and their IT team is managing that AWS stack. And they want to move to Craft Cloud. Do they contact you?
Will you migrate their site for them? Will you upgrade it, get all that stuff and get it set up on Craft Cloud for them?
Brandon: We've got pretty thorough documentation. And so the expectation is that most sites would just do this on their own. They work with their web agency and get things moved over.
We do have some planned updates to the partner network where we want to do a better job surfacing partners that provide those sorts of services as well. So that's where we would default to pointing you to next if you don't have the means to do it yourself and you don't have an existing agency that you're working with.
John Henry: There is a sweet spot in terms of coming from a developer point of view is where you're on Craft 4 and you want to upgrade to Craft 5. And you can acquire Craft Cloud services and you can build your Craft 5 site upgraded and be ready to go when you're ready to make that switch. That's kind of a sweet spot for us.
If someone's looking to move from Craft 4 to 5, yeah.
Brandon: It's a great hook to get your relationship started with a new client for sure.
Brad: And if there are any pre or post sales technical questions while migrating to Craft Cloud, of course, write into support, we're going to help you through that.
Mitchell: Well, I think that covers it. We got all those questions answered. And I kind of wish you guys had been on that kickoff call because they would have been a lot more thorough answers than what they got.
But they're pretty happy. John-Henry, how far along is that? They're not in production yet, right?
John Henry: No, they're quite happy. I did the kind of initial works at the upstage environment and stuff. And they've cut their teeth into it. They're doing deploys.
They're quite happy with everything there. The biggest thing is they don't have to think about anything. They haven't come back to me to ask anything about Craft Cloud because they don't have to.
Because everything just kind of works.
Mitchell: Yeah. Yeah.
Just works is the high bar that we're trying to achieve in our work these days. So I'm really proud of you guys for doing that. You really nailed it.
Brandon: Thanks.
Mitchell: Yeah. Congratulations.
So thank you for being on the podcast. Brandon, Brad, John-Henry, appreciate your time. Headed into the holidays.
I hope you guys can take some time off and enjoy family and chill out. You've earned it. So thanks again.
Thank you.
[Music] You've been listening to the Solspace Podcast.