0:03My name is Joe Dixon and I'm VP of product at Laravel in case you're not familiar with Laravel we are first and foremost a batteries included PHP framework and we're used by millions of developers every day and so what do I mean by batteries included well really Laravel ships with everything that you need to build you know full stack web applications everything from database ORMs to authentication to broadcasting to queued jobs. Everything is right there, ready for you to use. And so it really takes the pain out of building web applications, both in the sense of traditional web application development, but also in this kind of agentic era that we're in right now. The rich 15-year history of guardrails and opinions baked into the framework and the documentation that we've produced over that period really makes it a productive agentic stack too.

0:56So yeah, like I said, very productive development stack. But what about the deployment story? Now, maybe we could just take a second and pause for everybody today who may be familiar with the PHP vulnerability that was announced and everybody who's dealing with hosting PHP applications, what they've been dealing with over the last 24 hours or so. And we happen to be one of those companies too. So for the last 10 years or so, we've had a product called Laravel Forge, which basically allows you to provision VPS servers in a way that's optimized for running Laravel app. applications we've also had a product called laravel vapor which does something very similar but running your laravel apps on aws lambda both of those products were very much bring your own cloud and we'll do the provisioning for you but we've had more recently more ambitious goals to build a fully managed platform and that was really the inception of what has now become laravel cloud um cloud is a platform that's now about two and a half years old we built it in just shy of a year and the goal for cloud is to basically allow you to connect your code push your code see everything live and not have to worry about maintaining any of it operating any of it will take care of the infrastructure under the hood and it's built for hobbyists so we have proprietary technology built into our stack that allows applications to fully scale to zero and so customers are not charged for compute but we've built it in such a way that we have you know half second cold stop So you're not really paying a penalty for using that software or using that functionality.

2:25We also support the most demanding of workloads with our kind of mature scaling configurations options that we have built into the platform. We support or we have database options, caching options, web sockets, object storage, custom domains, SSL certificates, everything that you could possibly need to build and run your application on cloud. and we're not laravel specific it's been a very laravel focused 24 hours as i mentioned or php focused 24 hours we're not even php specific we've built the platform or kind of um pivoted the platform a little bit more recently to support your entire stack so what we were seeing was you know lots of people have laravel as the main part of their application stack but they'll have lots of different microservice built in different languages and we want to be able to support those too and that's more prevalent than ever as we found us find ourselves in this agentic era where people are writing more and more applications or more and more services for their applications where the language isn't just not so important anymore.

3:25So as I mentioned, we built cloud it just shy of a year, which meant solving a whole bunch of complex problems, mostly in parallel. Things like compute, storage, networking, security, and billing, some of them that spring to top of mind, but really just the tip of the iceberg. And I could spend all day talking to you about some of the interesting problems that we had to solve in doing that but for the purposes of the next 16 minutes or so i want to kind of zoom into one part of the platform and it's really the part of the platform where uh our partnership with cloudflare has uh we've been able to leverage the most and it's been probably the biggest differentiator to the platform as a whole

4:03perhaps unsurprisingly that is ingress how do we take a request from somewhere in the public internet anywhere in the world route that through to our internal infrastructure to a deployment running on our Kubernetes-based infrastructure in any region, in any cluster of that sprawling infrastructure. Another complex problem to solve.

4:27So I want to dig in and tell you a little bit more about that story and how things played out for us. And to do that, I'll start with the two parts of the problem which were perhaps the easiest for us to solve. First off, I've already mentioned that we partnered cloudflare that was a decision that we made very very early on in during the build um we didn't really feel like we had the resource or the time to be able to build our own edge network nor did we really feel like that was the place where we could add value um so we decided that the right idea was to partner with what we deemed to be the gold standard in edge networking um of cloudflare specifically we use a product called cloudflare for sas which basically allows us to um create multiple host names within a single Cloudflare zone and that will become important later on in the presentation.

5:13Over on the right -hand side of the screen here you can see our internal networking. Basically I've already mentioned we run in multiple regions across the globe. We have clusters running in each of those regions, many clusters running in each of those regions and each Kubernetes cluster has its own router and the router's responsibility is to essentially accept any coming request, read the host name off the request, and shuffle that traffic to the correct deployment on the cluster. This isn't groundbreaking stuff. These are patterns that exist in Kubernetes. It gets complex, obviously, running this stuff at scale and making sure there's no bottlenecks. But these two parts of the equation are kind of well-trodden paths. The part that I want to zoom into a little bit more is those kind of three question marks in the middle.

