The Laravel Podcast

Matt Stauffer:
All right, welcome back to Laravel podcast season seven. I am your host as always, Matt Stauffer, CEO of Tighten. And in this season, I'll be joined every episode by a new member of the Laravel team. And today I get to talk to my delightful friend, James Brooks, the Forge engineering team lead at Laravel. James, can you say hi and share a little bit about what you do at Laravel day to day?

James Brooks:
Yeah, hi Matt. So my name is James Brooks. As Matt said, I'm the engineering team lead on Laravel Forge, which basically means that I kind of oversee the development of Forge. Most recently, the redesign that we launched or we shared at Laracon US, but also previously various things, documentation, the framework, that kind of thing.

Matt Stauffer:
So you know this, but one of the things I want at the beginning of every episode is I want to hear your journey to Laravel, whether that is the last year or the last, I mean, it can't be the last year for you because you've been working there for what, like five, six years. But anyway, it could be just the short period of time leading up to moving to work at Laravel, but it can be as far back as you want to go. And I want you to go as far back as you're comfortable going, because I really want to hear the story of kind of what got you through the various stages, especially as one of the earliest kind of Laravel team members.

James Brooks:
Yeah. So, man, we can go back quite, quite far. When I was seven, I fell over, hurt my knee. This is quite a long story, but I'll try and keep it relatively brief.

Matt Stauffer:
I'm fascinated to see where this goes.

James Brooks:
So I, yeah, I fell over, chipped my knee cap and I was kind of like bed bound for a while. And I went to, my mom was going to the library because they used to be like big popular things back then in the nineties. And she was like, would you like a book? And I said, I want to learn to make games. So like a couple of weeks before that, my school friends, dad had come in and we had like fruit bread, the Soren company. And they had some games that were like on a floppy disk where you would play asteroids and it was all like bread instead of asteroids. I like those kinds of variations of those games. And I was like, I want to learn how these are made.

So my mom, I was like, I want to learn to write code or whatever it is that I need to be able to do to do this. And, she came back with a book on JavaScript. And so it was like a very early version. I can't even remember what the book was. And so I kind of like seven year old did not have the capacity to read a book like that. So what I did was copy all the code into notepad and then just like see how it would run. So like my parents had me out, get kind of started with that kind of thing, not technical people themselves, but like show me how to like save a file, open it in Internet Explorer or whatever it was back then. And then, yeah, I kind of, I was like, that's it, I'm gonna, I'm gonna be a software engineer or whatever it is that, I don't think these terms are like really things, but like, I want to do this, this is what I want to do. And it was between that or being a stuntman.

Matt Stauffer:
Being a what? Stuntman.

James Brooks:
So, yeah, stuntman. So like, yeah, yeah.

Matt Stauffer:
I thought you said Stumpman. And I was like, is that another Britishism that I get to learn today? Okay, software engineer Stuntman. Yeah, okay.

James Brooks:
Yeah, bit of extremes. And I mean, being a stuntman didn't work out, but being a...an engineer did.

Matt Stauffer:
Clearly.

James Brooks:
So like I kind of went through different types of engineering. So I did Windows development. I was writing a 16 bit operating system at one point. I was like, I tried to make games.

Matt Stauffer:
How do I not know this?

James Brooks:
I just like, I tried a lot of things, right? And at one point I found PHP and that was like 4.2, 4.3. So early 2000s. And I was like, this, this is my language. I understand it. It makes sense. I'm like going all in on this. And I've still done other things around that, but, yeah. So I went to college, which is like not university college, but, 17 years old. Did, an IT course. One of the things there was like, VB six. So I tried that for a while.

And then I got my first job at a, jewelry company doing like IT support.

Matt Stauffer:
Okay.

James Brooks:
And they also made all their like EPOS, that point of sale software for all the shops around the UK and all in VB six. So I was like, well, I know a bit of VB. I like, can I help out? Can I do something? So I did that for a while and then I found, yeah, a lot.

Matt Stauffer:
Was this just kind of classic procedural VB? Or was it class? OK.

James Brooks:
Yeah, Well, VB6. So was like the drag and drop UI components.

Matt Stauffer:
I don't know the VB Delaney. okay, got it, got it.

James Brooks:
Yeah, like drag and drop stuff. And then it was like, I can't remember the handles. So you could do click on button and it would do this and run procedures. And then I saw an advert for a travel agency that were looking for a web developer. I was like, that's really what I want to be doing. So I worked there for near on 10 years, up to the software development manager.

And so during that time, there was like a already built CMS CRM system and they would get quotes on the phone. Agents would assign them to themselves and work through those. And then I was a couple of years in, I was tasked with rebuilding it. And this was all like PHP in HTML, like what people think is really bad these days.

Matt Stauffer:
Okay, yeah

James Brooks:
That's exactly, it was exactly that everywhere. So I was like, well, we're definitely going to use a framework. Like that's a no brainer here. And I was looking around for different frameworks and I came across Laravel, which was like 4.1, I think at the time. So this is like January, 2014. We'd already tried building this CRM by the way in Node.js, but it was like very early. We had real time kind of, if one agent tags a quote, it would remove it from everybody else so that we didn't keep running into people working on the same thing.

But it just didn't work. Like, I don't know what was going on. We had memory leaks and all sorts of stuff. So I was like, let's rebuild it in PHP. That's what we know. I found Laravel. I read through the documentation one afternoon. I was like, this is it. This is what we're going with. The documentation explained everything. I think like even the documentation at the time was mentioning flights as like models and stuff, which I was dealing with.

