Inside Forge 2.0 and Laravel VPS With James Brooks ![rw-book-cover](https://wsrv.nl/?url=https%3A%2F%2Fimg.transistor.fm%2FKaV0wfWtCgK0nb7sfOm5yYYtt9GaofmCwWCj3kVt3ro%2Frs%3Afill%3A0%3A0%3A1%2Fw%3A1400%2Fh%3A1400%2Fq%3A60%2Fmb%3A500000%2FaHR0cHM6Ly9pbWct%2FdXBsb2FkLXByb2R1%2FY3Rpb24udHJhbnNp%2Fc3Rvci5mbS9zaG93%2FLzQ0ODU5LzE2OTQ2%2FMzkyODAtYXJ0d29y%2Fay5qcGc.jpg&w=512&h=512) ## Metadata - Author: [[The Laravel Podcast]] - Full Title: Inside Forge 2.0 and Laravel VPS With James Brooks - Category: #podcasts - URL: https://share.snipd.com/episode/70c9c098-0484-44e4-898f-6395b3aaf476 ## Document Notes ## Highlights - **From Childhood Curiosity To Laravel** - James Brooks learned to code as a child by copying JavaScript examples into Notepad and experimenting in a browser. - That early curiosity led him through many technologies and ultimately to PHP and Laravel, shaping his career path. Transcript: James Brooks 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 fell over, tripped my kneecap and I was kind of like bed bound for a while. And, uh, I went to, uh, my mom was going to the library because they used to be like big popular things back then in the 90s and she's 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 friend's dad had come in and we had like fruit bread the saurine company and they had some games that were like on a floppy disc where You would play asteroids and it was all like bread instead of asteroids. That's fun. Um, I like those kinds of variations of those games. And I was like, I want to learn how these are made. 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, uh, 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 by then and Then yeah i kind of I was like, that's it. I'm going to, I'm going to 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. And so being a what? Yeah. Stuntman. Matt Stauffer Oh, stuntman. I thought you said stuntman. And I was like, is that another Britishism that I get to learn today? James Brooks Okay. Software engineer, stuntman yeah okay yeah bit of extremes and i mean being a stuntman didn't work out being a an engineer did 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'm trying to make games 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 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 um an it course one of the things there was like uh vb6 so i tried that for a while and then i got my first job at a jewelry Company doing like it support and they also made all their like epos that point to sell software for all the shops around the uk and all in vb6 so i was like well i know a bit of vb i like can Matt Stauffer I help out can i do something so i did that for a while was this just kind of classic procedural vb yeah or was it a lot okay well vb6 so it was like the uh drag i don't know the vb 20s oh okay got James Brooks It got it yeah like drag and drop stuff and then it was like handle 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, but that's really what I want to be doing. So I went there for near on 10 years up to 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 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. 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. And I was like, wow, this is everything I could ever want in a PHP framework. And I built a proof of concept that afternoon, just like tagging things, like connecting to our existing database, figuring stuff out. So yeah, that was January 2014. ([Time 0:01:21](https://share.snipd.com/snip/d795dadb-756d-4425-ab4c-5543d44ab26f)) - **Community Work Led To A Job** - James contributed to Laravel community projects and won a Laracon ticket which led to direct contact with Taylor Otwell. - A small Envoy feature contribution and a CV led to him being hired at Laravel in 2019. Transcript: James Brooks That got kind of well known. It's like used by lots of companies around the world, big, 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 It was all like Ruby configuration files. They like use the TM language files. Um, I think it was TM language and it just needed enabling. Um, but I enabled it and, uh, there we go. Yeah i did that and then i applied for one of those i was like early 20s i think yeah early 20s and i applied for one of the laracon giveaway like for the tickets to the us uh which i won um so Incredibly grateful for that like a bit of a defining moment in my career really and 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. I went, uh, to Louisville as my first conference 2015 that was, and then, um, 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 messaging him on Telegram, as you do. There was a thing in Envoy 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 this one feature? He's like, you add it, I'll merge it in. So I got access to OneVoyer, I built the feature, and then that kind of, that was that. And then I was listening to Taylor's podcast and he was saying that, this is when he used to kind of record himself just talking about business and Laravel and that kind of thing. And yeah, he was saying that, oh, I'm thinking maybe I'll hire somebody for Forge kind of thing maybe we'll see it was like very loose very sensitive so i messaged him i was like hey i'm Your guy i you know i i do i need to say anything and uh he was like yeah send me a cv so i i did that and uh i 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. ([Time 0:06:46](https://share.snipd.com/snip/4df43161-78b7-493f-ade3-904c0c8d1621)) - **Forge 2.0 Started As A Cross-Team Vision** - Forge 2.0 began from a company offsite brainstorming session that prioritized organizations, teams, health checks, and zero-downtime deploys. - The Cloud redesign and shared design language guided Forge's bigger overhaul and product vision. Transcript: 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, I think 30 or 40. And we kind of sat there. And so the team leads were given 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 but like 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. I think it was Taylor was just sat there like, what if we just like completely like overhaul Forge, like Forge 2.0? Yeah. 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, oh, 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, but like what we were already working on. And until a bit later where we were like, okay, so we need these features. I'm going to add this, and this is what I'm going to ship. And then the cloud redesign really helped because I introduced a lot of our design language. So we knew that, okay, well, we can apply that to Forge. We need a designer. He's going to have to, or now jim but they're going to have to kind of apply the design language to forge every aspect of forge but initially like the feature set was organizations and Teams health checks and heartbeats and like zero downtime deployment and then it just like turned into this like well actually we can do a lot more than that let's set it up for the future. ([Time 0:13:30](https://share.snipd.com/snip/79b5a887-3111-42bb-8242-09fd57999f1a)) - **Fake SSH In Tests To Avoid Slow Integration Runs** - Test Forge by faking SSH/tunnel classes instead of running slow full server integrations. - Validate commands, scripts, and generated parameters via unit tests rather than provisioning live servers frequently. Transcript: James Brooks So we do a lot of faking basically. We try doing like actual testing where we connect to a server and we like run some code and like some of the bash and see what the output is. But it's actually really hard to do that because like, especially where Forge is changing configuration files on the server, you basically have to then delete the server, spin that Back up. We all know that takes time. So it's like, well, how often can you run actual tests, like full integration tests, which ends up being never, because it's just too slow and inconvenient. And if a test goes wrong, well, that's it. That server is kind of just dead now. Delete it and start again. So what we do is we have SSH wrapping classes which we call a tunnel and then we fake it basically and just make sure it gets a call that says you know ssh run whatever totally yeah and does It have the right script has it generated with the right variables and that kind of thing which we find like 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. ([Time 0:20:03](https://share.snipd.com/snip/e0f460ac-d347-4f66-96c7-e9401d75a95c)) - **Action Pattern + Cached Output For Deploy UX** - Forge uses an action pattern to change model state then dispatch provisioner jobs that run processes and record logs. - Process output is cached and polled by the frontend to simulate near real-time streaming without heavy websockets load. Transcript: James Brooks The action pattern itself is used for like dispatching jobs, essentially. And 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. So provisioners in Forge are like glorified jobs. They have some nice DX for us to set event logs. We can do like failed hooks. So if the process code of the command we're running is like 255, then what was that error? Was it basically what was the non-zero exit code and then kind of handled that? Maybe we need to reset some states 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 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. 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. What, what Forge's front end is doing is actually pulling that cache and refreshing it every few seconds. So it gives the illusion of real time output. ([Time 0:22:33](https://share.snipd.com/snip/aee4c19a-f184-4b71-887c-63ddd15c6564)) - **VPS Reduces Onboarding Friction And Speeds Provisioning** - Laravel VPS emerged from the desire to remove onboarding friction by becoming the server provider and speeding provisioning. - The team implemented prewarmed images/pools to enable near-instant provisioning and tailored features for VPS users. Transcript: James Brooks 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, if we just offered our own provider what would that look like because one of the biggest like the the biggest barriers to entry and 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 digital ocean we actually brought in like a wolf so it's like one click Yep 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 onboarded, but then like, what's the actual value for that? Because really it saved you a few steps. And then it kind of 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, provisioning takes like 10 minutes. What performance increase do you have to get to be like, hey, you could provision a server faster and it actually means something. So Taylor's original 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? And I was like, oh boy. 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 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. Matt Stauffer I was wondering about that. It's impressive. Yeah. I don't know what I'm allowed to ask you questions about. So I'm just going to ask and you tell me what you can't say. Okay. I am at the first two ideas I came up with, and I'm sure there's millions of other us, like 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 like a pool of servers that have already been spun up that are just being waited to hand off to customers When they want them and they make sure there's always at least a pool of you know 100 or something like that are you able to tell me any if i'm right on either of those and any more details James Brooks Or does this all have to be top secret for now 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. Matt Stauffer Okay, cool. James Brooks Great. More than that. But yeah, you've got somewhere with that. ([Time 0:25:12](https://share.snipd.com/snip/6c29d276-e239-4d6d-bd87-fd956f499da1)) - **Make VPS Valuable With Billing And Integrated Features** - Offer consolidated billing and managed servers to reduce friction for business customers. - Build value-added features (like integrated terminals and permissions) that leverage being the server provider. Transcript: 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 not, you technically get two bills because you're through forge, but essentially you only get built through forge, which is, which is nice. Plus, especially as like a 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 current subscription, which might be $39 a month, but then maybe it's a week later, you actually provision a server. Well, because we don't use first of the month billing, always anniversary. Like, that could change. And we can't pre-rate it. So we give you an invoice month to month from the date that you start provisioning the server. So you've only got two hour goings, 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 directly through the provider. Right. So we have to provide something for you. And that's kind of a nice way of managing that could be that Laravel VPS is like you get the terminal there. ([Time 0:29:20](https://share.snipd.com/snip/6a4a702c-9743-4ef6-8480-084527b0c9b3)) - **Rebuilt Monitoring As Scalable Microservices** - Health checks and heartbeats were rebuilt as independent microservices so they can scale separately from Forge. - The new health checks provide latency and status-code details from multiple regions, improving observability over Envoyer. Transcript: 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 Envoy, we wanted to do it again, but with like more usefulness. So like health checks, for instance, currently in Envoy, it's like, is it up? Is it 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. So you get some more insight. You get notifications around that as well. And then Heartbeats with the CRON stuff, we wanted to improve that service, make it kind of more natural to use. Like we felt that some of the way that we did it in Envoy wasn't quite as clear as notify me after. ([Time 0:33:16](https://share.snipd.com/snip/8b796b0c-4652-495a-8bd0-14f656bb280b)) - **Migrating Circles To Organizations Took Careful Work** - Migrating Forge from circles to organizations and roles required large data migrations and performance tuning. - The team ran dry-runs locally but still needed a careful production migration with temporary downtime and optimizations. Transcript: James Brooks So we spent last year like june onwards june till august just like implementing organizations and what that would look like and refactoring all this circle stuff to teams. And we had to do like a ton of migrations to do that. So we've actually been running organizations and 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. Before we had announced 2.0, we knew that that's the direction we were going in. We actually took Forge down for us for 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 needed, 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 run this migration locally on these like brand new matbook m3s and it takes like 20 seconds like it's super quick yeah production day comes around we're going to deploy It we're like okay we know that this works we've absolutely nailed this uh let's all jump on tuple and just get ready just just in case yeah and then um we took down Forge because the migration Took far too long to run. And we're like, oh, man, it really shows that these Apple M series stuff is serious business. Very powerful. 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, you know redeployed and it's been in production since August. ([Time 0:36:14](https://share.snipd.com/snip/38def71c-7984-46c5-8bed-93f2a19be066)) - **Use Feature Flags To Ship Big Rewrites Safely** - Ship major rewrites behind feature flags and keep working in the main repository to battle-test changes progressively. - This approach reduces risk by allowing gradual enablement while maintaining legacy compatibility. Transcript: 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 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 because it has been working. ([Time 0:39:03](https://share.snipd.com/snip/9d265480-d4a4-4b44-9927-3248fe295a53)) - **Roles Simplify Permissions And Aid Migration** - Roles group common permission sets to simplify access control and avoid overwhelming users with many individual toggles. - The team auto-generated custom roles for edge cases and allowed manual edits post-migration to preserve exact access states. Transcript: James Brooks Yeah. Brilliant. Matt Stauffer 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 is like 45 individual permissions currently, which is just like, it's A bit overwhelming. It doesn't really mean anything. I 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? 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 um so we knew that like an owner would just have every permission our 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 uh those kind 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 yeah 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 Matt Stauffer Okay which is yeah that was 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 if they have this very common set of permissions we'll put them in the developer group and stuff like that yeah exactly that's very clever because 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. James Brooks Yeah. I mean, it's not going to be perfect, but it's like, for everyone that we've, it's good enough. Yeah. And you can always go through and edit that as well, right? Yeah. You can go and change those roles. You 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 can manage the billing side of things for you and do whatever else they need to do as well. ([Time 0:40:02](https://share.snipd.com/snip/8ca03b87-6c91-41d4-bded-264946ab8938))