6:00How do we actually take a request that hits Cloudflare Edge and route it? our internal infrastructure well our first pass at this was to build it essentially we would have the traffic coming into cloudflare we would proxy that traffic from cloudflare into a network load balancer and that network load balancer would in turn proxy the traffic through to an auto scaling group of ec2 instances running nginx that as part of that process we would how we have a Redis KB store, which is basically tracking every single host name on the platform and which cluster that host name is running on. And so we would do that lookup, the Nginx

6:45instance would then shuffle that traffic across through to the relevant router that we talked about on the previous slide. Relatively straightforward, a bunch of operational overhead that we didn't necessarily want to deal with, but felt like this was the best way to solve And we had all this working. We had done the relevant load testing. We were comfortable that this was the direction that we were going to take. Everything was working until it wasn't. And we had this seemingly innocuous problem where we just couldn't figure out how to terminate the mutual TLS certificate between Cloudflare and between our internal private network. The thing that's really important to give us the confidence that the request is coming from a trusted source. Just couldn't figure out how to get it. work so we jumped on well we did what anybody else would do and we called up cloudflare and said can we speak to our solutions engineering team to try and unpack this together and that's the point that we uh we drafted in a guy called ethan kennedy now i wanted to give him a call out explicitly because he was incredibly pivotal in that initial year phase of building out laravel cloud um he knew the product the cloudflare product inside out he understood all of the gotchas that we would run into and how to work around them.

7:58And on this day, when we spoke to them about our MTLS problem, it proved to be exactly as normal. We presented Ethan with our network diagram and said, this is the problem that we're trying to solve. And I have no doubts that Ethan would have solved that problem for us, but it turned out that he didn't, he just didn't need to. Almost in passing, Ethan uttered the words, have you heard of Cloudflare Tunnel? And the rest of that... That kind of, the network diagram I showed you previously with the question marks, the rest of that is kind of history from there on out. Of course, we had all heard of Cloud Play Tunnel. We were very aware of how it worked, the problems that it solves, the privacy and the security benefits that we would get from it. We even knew that it could be used in configurations like ours with a Kubernetes stack behind it.

8:45What we didn't know is that it could run at the scale that we knew we would want it to at some stage. Ethan gave us the confidence there and then. that it would absolutely be fine and there would be no issues with scaling and that people were doing this in very similar situations to us too. And so we took that confidence from the call and we revisited our network diagram and our implementation.

9:09So just to remind you, this is what we currently had, our network load balancer or auto scaling group of EC2 instances

9:17and yeah, routing, we're shuffling that traffic through to our internal cluster routing. So we ripped that up and we ended up with this. The important part of the interesting part here is the part in the middle where now each one of the clusters that we have in our infrastructure stack has a Cloudflare D agent running on it. And that Cloudflare D agent is responsible for establishing the tunnel between our private infrastructure and Cloudflare. So this is totally private. There's no open ports. There's no public access to this tunnel. at all now the public request comes in it hits cloud blur as it always has done um but rather than hitting that nlb we proxy that traffic through to the relevant tunnel it's connected to the cluster that that request should go to and so just like that just through that one conversation with ethan we managed to simplify the operational overhead of our platform we reduced a bunch of costs because we were able to take out that infrastructure that we needed to you know handle that routing us and we ended up with something more secure and stable and resilient and proven

10:24so yeah that was a really really big win for us

10:35but it didn't stop there as we launched the platform and we started to gain some traction we started to hit some scale as i'm sure you can all imagine you hit different kinds of bottlenecks you didn't perhaps see coming from the get -go. One of those was actually the part that I talked about at the very beginning, our private networking part with our cluster-based routing, that I said was a well -trodden path, did actually mean it when I said it does get difficult to do some of this stuff at scale. And what we actually found was when customers were regularly deploying their applications or attaching, detaching custom domains from their applications, we were continually having to rebuild these ingress objects on each one of those cluster routes. and at some scale that became an expensive performance bottleneck that we needed to address and so we had to think outside the box a little bit on this one and for that i want to introduce you to this glorious little four kilobyte json object that we have accessible to us in our partnership with or in our usage of cloudflow for sas let me take you back a step and tell you how that works behind the scenes so when a customer has an application on laravel cloud and they want to attach a custom domain they'll do that with an iui and behind the scenes we're making an api call to cloudflare to create a custom host name within our cloudflare zone using cloudflare for sas when we do that we also set the origin and the origin in this case will be the cloudflare tunnel we want that request to go through to but what we can also do is send this json object this custom metadata json object so what we do is