Matt Stauffer:
Yeah.

James Brooks:
And it was like, wow, this is, this is everything I could ever want in a PHP framework. Um, and I built a proof of concept that afternoon, just like tagging things, like connecting to our existing database, figuring stuff out. Um, so yeah, that was January 2014. And then, uh, I started kind of contributing to the Laravel community kind of around that time as well.

So there used to be like a Slack channel and I was involved in that. I spoke to Abby at some point and, famously mispronounced Arkansas as Arkansas. And then, I still don't understand how I got it wrong.

Matt Stauffer:
It's very reasonable to say Arkansas, Yeah. Yeah. Arkansas. Yeah.

James Brooks:
Right? I mean, Kansas, Arkansas, it makes no sense. Yeah. So yeah, then I started working on like an open source status page system called Cache that got kind of well known. It's like used by lots of companies around the world, big, big companies. And then around that as well, I was contributing to the Laravel ecosystem. So I added Blade highlighting to GitHub.

I say I added, I like enabled it, it's like a linguist thing.

Matt Stauffer:
What was the syntax for that when you built that?

James Brooks:
And then it was all like Ruby configuration files. They like use the TM language files. I think it was TM language and it just needed enabling, but I enabled it and there we go. So yeah, I did that. And then I applied for one of those, so was like early twenties.

Matt Stauffer:
Okay.

James Brooks:
I yeah, early twenties. And I applied for one of the Laracon giveaway, like for the tickets to the US, which I won. So incredibly grateful for that. Like a bit of a defining moment in my career, really. So Taylor gave me a ticket and then I convinced my company at the time to send me. I was like, look, are the tickets paid for? I'll sort my hotel out, but like we're a travel company. Can I get some help with the flights? So they helped me out with that.

Matt Stauffer:
Yeah.

James Brooks:
I went to Louisville, was my first conference, 2015 that was, and then kind of met Taylor a little bit. I was talking to him and then kind of in between all of that, I ended up with his phone number and like messaging him on Telegram as you do. And there was a thing in Envoyer I wanted. I can't remember exactly what the feature was now, but I messaged him and was like, Hey Taylor, can you please just add.

Matt Stauffer:
Wow.

James Brooks:
this one feature, um, it's like, you've had it. I'll merge it in. So I got access to Envoyer. I built the feature. Um, and then that kind of, that was that. And then I was listening to Taylor's podcast and he was saying that, um, this is what he, when he used to kind of record himself, just talking about business and Laravel and that kind of thing. And, um, yeah, he was saying that, oh, I'm thinking maybe I'll hire somebody for Forge that kind of thing. Maybe we'll see. It was like very loose, very tentative. So I messaged him. I was like, Hey,

Matt Stauffer:
I'm your guy.

James Brooks:
you know like do I need to say anything and he was like yeah yeah send me your CV so I did that and I'm sure he didn't read it because if he did I'm sure he wouldn't have hired me and so he was like yeah I mean when can you start and then I joined in 2019 so yeah six years on Laracon US actually while I was giving the keynote was my six year anniversary at Laravel

Matt Stauffer:
Six years is incredible. Because I don't know, were you, was there anybody else other than you and Muhammad at the time? Okay. I knew you were in the initial few.

James Brooks:
Dries as well, it was Mohammed, Dries, myself. Yeah, we used to, OG, yeah. And we used to, it was that small, we used to message on Telegram, like all of these packages, no Slack, no.

Matt Stauffer:
Not even have slack or anything like that. Yeah.

James Brooks:
All of these messages, all of these products and services and packages, and we're like discussing everything, and there's no threads in Telegram. And one day we were just like, we gotta sort this out. So four of us moved to Slack.

Matt Stauffer:
That's amazing. So when you started, what was the delineation? Was it Dries on open source and you on the products or how did you kind of split your work?

James Brooks:
It was kind of very loose really. When I started, I was actually working on the framework a little bit. So my first task was to replace Swift mailer with Symphony mailer. And I was like, man, like that was my first thing.

Matt Stauffer:
Thank God for you. Yeah.

James Brooks:
And I was like, I've made a terrible mistake. I can't do this. Yeah.

Matt Stauffer:
Pretty nasty bit of work so for that to be your first thing is pretty incredible.

James Brooks:
Yeah, it's massive. It's really like gnarly is the only way I can really describe it.

Matt Stauffer:
Yeah.

James Brooks:
And so I pulled it all apart. like pulled out all the Swift mailer and I was going through and I was like, just can't get it to work. wasn't like, kind of works, but like it was missing so many things and you couldn't like configure settings as like headers as easily. And I was like, this doesn't feel right. So I like calling Dries or Mohammed and I was like, I think I've like massively oversold myself here. I'm not capable. Can you just check this out? And they're like, whoever it was at the time they're like, yeah, it looks like, I think you're right. I think this is too early. so the product got like canned at the time.

Matt Stauffer:
Like too early in the Symphony Mailer's life, it just wasn't ready. Yeah.

James Brooks:
I was like, my God. I like got out of that one. Yeah. It wasn't ready yet. And it was a couple of years later that I think Dries picked up where I left off and, and it was in a much better state then. So that was, I breathed a sigh of relief that day. I felt like, okay, I can do this.

Matt Stauffer:
Okay.

James Brooks:
Yeah. So then from the open source, I did a couple of things here and there. And then moved to Nova for a few months. I think it was like nine or 10 months. So I worked with David Hemphill, on that. So he was kind of like, a boss slash manager. It was like, right, James, you go work on these things, tidy up all the issues. so I did that.

Matt Stauffer:
Yeah, yeah, yeah.

James Brooks:
Contributed a few things there, so that was nice. Really got to know the community at that point as well and people that were using Nova. And then it kind of naturally fell to kind of managing Envoyer and Forge. I'm a big Forge fan, always have been, used it very early. It's just an incredible product, right? It does exactly what it says it does.

Matt Stauffer:
It is incredible. It's still my favorite tool I use every day. So, yeah.

James Brooks:
I love to hear it. So yeah, kind of just like naturally fell into that because I just enjoyed working on it. And yeah, that's where I've kind of been focused. Yeah. Look at me now.

Matt Stauffer:
You know. Okay. So, so when cloud came out, a lot of us, you know, I shouldn't say us because I felt confident that Forge would always have a life. But a lot of people in the community were really nervous that like this means the end of Forge. And I was not worried because I trust, you know, Taylor and I trust you and other folks in the organization. But if I had been worried, it would have been a big worry. Because like I said, I use Forge every day. My company relies on Forge to run automated scripts hundreds of times a day. Like Forge is like at one of the heartbeats of Tighten. I freaking love that tool. And so I was so delighted to hear that Forge is gonna get like an extra, not just, yeah, we're gonna maintain it, but actually we're gonna kind of put more energy and effort.

And it wasn't, that wasn't the initial pitch, right? The initial pitch was Forge is gonna be around, don't worry. And then sometime like halfway through last year, when I was talking to Taylor, you on the podcast and off, he would start saying, no, we're gonna kind of put some extra energy and attention into Forge. And I was like, I'm excited about this, whatever. So I'm curious, like for you, was there a moment where you all sat down and said, all right, it is time for us to figure out what is the next iteration? What's Forge 2.0 look like? And if so, what was the impetus there? Did you all brainstorm together? Did Taylor say, this is what it's going to be? And you internalized it and then split it up for the team? What was that process like?

James Brooks:
Kind of a bit of everything really. So at Laracon US last year in Dallas, we did an offsite with the company and there was like 40 of us, think 30 or 40. And we kind of sat there and so the team leads were giving like updates on kind of where like Jess's team were with Nightwatch, Joe's team were with Cloud. And then I did a bit of like, here's what we're thinking with Forge. We think we could do a lot more.

Matt Stauffer:
Okay.

James Brooks:
But we knew that we needed to implement things like organizations, we knew that we needed to do teams, we had this massive backlog of things. And so we're sat there in this room giving these talks and we're just kind of chatting. And I think it was Taylor was just sat there like, what if we just completely overhaul Forge, like Forge 2.0 and...

It went from like everyone's been super excited about Nightwatch and Cloud and that kind of thing, all this new stuff. And then we spent like a good 45 minutes hour just discussing like what Forge 2.0 could be. The room was like, it was so excitable in there. And so we're like, it came away like really invigorated and energized and excited about what it was. And then like we hadn't really come up with anything concrete as to what Forge 2.0 was, bar like what we were already working on.

Matt Stauffer:
Love that.

James Brooks:
and until like a bit later where we were like, okay, so we need these features. we're to add this and this is where I'm going to ship. And then like the Cloud redesign really helped because I introduced a lot of our design language. So we knew that like, okay, well, we can apply that to Forge. We need a designer. He's going to have to, or there is no gym, but they're going to have to kind of apply the design language to Forge, every aspect of Forge.

But initially, the feature set was organizations and teams, health checks and heartbeats, zero downtime deployment. And then it just turned into this, well, actually, we can do a lot more than that. Let's set it up for the future. And so it's of grown in places, and we've had to take a bit of the scope back a bit, because there's just too much that we want to get done. So yeah, it's quite exciting, though.

Matt Stauffer:
Yeah.

And so when I had Taylor in the podcasts a week and a half ago or something like that I was saying so what does this mean for the future of Envoyer and what I did not think about the fact is that you're also like a very kind of connected to Envoyer person because I feel like there's those of us who've used Envoyer extensively like we've used it on a bunch of projects it's the best way to have zero downtime deploy the heartbeats and the health checks are just so freaking convenient that's like why not use it but I know a lot of people have never touched Envoyer before so I while I love Envoyer and Taylor's answer kind of ended up being like there's a level of multi-server configuration on Envoyer that you're not going to get in the new Forge.

James Brooks:
Mm-hmm.

Matt Stauffer:
I am still very excited that every single one of my Forge sites without having to add Envoy are now getting all these features. Was there any part of you that was like, was there any sorrow in knowing that kind of Envoy usage is just gonna drop a little bit as you're building these features in?

James Brooks:
Yeah, kind of. I mean, so Forge, Envoyer and Vapor are all under the Core Services team. So technically that's my remit. I'm like engineering team lead of Core Services, but like fundamentally that's Forge.

Matt Stauffer:
Okay.

James Brooks:
And so, and given like my history and attachment to Envoyer as well, like that being almost one of the pivotal moments of me getting my job here. Yeah, like part of me is like, man, that's such a cool product. Like it's nice to work on. People love it as well, like it just works. It does exactly what it says it does. The only time it ever really fails is if like a source control provider is down. Not often, yeah. And so...

Matt Stauffer:
That's not on Envoyer. Yeah. Yeah.