12:07we actually send through the that this domain is going to be attached to the reason we do that is because the application id persists for the lifetime of that application running on cloud it never changes and so if we're clever with that we find that we never have to rebuild these expensive ingress objects i talked about previously but how do we use that metadata object well once it gets created on cloudflare we have access to it when requests for those host names come in so the request comes in We write a Cloudflare rule that basically extracts that key from the JSON object and it rewrites it to a header on the request. So we have an additional request header that we then pipe through the Cloudflare tunnel. And rather than our cluster router now looking up the hostname and routing based on that, we route on that application ID.

12:58And that's a huge save for us because we set that once, it never has to change, we never have to update those ingress objects. As a side effect of that, we're able to move domains between applications much more quickly and easily than we were before without the customer having to require a redeployment of their app. And it's secure because Cloudflare is always going to be the last link in the chain, the one that will write that header on our pass. So again, another big side effect benefit of our partnership with Cloudflare, leveraging the tools that we have access to, to shuffle some of the complicated stuff and take the burden off our own infrastructure and pushing that off to the edge.

13:40but metadata isn't just for routing or at least we don't just use it for routing we have um lots of use cases for this metadata object if anything i wish it was a little bigger than four kilobytes but we we make with we make do with what we have um so here i want to tell you about how we apply it a little bit more at scale so one of the problems that you have when using for sass is that you're you're routing tens of thousands of custom custom host names through a single cloudflare zone and cloudflare zones as we all know have a limit on the number of rules that we can apply the number of waft rules the number of cache configuration rules the number of transform rules and so we can't just give our customers access to the rule builder we can't rebuild the rule builder in our ui and allow customers to create those rules in cloudflare um we to think outside the box a little bit and decide how we can apply those rules at scale and metadata comes in uh in a really uh useful way for this too because what we do what we've decided to do is create an opinionated set of rules configuration options that we present to customers within our ui ones that we know are most important to the customers and the use cases of the apps that we are deploying or the customers are deploying on our platform And so every time a customer makes a configuration change within their application, we make the same or very similar API call to what we do when we create that custom host name that I presented or mentioned on the previous slide, we update that custom metadata object.

15:14And that looks a little bit like this. So in the middle of the screen here, you can see the custom metadata object. It's a contrived example, but it kind of gives you the idea of exactly how this works. We need the top. key there you can see is the app id it's the exact same thing that i talked about on the previous slide that's how we manage our internal routing next you can see we've got some additional keys so we have cache and that value is set to bypass we have frame and that value is set to deny and we have under attack and that value is set to true now hopefully what you can visualize is that we have presented these options within our ui so we give customers access to define their caching strategy we give up we give customers certain secure rules that they can apply in this case, whether or not they want to prevent their application being accessed by an iframe. And finally, hopefully you get the idea with the last one from a denial of service perspective.

16:04If the customer notices they're under attack before Cloudflare do or before we do, they have the option to go and trigger under attack modes. And so it looks like this. We have that, that have that metadata. object attached to the host name similar way to or in the exact same way as routing the request comes into cloudflare we set the first thing we do is set the request header with the app id that would get sent through the tunnel for our internal routing we can also set the cache configuration rules so we'll do a look up on that key and an input on that object i'm sorry and if the cache key is set to bypass we'll apply a cloudflare rule that bypasses the cache entirely if um the customer has set this frame option to deny will set a response header an outgoing response header um to to inform or to set that security header to prevent their application being uh accessed via iframe and again from the denial service protection perspective if the under attack key is set to true we'll apply that rule and those rules only apply to the host name um where that metadata applies so it's really really really, really powerful stuff.

17:18And like I said, it's just a tiny little four kilobyte JSON object, but it gives us so much flexibility and control over how we route these requests through our Edge network. So that's basically everything I wanted to tell you today. As I mentioned, we're building variable cloud, this fully managed platform where you can bring your entire stack. And we really want to take the pain out of deploying and hosting web applications. And to do that, we've really heavily leveraged our partnership with Cloudflare to push as much of the complex configuration options that we don't need to handle ourselves and our internal infrastructure off to the edge. And that's been a huge differentiator for us. It's resulted in performance improvements. It's resulted in cost optimizations. Yeah, we're really, really happy with how things are working out. So I just wanted to share that story with you today.

18:06It's been a wild journey, which culminated in, you know, a nice PHP vulnerability coming into this talk today. So Thank you for listening.