James Brooks:
Yeah, part of me is like, oh man, that's kind of nice that like it's gone because it's one less, it's not gone, it will be maintained. There'll always be people that don't use Forge and they just want Envoyer, but like zero downtime is kind of now just something that you get with a lot of hosting services or deployment services. So I think there's still be, there's still be usage. And like Taylor said, Forge will only deploy to one server at a time currently.

Matt Stauffer:
Yeah.

James Brooks:
It's definitely something we want to explore because we think we can make that a lot better in Forge. But it's like stepping stones. Got to start somewhere.

Matt Stauffer:
Yeah. Okay. So as you were building out all these kind of new changes to Forge, you were to do obviously you've been maintaining Forge for the last, you know, however many years, but this was Taylor's first public software as a service project, right? Things have changed quite a bit in terms of how we write code, but also things have changed quite a bit in the team since he first wrote Forge.

James Brooks:
Mm-hmm.

Matt Stauffer:
How much did you do the refactors that you've been dreaming of for the last five years and how much were you like? This is kind of kind of looking pretty good for something that's this old.

James Brooks:
Yeah, There's still a lot of the original code around. Like we've moved things around. we now put models into a models namespace. That's like a default Laravel standard now that we didn't used to have. I think one thing that's super interesting about Forge, although not as true anymore, is that you could see the evolution of Laravel, the framework, through Forge. Because Taylor built like Cashier before he implemented Cashier. He built like the Echo stuff before we had Echo. Notifications before we had that in the framework. And you could see like where the inspiration came from. I was like, why do we not just use the notification system? Oh, it just didn't exist. Like it exists now. Yeah, but we've got to refactor that.

Matt Stauffer:
Yeah. Notification system is this pulled out into the framework. Yeah.

James Brooks:
Exactly, yeah. And there's like lots of things where you can see Taylor's played with ideas and seeing the evolution and it always comes out better in the framework. I think the framework nails every time.But yeah, there's still like, we've done a lot of refactoring to the action pattern for this new version of Forge. And we really chose to do that because we have the front end and the API. And we want to share a lot of the logic there. It wasn't just like, the action pattern is here, but everyone's doing it. We actually had like reason to do so. And it also meant that it's like units of all unit testing, which is something for us never really had it any before was any tests, anything meaningful.

Matt Stauffer:
Yeah. Which is tough for Forge, right? Because Forge is doing a lot of, it's not, and I wanted to ask you about this a second, but Forge is doing a lot of calls to terminal things that are also being streamed back live.

James Brooks:
Yeah.

Matt Stauffer:
Like I'm in the middle of building something right now that I used actions for and I had to unaction it in order to be able to stream its stuff. And so I actually wanted to ask you specifically how you did that in a second. But there's a lot of pieces about Forge that make it not our standard kind of use case. I don't know if you mind kind of diving into that. Like what is testing something that's all terminal calls? Is it a lot of process sniffing basically?

James Brooks:
So we do a lot of faking, basically.

Matt Stauffer:
Okay, yeah.

James Brooks:
We try doing like actual testing where we connect to a server and we run some code and some of the bash and see what the output is. But it's actually really hard to do that because especially where Forge is changing configuration files on the server, you basically have to then delete the server, spin that back up. And we all know that takes time. So it's like, well, how often can you run actual tests, like full integration tests?

Matt Stauffer:
Yeah. Yeah.

James Brooks:
Which ends up being never, cause it's just too slow and inconvenient. And like if a test goes wrong, well, that's it. That server is kind of just dead now, like delete it and start again. So what we do is we have like SSH wrapping classes, which we call a tunnel. And then we fake it basically. that, yeah. Yeah. And does it have the right script? Has it generated with the right variables and that kind of thing, which we find like,

Matt Stauffer:
Got it. Yes, and just make sure it gets a call that says, you know, SSH run, whatever. Totally. Okay.

James Brooks:
good enough, like plenty good enough. I don't want to undersell that, but we find it good enough that like we don't need to do this full end-to-end testing. Yeah.

Matt Stauffer:
Yeah. Yeah, yeah.

I built a lot of tools that end up at some point wrapping a whole bunch of local utilities. So there's a composer class that we will fake to make sure composer class gets these calls, whatever. So very familiar. Mine are usually on command line. They're the command line tools that we built. But I'm like, yeah, it's pretty similar. You got to make sure it ssh is in with these parameters and then sends this particular thing. So that makes a ton of sense. But now I do want to ask you about the action pattern. And I'm sorry to listeners, because this is just my pet thing right now. But I literally had a tool that I built

James Brooks:
Mm-hmm.

Matt Stauffer:
where it was something I built for my Laracasts course where I wanted to send off little terminal requests to call FFmpeg. And I would click a button, it would say, this video has not been run through this particular FFmpeg process. I click the button and then two minutes later, in theory, it's done. And I hear you refresh and it's done, but I'm not getting that whole terminal output, right? And it was just dispatching an action. And it was great in a way that I think it's probably valuable for Forge as well because the user interface is really just triggering. complex actions somewhere else. Whereas like a lot of times the user interface is triggering PHP actions and then it stays in our world, right?

But in Forge and in this thing I was building, it's really triggering these things that are happening somewhere else. Something else is responsible for this. So for me, I was just like, kind of lose access to what's happening if I use the action pattern. Whereas when I kept the actions happening in the controller, I could do things like the OB flush and stuff like that, every element of the loop. So I can do these streaming things. How do you handle that with the action pattern?

James Brooks:
So the action pattern itself is used for like dispatching jobs essentially. So for us, an action encapsulates setting state on a model. That might be like installing a new version of PHP. So we would either create that record or if we're patching it, maybe we set the status to updating.

And then we dispatch a job, which we call a provisioner. Like provisioners in Forge are like glorified jobs. They have some nice DX for us to set like event logs. We can do like failed hooks. So if the process code of the command we're running is like 55, then what was that error? it basically, what was the non-zero exit code? And then kind of handle that. Maybe we need to reset some state on the server.

And then the other part of that is kind of handling the output. So sometimes we need the output, like if we're syncing databases, we need to actually echo the list of databases on the server. So we'll print those out. Then we sync, we take kind of like read that, sync it into Forge. But then that's like one of the few cases where we need to kind of deal with output. And the other one is deployment output. So as you're deploying, we want to, yeah, we want to print that out, keep you up to date with what's happening so you see the stream of content. The original way that I built that was using server-side events before AI kind of like mainstreamed it.

Matt Stauffer:
That's what I was thinking, yeah.

James Brooks:
But we weren't sure how well that would scale. Forge gets a surprising volume of traffic. So we kind of like, do we want to put that onto the server? Probably not. Or like the main web server. So what we settled on was handling, reading the output from the process. So we use like the Symphony process classes for that. And then we can kind of pull out that output. And what we do is we just cache it.

For like a few seconds. And then what Forge's front end is doing is actually pulling that cache and refreshing get every few seconds. So it gives the illusion of real time output. But it's up to date enough that you're like not behind on anything.

Matt Stauffer:
Okay, that makes sense. That's really cool.

Matt Stauffer:
Yeah, and there's just basically like a cache prefix that you're pulling from.

James Brooks:
Yep, yep, just a generated cache key that we pull out.

Matt Stauffer:
Okay, huh. Yeah. Thank you. Learned something.

James Brooks:
Yeah, sometimes it's the simplest things, yeah.

Matt Stauffer:
Yeah, I hadn't even thought about that. I'm like, it's got to come straight across the wire. Well, you know, so awesome. Okay, thanks for teaching us that. Yes, and that's what I thought you were going to say.

James Brooks:
Yeah, I mean the other way of doing that would be with like web sockets, I guess, but that's quite a lot of... Yeah. Nope. I'm afraid not. Just, just good old cache.

Matt Stauffer:
Okay, so back to the actual topic that I interrupted you, I'm sorry about that. So you kind of made all these Forge 2.0 plans, you talked about the, you know, being this zero-down time deploy and stuff. When did the Laravel VPS come in?

James Brooks:
That was a good question. That was like earlier this year in some ways. So we'd been partnering with DigitalOcean already and it kind of came to us like, what if we just offered our own provider? What would that look like? Because one of the biggest barriers to entry in Forge is that you have to sign up, which we always know is a big one. And then you have to bring a server provider. So with our partnership with DigitalOcean, we actually brought in like a wolf. So was like one click.

Matt Stauffer:
Yeah.

James Brooks:
go to the O and then select which team you want to link and then you get back and it's done. So that's awesome because it already speeds it up. But then not everybody's using DigitalOcean and not every provider has that flow available. So we're like, well, what if you just didn't have to press any buttons and we could just be the server provider for you? Like that's cool in terms of getting people on boarded, but then like what's the actual value for that? Because really it saved you a few steps. And then it kind of

Matt Stauffer:
Yeah. Yeah.

James Brooks:
turned into what if we could deploy a server in a minute or less? Like how is that even possible? Because we have to spin the server up. It takes time to install things. MySQL alone takes a good couple of minutes. Like how could we possibly do that? And to what point is it acceptable where we say like, you know, provisioning takes like 10 minutes. What performance increase do you have to get to be like, hey, you provision a server faster. And it actually means something. So Taylor's original, like remit was a server like one minute or less. And so Kieran, who's our DevOps on the core services team, he was like, what if there were just no loading pages? I was like, oh boy.

Matt Stauffer:
Hahaha!

James Brooks:
Like what if there wasn't, but like, how are you going to do that? And I'm not going to give anything away. But he, I mean, you've seen he managed to do it. It's incredible. So we have like a lot of servers just running ready to go at this point. It's, it's impressive. Yeah.

Matt Stauffer:
I was wondering about that. I don't know what I'm allowed to ask you questions about, so I'm just gonna ask and you tell me what you can't say.

James Brooks:
Okay.

Matt Stauffer:
The first two ideas I came up with, and I'm sure there's millions of others, they either came up with a custom stock image and so they're spinning it up off of a custom image that already has these things installed and they have to keep this image constantly up to date, or they literally just have a pool of servers that have already been spun up that are just being weighted to hand off to customers when they want them and they make sure there's always at least a pool of 100 or something like that. Are you able to tell me any... if I'm right on either of those and any more details or does this all have to be top secret for now?

James Brooks:
I mean, I don't know what I can and cannot say to be honest, but what I would say is that both of those are correct. Like it's more than that, but yeah, you've got somewhere with that.

Matt Stauffer:
Okay, cool. Great. Some some measure. huh. Okay, cool, cool, cool.

James Brooks:
Yeah. But I know I don't want Taylor or Tom to listen and, Andre, be like, whoa, that's the magic sauce.

Matt Stauffer:
Totally fine. Yeah, totally. And I won't take you any further. Okay, so VPS for me, because one of the things we were talking about is like, what motivates somebody to choose VPS? And is it enough to motivate someone to take an existing app and move it over to Laravel VPS? Or is it mainly for new clients? So it's very clear to us for new clients, because we, the number of times, I'm telling you, every single new client who's like, where do I host? I'm like, Forge and DigitalOcean.

That's that has been my answer for a decade. I think that's been around for decade. But anyway, it's been around since that's been my answer for clients since Forge has existed. And we basically just put one of our project managers on a on a Zoom call and we walk them through signing up for Forge and then we walk them through signing up for DigitalOcean and then we walk them through handing off the keys because there's no way our clients would be able to do that. So I'm already sold purely because it's on DigitalOcean. So I don't have to be like, oh, we're moving to AWS or whatever, because I don't like AWS. When I can avoid it.

But also I'm just like, it's just so much easier. We can literally just say, hey, go up, sign up. You we can make them a little walkthrough. it's, I get it for new clients immediately. But there was also some pitches for, it's not just the signup flow that is beneficial, but there's elements in which some of the internal services that Forge is gonna offer get like a zero latency, zero, not zero, like a lower latency and lower ingress, egress costs when you're using Laravel VPS.

Can you talk a little bit about like, what are the reasons for someone to use VPS other than the easier onboarding flow?

James Brooks:
Yeah, so the servers are kind of all managed by us, which is like a big thing already. And then you also get.

Matt Stauffer:
Mm-hmm.

James Brooks:
not, you technically get two bills because you're through Forge, but essentially you only get billed through Forge, which is, which is a nice plus, especially as like businesses have lots of invoices, lots of expenses. Like it's nice to consolidate those where possible. So the firstly, like the reason for getting two invoices through Forge is that you get your subscription, but then we only charge you based on when you start using VPS. So you have your like current subscription, which might be $39 a month.

Matt Stauffer:
Mm-hmm.

James Brooks:
But then maybe it's a week later you actually provision a server. Well, we'll now like, because we don't use like first of the month billing, it's always anniversary, like that could change and we can't pro-rate it. So we give you an invoice month to month from the date that you sign up, sorry, the date that you start provisioning the server. So you've only got two outgoings, but one service and then...

There are some features that we want to build that we can do with VPS that we might not be able to do elsewhere. Just because it's kind of like catered to us and what we can provide. So there's options for integrations in the future, which would be nice. And then things like the terminal you saw could be exclusive to Laravel VPS because you don't actually get kind of SSH access to that server.

Matt Stauffer:
Mm-hmm.

James Brooks:
directly through the provider, right? So we have to provide something for you. And that's a kind of a nice way of managing that could be that Laravel VPS is like, you get the terminal there. And the other thing.

Matt Stauffer:
Okay. I was going to ask if the terminal was VPS specific because it wasn't super clear in the keynote. that is a VPS, they're all VPS specific thing. Okay. Yeah.

James Brooks:
Yeah, it's up for debate at the moment. We think it's kind of like cool for everybody, but VPS, like there's an actual reason for providing it for VPS over other servers.

Matt Stauffer:
Mm-hmm. Yeah.

James Brooks:
But we think it is very cool. Yeah.

Matt Stauffer:
It's very cool, yeah. I use the DigitalOcean one a lot, and if you were to tell me I would lose that, I mean not a lot, but it's a really helpful fallback. So knowing that we have that fallback in LaravelLVPS stuff, big fan.

James Brooks:
Yeah, super nice. And the other part of that as well, goes in hand in hand with that is access control. So using the same permissions that you can have on organizations and teams, that can also restrict access to the servers. So you could give terminal access that way. But also like people have access to the server. You don't need to give them access to like Digital Ocean as well. It's all in one place.

Matt Stauffer:
That's great. Yeah. I hadn't thought about that. Yeah, because right now I use the Forge circles to primarily define who has access to those things. And every once in a while someone's like, hey, I've got access to the circle, but you haven't added me to DigitalOcean. I'm like, So yeah, that's nice. Are there any costs if I were to just today take one of my existing DigitalOcean on Forge apps that I know how it's been working, it's been doing great for eight years, and I just want to move it over to VPS? Is there any you're like, eh, be careful if.

James Brooks:
Nope, works the exact same way. So no bandwidth. It is technically usage-based billing, but only in the same way that DO and other providers are. So it's a fixed cost over a month that gets kind of broken down into hourly costs with a maximum set on that. So it's always the round number and then that's where you pay. Yeah.

Matt Stauffer:
OK, cool. Is there anything about VPS that we have not covered that you wanted to make sure we get to talk about?

James Brooks:
I mean, the team have done a cracking job of it. It's like technically very cool to see it come together and actually be as good as it is. Mohammed and Kieran have really nailed that entire service. Very exciting. Yeah.

Matt Stauffer:
Yeah, I love that. so with Forge, we've talked about Laravel VPS. We've talked a little bit about kind of the fact that some of these onboard services are coming back. Were there any fun or less fun, but notable technical challenges about moving those zero downtime deployment, heartbeats, health checks over to Forge? And was it more like a recreation from scratch or was there any, I assume there wasn't a ton of code copying, but what was that process like? Was anything interesting about it?

James Brooks:
So everything has been written from scratch for these services. So we actually have two new microservices. I hate using that term, but they are. So health checks and heartbeats are both individual services. So they can receive and send their own kind of updates and whatever. And they can scale independently of the rest of Forge. And then, yeah, so even though we have all of this stuff kind of existing in Envoyer, we wanted to do it again, but with like more usefulness. like health checks, for instance, currently in Envoy, it's like, is it an opposite down? Is it 200 code or is it not a 200? With health checks in Forge, we wanted to actually be like, well, this page took five seconds to respond from New York, but only one second from London. And we also show you the actual status code that we received when we were trying to access your site.

Matt Stauffer:
Nice.

James Brooks:
So you get some more insight. You get notifications around that as well. then health checks, sorry, heartbeats with the cron stuff. wanted to improve that service, make it kind of more natural to use. we felt that some of the way that we did it in Envoy wasn't quite as clear as like notify me after. When you configure it, you can say like, I only want to be notified if that job runs for five minutes longer than it should do because maybe it is one of those kind of flaky third party services that just sometimes takes longer. And we wanted to make that just smarter in the way that we did it retries that kind of thing.

Matt Stauffer:
Yeah. Yeah.

James Brooks:
And then zero downtime, in Envoyer that uses Tarble. So it downloads the actual archive of the repository from the source control provider. In Forge, it's worth noting actually currently zero downtime will only work for newly created sites because we have to set it up slightly differently.

Matt Stauffer:
Okay.

James Brooks:
Well, what was I saying? So zero downtime. Yeah. So that Tarble in Envoyer, but actually we could use the OAuth tokens to kind of clone those through Git still. So you get all of the like rollback functionality potentially. You can still ignore some of the files in there. It just felt a bit more reliable than like Git never fails, but downloading stuff has failed. And then...

Yeah, so that's kind of like where we've brought over features from Envoyer. Technical challenges, I would say, was introducing organizations and kind of refactoring circles to teams. So previously, you would sign up as a person and then you get billed like personally, even if you represent a business. And what's confusing about that is that you, you can't use the same email for multiple accounts. You have to sign up a new email address every single time. And then you could use circles to get added to other people's accounts, but there's like a Venn diagram of what you're allowed to actually see. And it's like a really weird mental model. So we knew that we had to fix that like big

Matt Stauffer:
Yeah.

James Brooks:
point number one on the list is organizations and teams. Circles just don't cut it. So we spent last year, June onwards, June till August, just implementing organizations and what that would look like and refactoring all this circle stuff to teams. And we had to do a ton of migrations to do that. So we've actually been running organizations on like, the backend was calling everything Teams and it was working with individual permissions and like, role-based authorization and that since August last year.

Matt Stauffer:
Really?

James Brooks:
Before we had announced 2.0, like we knew that that's the direction we were going in. We actually took Forge down for us for like a few minutes because of this migration. So we were migrating old users into organizations and then kind of overlapping where they had been in circles of these organizations and then migrating them into teams that only were in those organizations with the set of permissions that they which are now roles. So we had to do like all of these migrations to kind of put people into the right state as the world is with organizations. Move all the billing stuff over to it at the same time. Locally, so we ran this migration locally on these like brand new MacBook M3s and it takes like 20 seconds. Like it's super quick.

Matt Stauffer:
Yeah.

James Brooks: \
Production day comes around, we're going to deploy it. We're like, okay, we know that this works. We've absolutely nailed this. Let's all jump on tuple and just get ready just, just in case. And then, yeah, we took down Forge because the migration took far too long to run. And we're like, well, managed really shows that these Apple and serious stuff is serious business. Like very powerful.

Matt Stauffer:
They're very powered. Yeah, yeah, yeah.

James Brooks:
And then there was like some performance stuff that came around because we have like this, table that we join on to get permissions and what you have access to. So we did some optimizations around it, but we redeployed it and it's been in production since August. But that has been one of the biggest challenge and bits of work on this version of Forge. So actually, one of the things that we've been doing

Matt Stauffer:
That's crazy.

James Brooks:
And Taylor kind of hinted at this as well on stage was that what you saw in that demo is actually in production right now. It's just a feature flag away.

Matt Stauffer:
Yeah.

James Brooks:
So one of our early decisions was, we had a decision really, which was, how do we work on Forge? Do we do it in a new repository? Do we clone the repository and like...

Matt Stauffer:
Mm-hmm.

James Brooks:
of sorry, fork it and then work on that. Do we do it on a new branch or do we just keep shipping to production as we go? All of which have varying levels of challenges, we opted to just keep shipping behind feature flags. So that's what we've done. It's been a lot easier to test things, but also a lot harder to actually keep like legacy working the same.

Matt Stauffer:
Yeah.

James Brooks:
But on the flip side of that, it's afforded us the ability to actually battle test everything that we're doing. So we have a new deployment pipeline that's already in production that you're using right now, which solves a few problems with deployments. We have the new UI that's behind a feature flag. We've like refactored all to these actions and then we've updated legacy with it as well. So when we switch you to the new Forge, we are a lot more confident, highly confident, fingers crossed, that everything just works.

Matt Stauffer:
Yeah.

James Brooks:
because it has been working.

Matt Stauffer:
Yeah. Yeah. I would, and I had been wondering this whole time. I'm like, the thing that made me most nervous for y'all. And I told the team this, I was like, is circles. I'm like, how you're going to move this extraordinarily complex system of permissions over. And I'm sure every person is using their circles a little different. So I was just like, can't admit it, but basically what you're saying is we already did. It's just, we kept a circles UI on top of the new system. And at some point you're going to swap out a UI that gives us a totally different level of interaction with it.

James Brooks:
Yeah.

Matt Stauffer:
Brilliant. Love it. Very happy for you and for me that that's the case.

James Brooks:
Yeah, it's done and you don't need to worry about it, which is nice. One of the big things there as well was introducing roles because we figured that the individual permissions, there's like 45 individual permissions currently, which is just like, it's a bit overwhelming. It doesn't really mean anything. It's, mean, it does, but it's hard to kind of quickly like, oh, that user can't do this thing. What permission do they need?

Matt Stauffer:
Yeah.

James Brooks:
So we knew that we wanted to simplify that to roles, which are just groups of these permissions. But then we had to kind of also migrate every single circle member into a role. So what we did is we looked at like the common groups of permissions. So we knew that like an owner would just have every permission. Owners are the people that actually created the accounts to begin with. So that's easy. That's taken care of. Therefore every organization immediately has one owner. And then admins, developers, those kinds of things. We were like, what do we see as like the top groups of permissions and what do we call those? Because that's like clearly a common pattern that people are applying, whether they know it or not. And then what do we do about all these people where they've only got like a handful of permissions? How do we get those into roles? So we had to like auto-generate custom roles for everybody as well. Which is, yeah, that was a challenge as well.

Matt Stauffer:
Interesting. So you basically were able to say like, hey, if somebody is not the owner, but they have all the permissions on, then we're going to instantly put them in an admin group or something like that.

James Brooks:
Yeah, yeah, exactly.

Matt Stauffer:
If they have this very common set of permissions, we'll put them in the developer group and stuff like that. That's very clever. Cause I was just like, again, like, are we all going to have to walk through this like onboarding process the first time? It's like, no, like we're going to make really smart assumptions. I love that. That's great. It's a really nice pattern.

James Brooks:
Yeah. I mean, it's not going to be perfect, but it's like for them, everyone that we've, it's good enough. Yeah.

Matt Stauffer:
Yeah. It's good enough. Yeah.

James Brooks:
And you can always go through and edit that as well, right? That you could go and change those roles. You can change the roles that users have. You could even say, actually, I don't want to be the only owner anymore. I can add somebody else. Now they, they can manage the billing side of things for you and do whatever else they need to do as well. Yeah.

Matt Stauffer:
I'm very grateful. We're going to need that at Tighten. We've had varying levels of roles over the years. And sometimes I couldn't give anybody all the accesses I want. Sometimes, like you said, it's hard to know what to put to people. And sometimes I've got 12 people at the organization with the same permissions, and I don't want to set those same check marks every time. So this is great. I love it.

James Brooks:
Yeah. It makes so much sense, right?

Matt Stauffer:
Yeah, it really does. I just looked at time, and we're...I was supposed to have been cutting us off like five minutes ago, but I'm just having a great time here. So I have to ask the question as usual, which is, is there anything that we didn't get to today? Because obviously we could have just kept going. Is there anything we can get to today that you wanted to make sure we covered?

James Brooks:
I do want to give a shout out to the team because they have been incredible.

Matt Stauffer:
Yeah.

James Brooks:
They really heads down focused on getting this to be the best thing that we can ship. And I know everybody says that everybody means it as well, but I'm truly grateful for every single one of them for all the effort they put in. Like they've really gone above and beyond.

Matt Stauffer:
Love to hear that. Well, James, I talked to several people. So one of the things I like to do at Laracon is to make sure I'm connecting with people who are there for the first time. We do the Laracon sponsorships and stuff like that. But also I just kind of like hunt out people who are coming for the first time, especially people who are new to the Laravel community. And I was delighted and unsurprised to hear multiple of them mention, oh, and then I met James Brooks and he's just such a sweetie. He's so kind, everything like that. And obviously, you know that that's been my experience of you for the longest time. Also my wife, you know, when she first came in the community, you were one of the first people that she met.

And we left the first LaraCon she was at, she's naming all people, she's like, and then James, and you guys had this wonderful, so anyway, I just wanna name that there are so many good and kind and wonderful people in the community, but you are one of the kindest, caringest people, and you have a reputation of just, you've been in Laravel team since you're an OG, like you said, and I don't know that we always recognize the combination of expertise and experience and OGness and also just being like a good human being together. You sometimes we, you know, someone knows about James the kind guy, he does the podcast and stuff like that. And then sometimes people know James like the big deal, but I just want to name that like you're both of those. And I'm very grateful that you are not just a good person, but a good person doing great work. Like you don't have to be one of the other, you know what I mean? So thank you for being who you are in our community.

James Brooks:
I appreciate that Matt. I think it comes from just like the community as a whole. I think that could be true for everybody because at Laracon is always one of the most welcoming, if not the most welcoming conference I've ever been to, ever had the pleasure of attending and speaking at.

You know, like I went to, when I went to my first one in 2015, everybody was so kind then. And I go now 2025 and everyone's just as kind. And if not kinder, like it just, I think it's something that like Taylor and people like yourselves and Eric and Ian that have all kind of led and paved the way for that. Everyone is just kind and it, I mean, it helps that everyone just seems like genuinely kind people anyway. But it's nice to see that like being kind of the waves of that going across the community in various ways.

Matt Stauffer:
Well, grateful to have you as a part of the community and thank you so much for hanging out today and as a dear, dear Forge fan, thank you so much for you and your team doing all the work you did on Forge. All right, go ahead.

James Brooks:
I appreciate it. Thank you so much, Matt. It's been an honor to be here. I was looking back at the original episodes I was listening to and it was like Sean McCool 2014. Like, it's been a dream of mine to be on here. Everybody says that, but it's true for everybody.

Matt Stauffer:
We finally got you.

James Brooks:
Yeah. I'm here. Yeah.

Matt Stauffer:
I gotta catch them all, right? Yes. Awesome. Well, thank you again. And for the rest of you, thanks for hanging out with us and we'll see you next time.