Matt Stauffer:
All right, welcome back to the Laravel podcast. This is a special edition live at Laracon US with Taylor and me. And Taylor just gave and led, I guess, the keynote announcement. So if you have not seen that keynote announcement, I would start there because we're trying not to cover things that have already been covered there, but instead go a little bit deeper and answer some questions some folks had. So if you haven't seen that, take a pause, go check out the keynote. It's two hours long, but it's worth it.

And then we're just going to dive into some of the things you guys covered there. So thank you so much for hanging out.

Taylor Otwell:
Thanks for having me.

Matt Stauffer:
So this is, you said you've been at 20 something Laracon's at this point.

Taylor Otwell:
This was my 23rd, counting all the international Laracons. I think I missed a Laracon year at once. I've missed a couple of Australia's and an India maybe, but yeah.

Matt Stauffer:
Incredible number and clearly you're winning in terms of the numbers that you've been to I'm curious to for us to eventually see like who's number two because we have that from speaking right not from attending

Taylor Otwell:
Yeah, it's a good question. mean, on a related note, I think there's only three of us remaining that have been to every Laracon US. Really? It's me, Eric Barnes from Laravel News, and Bill Kondo, who's just a long time community member. He's doing some photos here at the event.

Matt Stauffer:
Fidao hasn't been all of them?

Taylor Otwell:
No.

Matt Stauffer:
Oh my gosh, yeah I missed the first one. We were gonna go to the first one and then some big client thing came up. And I was like, I mean, I don't know if this conference is gonna be life-changing, so we'll go next year. And now I'm like, oh, I could have gone, you know?

Wow, okay, so that's like, I mean, obviously you're the OG, but just to be in that small group is pretty impressive.

Taylor Otwell:
Yeah, it's pretty crazy.

Matt Stauffer:
So speaking of impressive numbers, I told Taylor all this, but I'm kind of organizing this around different sections you're talking. The first piece is I just wanna talk about Laravel and Laracon.

You said over 70 people working at Laravel?

Taylor Otwell:
Yeah, that's right, just over 70.

Matt Stauffer:
How does that feel, like as a person? Not as a business owner, successful investor, but like as a person.

Taylor Otwell:
It is pretty surreal, you know, to like look around and there's all these people in red shirts and they're working at the event and to think, especially thinking back to how it started, you know, with some of those first conferences or even when I just first started working on Laravel, never would have even been on my wildest dreams that it would be like this. So that is definitely surreal, but honestly, the team's been great.

Matt Stauffer:
Love that.

Taylor Otwell:
Everyone's really easy to work with, they're excited, you know, I they're excited about what we're building here at Laravel. It's just good energy.

Matt Stauffer:
Do you know how many are here? I don't know if you actually have that.

Taylor Otwell:
I think we have about 40 here.

Matt Stauffer:
That's amazing. Because I thought you were still at like 40 total and you said 70. I was like, oh my gosh. Sure. Okay. And so, I mean, from my experience from running a company, like there's these different kind of shifts of like at this size, I know everybody. At this size, there's a layer of management in between and at 70, you don't have this like deep, close personal relationship with every person. And I know you know their names, you know who they are, stuff like that. But is it weird for you at times where you meet somebody and you're like, We are on the same team, we work for the same company, you technically work for me, and yet we haven't got a chance to build that relationship. And what do you do if that's the case?

Taylor Otwell:
You know, it is a little bit weird and I don't really think of it as like, and maybe I should, I don't know if I should or shouldn't. I started as a programmer and of accidentally became this business guy. And I don't really look at it as like, you work for me or anything like that. To me it's just more like, look, we're all kind of on the same team. Because that's how it always was when there was just like five, six, seven of us. And even though I set kind of the strategic direction to do a lot of the product direction, it's really such a team effort that I just look at it as a big team and we're all kind of working towards the same goal. Yeah, it's pretty crazy and we actually have an internal Laradex, kind like a Pokédex, if you play Pokemon, where it shows you a picture of a Laravel employee and you have to type the name in and it tells you how many you get right out of all employees. So people have definitely been brushing up before the conference.

Matt Stauffer:
I was going say, did you make it for the conference or it already existed?

Taylor Otwell:
It existed, it wasn't built specifically for the conference I don't think. But even so it can be challenging because people sometimes they don't look exactly the same as they're in the Slack.

Matt Stauffer:
Sure. Imani has been telling me for years at this point that I need to get one of those because I come to the conference and there's all these people who I'm like, I know I know you, but I can't remember where from. Yeah. And so, yeah, like that absolutely makes sense. OK. So when you started Laracon, you were the one running Laracon. And for a long time it was you and sometimes you'd have somebody helping you, at times other people had been involved, and then you also had event planners doing it. Last year I think was the first year where Accel was actively involved and some of the folks they brought in. But I feel like this is definitely the most produced Laracon. And one of the things I was wondering, and people have often said, well, is investment of money, is the increase of the size gonna change kind of like the tone of the organization?

Part of it was Aaron's initial talk. I really think it said it in a very personable, very friendly way. But I definitely expected a level of quality and production to lead it to feel less personal and relational, and it hasn't. Is that something you've been doing intentionally, or do you think that's just kind of a natural outflow of how you do things?

Taylor Otwell:
Yeah, mean, think, you know. This is the first year where we've had kind of the marketing team really run Laracon. Even last year, we were growing the company. We had people on the marketing team, but they'd only been in the company for a month or two and Laracon was well underway being planned by then. But they were able to attend and like see the vibe, see what it's like. And I think that gave them a good idea of like, okay, we know what kind of event Laracon is now and we can kind of take it and run with it. And they've grown it much bigger this year. And a lot of that is because when I was doing it mainly myself, I tried to really streamline it down to the essentials because I was doing it all myself.

But now since they have a team of people, they can take bigger swings and have more fun, cool stuff going on that is great to have, but I was just overwhelmed to take that all on myself.

Matt Stauffer:
Well, you said a lot. I mean, you're not necessarily talking about Laracon, but talking about other things you're like, having a larger team allows me to do things that I would have wanted to do, but never could do. Yeah, totally. It sounds like this is part of that.

Taylor Otwell:
Yeah, like it would have been great to do all this stuff before, but it just like, you know.

Matt Stauffer:
You can only do so much. Yeah. OK. So one last little piece about that. I just got out of a talk. Dave Kiss, I think. He gave a talk. And this guy from Mucks who is a video processing thing. And what I expected it be was not what it was. And I really was delighted by what it was. And it ended up being a talk where the guy basically said, I'm not a Laravel programmer. I learned Laravel basically for this talk so that I can, you know purportedly it was sort of like so I can get you all excited about my product right and so it seems like it's gonna be product sales but instead ends up being this very beautiful like kind of inspirational thing of like wow you can do so much with Laravel and it's really wonderful but also he had the mindset of somebody who doesn't know Laravel but also the mindset of a teacher and so he ended up saying so yes if you don't know PHP this is what packages is if you don't know and I was like that, that was really incredible because I know there are a lot of people here who don't know Laravel and probably more than ever before. And usually in the past when we've thought of people coming into Laravel, we think coming from PHP, right?

Like it's a Symphony developer, it's a WordPress developer. And more and more it's people coming from boot camps, coming from React, coming from wherever else. And so it was really fun kind of watching him saying, hey, are you a JavaScript programmer? Let me gently walk you in. Was that intentional? Did that just kind of work out that way? Because it feels, sorry, I'll ask second question.

I feel like you've been doing a lot of work lately, whether with the way you've structured the starter kits or anything like that, things are moving more and more towards being accessible to non-PHP programmers. Is that intentional? And was this intentionally part of that, or did that just of come out of, you know, wherever?

Taylor Otwell:
Yeah. So it is intentional in the sense that we're trying to sort of streamline the ecosystem. You know, Dave's talk was just sort of a happy coincidence. I think that's great that worked out that way. Um, but the Laravel ecosystem is vast, you know, and I think we have 25 plus open source packages. If you've been in the ecosystem a long time, like it all makes sense. And like, of course, you know, when to use this, use that. But if you're just coming into it, I really want to streamline down to like the essentials. And there's been a lot of kind of things that have come out of that, like the php.new, easy installation of php.thing is like one aspect of that. Or the way we even structure the getting started docs, or the new Laravel bootcamp that's coming out. know, trying to like, okay, what are the core pieces that we want to emphasize? Because we don't want to overwhelm people with a list of 25 open source packages that they have to look through and understand how they all fit together.

I think Vue.js, think Evan has a very similar philosophy about this with Vue.js of like, you can start really basic, the framework can get really complex, you know, if you're building like a really serious app, but I think in a similar way, like, Laravel, I want to start with the simple things and let people gradually work their way into the more advanced things so they don't get overwhelmed.

Matt Stauffer:
I love that. I I told you this a couple years ago, but I went on a podcast with some JavaScript people saying, teach us Laravel. And I'm like, oh, it's so easy and it's so clear. And they're like, but there's so many files when you first install it. And I never thought about it that way.

Taylor Otwell:
We basically want to like gradually reveal complexity, know, like when people are ready for it.

Matt Stauffer:
Yeah, no, it's a really brilliant way to do it. So I love that. Well, speaking of Laravel the framework, my next section is about Laravel the framework. And you introduced a lot of surprisingly number of new features given just kind of how much you guys have pushed out and how much you've started pushing work out just every two weeks rather than waiting for the big announcements. And yet there was still some really exciting stuff here. One of the things I like a lot is the attribute binding. And for those who are not familiar, basically, if you have an interface, normally if you want to say how should the container resolve this interface, you have to go to a service provider and say, here's how to resolve it. And you guys introduced a way to put an attribute directly on the interface saying, hey, here's how to resolve it. One of the things you mentioned in your talk was this is a way that allows you to avoid having to do it in a service provider. And I was curious, do you kind of have a mentality where you're like, service providers are a bit of a smell?

Taylor Otwell:
I think so. I think in a perfect world I would never like to have to go into a service provider. Don't worry.
We are not are moving service writers in the same way we still haven't removed the command bus. But starting in Laravel 11 when we tried to simplify the whole file system and we introduced this bootstrap slash app file that is kind of like the routes file equivalent of bootstrapping your app where it's not really class based, it's just a really simple file. To me the word service provider is just so heavy sounding. It just sounds like such an enterprise complex app.

It goes back to like new people coming into the framework, right? They see the word service provider and it's like, whoa, this sounds like some real computer science type stuff. Just trying to like really simplify that down. So anything you can do in a service provider.

Which maybe people picked up in my talk you can actually do in the bootstrap app file by using like the booted or booting callbacks. So yeah, yeah, I guess you could say I'm sure I try to like stay out of that and I think in a perfect world it would not be a thing that new comers in the framework really interact with.

Matt Stauffer:
Yeah, I mean one of our most often missed things even when interviewing relatively senior developers is I asked them I'm like what's the difference between the boot and register methods of the service provider? Yeah, and people usually don't know because it's kind of scary and overwhelming.

Taylor Otwell:
Yeah, yeah.

Matt Stauffer:
So yeah, I love that. I smelled you say it and I was like, I think that's where he's going. I really liked it. OK, speaking of things I really liked, automatic eager loading. So when you started your demo, you were basically saying, here's what it looks like to have eager loading and N plus one problems. I'm just sitting here being like, I just wish I never had to deal with this. And then you announce a feature that is literally you write this one method and then you never have to think about it. Now, I'm sure there are some downsides. I'm not even fully aware at this moment what they are. But.

Do you think of this as being sort of like a 95% of apps should probably just use this and then we have to be aware of the edge cases? Do you know what they are?

Taylor Otwell:
And there's really not that many edge cases. You know, kind of like I said during my talk, if you're just spitting through models and you're spitting through relationships and you're not adding additional constraints to the relationship, you can just turn this on and not ever think about it. We have not really seen any edge cases or problems with that. And if you need to add constraints, you can always just still use with, even if you've used this feature. If you've already eager loaded something, it won't try to like eager load it again or whatever. So you can just do all your eager loading you want if you need to add additional conditions to the query. But otherwise you can kind of just let this thing rip.

If you spin through a relationship and it hasn't been eager loaded, it will just do it just in time. Really, it's a cool feature, but it doesn't have to be that scary if you think about it. You could always say, users arrow load comments on an existing model. And really, all this is doing is doing that when you need it.

Matt Stauffer:
It basically looks ahead and says, you're about to make this call. I'll do the load. Which is very simple. And yet I feel like that's like we do a lot of like.

Taylor Otwell:
Call the load method for you.

Matt Stauffer:
Why is your app slow testing for people? And just like this alone will save people thousands of dollars in consulting and people with us just because it's so common to accidentally forget you're doing it or to not know about it. Yeah, love this one. Very happy about it.

OK, when you're talking about writing the framework, you mentioned you had a value of it feeling cohesive and like it's written by one person. And we've talked about this on and off. But I was curious if you think about sort of like there's a value to the end developer that comes from a cohesively written thing. What is that value? What are you aiming for? What's the goal that you want to accomplish by it feeling cohesive?

Taylor Otwell:
I mean, I think like when you're using a tool that kind of has that feel and you read through the docs, everything kind of like makes sense and the way it fits together and everything feels like really logical. Sometimes when stuff is like designed by committee or there's a bunch of different sort of like competing voices on how things should be designed, it feels like kind of disjointed. The features, this feature works one way and this feature does a similar thing, but it works in a totally different way and it can kind of become, you know, it just feels like a book written by multiple authors and you can just sort of tell. So I really try to make everything, and it's a big part of what I do when I review the pull request is like kind of smooth over things of like, how would I have written this or said this or built this so it all feels like one author even though it's literally thousands of authors at this point.

Matt Stauffer:
Yeah, but the thing that's great is that it's thousands of authors, but the API feels consistent. You get a lot of that sort of like it just does what you think it's going to do. I've said this so many times, but I just love where I'm like, I'm going to guess that based on what I know about the rest of the framework, this new thing has a method that says this. And it almost always just does. And I'm like, I love that. As you're thinking about that, do you have any parts of the framework where you're like, that's so embedded, I can't change it, but it feels like the API is wrong? Or if you hit that, do you just change it?

Taylor Otwell:
Well, like the scopes thing, which I skipped over in the demo because I knew we were already going to be running long, which we did. It's kind of a good example of that where when you were defining local scopes on Eloquent models, you used to have to prefix the method with the word scope. And to me that always felt like, man, that is just kind of gross and magical in a way that was kind of annoying. But we introduced a scope attribute so you can just name the method normally but put the scope attribute up in the method.

There's always like warts in the framework that I'm like, you that was one of the last remaining ones that really bugged me. And I can't think of any others that just like drive me crazy in the way that did.

Matt Stauffer:
I was wondering if like accessors, because you you guys change them to use attributes.

Taylor Otwell:
That's a totally similar thing. It was that method prefix and suffixing stuff. That stuff kind of drove me bananas.

Matt Stauffer:
Well, it's cool because a lot of times I don't think that we think of...

A lot of folks who are not like bleeding edge people are not looking at attributes like always saying, here's all the things I can do with them. And sometimes people do them because it's the new sexy thing, not because it's better. But one of the things I'm seeing you use it for is attributes give the ability to pass metadata along with classes and methods that we previously had to use at best type hinting and return types and at worst prefixes, you know, like magic G-E-T underscore, whatever, you know, like it's like, so yeah, it's cool that you're saying here's new technology and we can use it to address some of these longstanding concerns.

Taylor Otwell:
Yeah, and I think there's probably a few more things we could do. Like, I mean, you can imagine like before attributes existed, we had to use sometimes properties for these kinds of things. So like even on an eloquent model, to set the table associated with it as a property. Yeah, that's kind of the thing that you could sense might be an attribute like a table attribute. I don't know if that will ever happen, but I'm just saying like that's a good example of like things we would typically use properties for. Yeah, some of those use cases can now just be attributes that even make more sense as attributes.

Matt Stauffer:
I hadn't really thought about it because an attribute is related to a class in a different way than a property is. And you start asking, like, which makes more sense?

Taylor Otwell:
I think like what you said, it's kind of like metadata about how it behaves or how it works. And so I actually have it on our open source kind of to-do list to go through the entire docs for everywhere the word property occurs in the docs. And just look at it and say like, should this be a property or should this be an attribute? And just do a thorough audit of that because we've been getting PRs of people adding attributes and sort of like a patchwork, like random places. And I keep saying like, I want to do this sort of like all at once so we have like one consistent philosophy towards attributes and like when we use them when we don't. So we don't end up with sometimes we use properties sometimes attributes and that feels really odd.

Matt Stauffer:
That makes sense and that's helpful for me because I'm still trying to get a handle on like when does an attribute make sense and when do I think that person ever used it and I feel this is starting to kind of like slot in like there's a system that makes sense so yeah.

OK so this may not be relevant at all but Ranger which is the that's the name right the tool that's.

Taylor Otwell:
It's the underlying sort of tool, that power's Wayfinder.

Matt Stauffer:
But it sounds like, and when I saw Ranger come out on GitHub, I actually thought it was for AI. And I'm guessing they probably use it in some of Boost to kind of like discover what tools you're using.

Taylor Otwell:
Yeah, I'm not sure actually if we're pulling in any Rangers stuff, but we probably could.

Matt Stauffer:
Yeah, and I was curious for you because I know that like often when you build these tools you're sort of like well it makes sense just for there to be a boundary but I don't necessarily know what else I'm gonna use Ranger for. When you look at Ranger do you get like a vision for the future? You're sort of like maybe we'll come up with something.

Taylor Otwell:
This was actually something that Joe Tannenbaum and I were, I guess, surprised about just here at Laracon is sort of the interest in Ranger. Because it was very much like a footnote at the end of the Wayfinder section. And Wayfinder is this tool that sort of automatically generates types for a lot of your backend stuff so that you can consume it on your front end in TypeScript with type safety and stuff. And Ranger was like this underlying code inspection library that spits out JSON about your models and all that. But people seem to be interested in that, like know our level of tool for various things. I've had a few people come up to me and talk about that. We found surprising.

Matt Stauffer:
Yeah, I mean I saw it somebody posted and said hey look new Laravel tool. So I looked over it and it was saying things like what coding methodology it's using is it using viewer react is in EDD or whatever and I was like I wonder and that's why I thought AI was like what would the biggest benefit to have a structured format of saying here's how this app is built and I was like oh AI but I even then I was like there's got to be other fun things we can do with it. I don't have any ideas. That's I was curious. So sounds like a lot of people are just kind of interest peaks. Yeah, see where it goes. Yeah.

Taylor Otwell:
Yeah, I'm curious to see what people build with it.

Matt Stauffer:
Okay last thing about Laravel the framework. What's the future of Dusk? Do you have an answer here or is it sort of like, we'll see how it pans out?

Taylor Otwell:
I knew Nuno pinged me about this actually a week or two ago before the talk and he was like, hey, you know, this browser testing thing in Pest, it's super fast. What should we say about Dusk? And you know, like...

We've always been big fans of Pest. We use Pest here at Laravel and of course Nuno's here at Laravel. And you know, I have no problems putting at the top of the Dust documentation, Hey, like it's too slow.

Matt Stauffer:
Try out Pest.

Taylor Otwell:
You know, things change, you know, and I think the Pest browser testing probably is actually a better experience than Dusk. It's faster. I think Nuno cracked a few things that we didn't crack in Dusk, you know, years ago about being able to like assert authenticated after you do something in the browser.

Or all of that stuff is like a big unlock for browser testing that was just super annoying in Dusk. So, you know, like we just want things to be better. You know, I think it's better for Laravel and we want people to use the best thing. And this might be the, you know, the next evolution of browser testing for Laravel. we don't, don't have any problem like officially recommending that if that's the case.

Matt Stauffer:
And I mean, I'm sure there's going to be some people who are like, hey, look, we've built everything in Dusk. You're like, it's not going away. Yeah, sure. And you may end up still getting some new features because there's some things that probably Dusk can do that this will never be able to do. Cool. But it also might be like the default, do you need to test interactivity in this way, now comes into Pest unless.

Taylor Otwell:
Yeah, and the nice thing is Nudo built the API to be almost the exact same as Dusk. So if you did actually want to migrate, like it should not be a super heavy lift in terms of changing all your code.

Matt Stauffer:
Nice. Moving on to Laravel theproduct company. So you did talk about some announcements for Forge, Nightwatch, and Cloud. To me, I Forge was the biggest. This is Forge 2.0, whereas Nightwatch and Cloud were all very cool. There's kind of one big feature for Cloud that I want to talk about, but I want to start with Forge. So Forge has been working, right? Forge is the product that allowed you to be independent in a way that...

Nothing else did. And I'm not saying it's the only reason that you were independent. But Forge is like your initial baby SaaS launch. And it's worked fine. But at some point you said, it's working fine. And we're building new products. And we're investing in things that can make us more money. And even though I might not be making any more money out of Forge as a result of this, I want to put a whole bunch of time and energy into Forge. Is it hard to make decisions to do, paying money into doing ground up rewrites of things that technically worked but you know they can work better, like circles?

You know, like what does it feel like to make a decision as a business owner to like do something like that?

Taylor Otwell:
You know, I mean...

We have many thousands of customers using Forge. We very much didn't want to leave them out in the cold.

Matt Stauffer:
Thank you.

Taylor Otwell:
You know, Cloud is the best way to ship fully managed layer by applications and scale them. Yeah. But like I said, we have so many customers on Forge and I think we'll always have customers on Forge that just want to manage their own server. And we wanted to not only unify like the design language between Forge and Cloud, but bring some of the features into Forge that have been sort scattered around the ecosystem, like zero downtime deployments, and just unify those into Forge. Because I really believe that Cloud, Forge, and Nightwatch are the future of Laravel, that kind of product trio.

So I'm happy to bring all this modernization to Forge. It does hold a special place in my heart, just being the first product that kind of made Laravel successful as a company. So I'm excited for people to get their hands on it.

Matt Stauffer:
I'm very excited. I've been Forge's biggest advocate this whole time and I know that some people when Cloud came out and said no like it's gonna Forge gonna go in you've always been saying no. But I am very grateful that you guys kind of really put your money where your mouth is in terms of really saying Forge is here to stay and it's gonna keep going and further twitch your money when your mouth is where you said basically I'm going to take paid features that are the primary reason people are going to get Envoyer and I'm just going to make them for free. I mean, number one and number two reasons for Envoyer are Zeroed Out Time Deploy and Heartbeats and Health Checks. And they're now both in Forge for free.

So what's the future of Envoyer at that point? Do you think it's more of a builder type thing, whereas Forge is still more of like a, it's just command line? Is that the big difference?

Taylor Otwell:
I mean, I think there's still some people that are going to continue to use Envoy for a couple of reasons. One of the reasons is the multi-server, zero downtime deployment, orchestrating that across multiple servers. Forge is sort of like single server downtime deployment. It's really like a single server management tool. Forge doesn't provide a lot of tooling for linking servers and defining apps. That's more of like a Cloud thing. If you need to scale up across replicas and you need load balancing, that, Cloud is probably the best route for you. With Forge, or with Envoyer as well. We have customers use Envoyer that are not using Laravel deployment solutions at all. So those people will probably continue to use Envoyer. They're not using Forge or Cloud. They're using Envoyer to deploy to custom infrastructure. you know, there's a couple sort of more niche use cases for Envoyer that I think will stick around. But I think most people will probably stick to Forge Cloud or not.

Matt Stauffer:
That's sort of like the Dusk and Pest conversation. Like you're going to use Forge's zero time time downtime deployed by default, but there are reasons why. And one other note for you guys to just have is, Envoyer allows you to build those kind of flows in sort of like a, drag and drop, but it's a very visual way where you don't have to be a programmer in bash to say, start the release here and then do this and then publish the release here. So I think there's some people who may prefer that interface as well.

Okay, this was one that's asked from the internet, should we expect that Forge's pricing is gonna be changing as a result of all these new features?

Taylor Otwell:
I don't think it will change in a way that makes people upset. If anything, it may make people happier. It's something we'll revisit, especially as we think about bringing Forge to new audiences. As I showed in my talk, we were running a Nuxt app on a Forge server in server mode. It wasn't a static site generation. For those kinds of customers, we may think about what is the best way to price Forge to attract new audiences.

So, like I said. I don't think we'll change in a way that people are upset about if at all and it may not at all but it's something we'll definitely explore you know this fall as Laravel VPS launches and we start to think about how do we get how do we bring Forge to new audiences that are maybe underserved and don't have this kind of tooling available in their ecosystem and would would be happy users of Forge.

Matt Stauffer:
Okay. And I didn't write this one down, but I just remembered one of the cool things about Forge is that you have those SSH directly in Forge. And you can also share those sessions. Is that unique to Laravel VPS or is that for all providers?

Taylor Otwell:
Right now that is unique to Laravel VPS. It's a feature we actually built at our Forge hackathon. And I'm super happy with how that turned out. It's just so convenient to just hit a keyboard shortcut and be in a terminal. I will use that quite a bit, I think. The collab feature was sort of a fun thing we threw in there, you know, and we'll see how much people use it. But it was fun, nevertheless. And it is a cool thing to be able to hop in a terminal session that's sort of shared with your teammates.

Matt Stauffer:
And I appreciate hearing that because we've talked a couple times over the last year where you did something and people were saying, why this or why And you're like, because it was fun and I working on it. The same thing with the Work OS. People were reading stuff in Work OS and I was too at first. I was like, curious. And you're like, because I was playing around with it and I was making an app and I thought it was really cool and so I did it. And I love that that's still in there.

Taylor Otwell:
Yeah, you we were at the hackathon and the terminal was basically built like the single-player version of the terminal. We had the POC working and we were like what if there was just like a little toast when someone else starts a terminal where you could just join in a watch because we're using reverb behind the scenes. So we have presence channels We have web sockets so we can kind of do that stuff fairly easily, you know and so we decided to swing for it.

Matt Stauffer:
That's very cool. that, so kind of talking about that being, at least right now, a VPS specific thing. We were talking in the car on the way to the conference this morning about what would motivate people to move. And let's just say DigitalOcean right now because VPS is on DigitalOcean. If I've got five servers on DigitalOcean run by Forge, what are the things that motivate me to move over to Laravel VPS? And you told us a few, you said, there's the free ingress and egress for certain data things that you guys are gonna offer, but I wanted to ask you, what do you think would motivate people, or is it of like, you know, whatever, start your next thing on VPS.

Taylor Otwell:
I think for us Laravel VPS is definitely more of like a long term, our long term thinking around Forge. I definitely think it makes sense for like net new projects. One, you just get the server instantly and you get some cool new features like the integrated terminal. You get your metrics right there in Forge and you just, you only have one Forge bill. You don't have to go sign up or manage any other service. But again, like long term, as I think about, you know, expanding the audience of people that are using Forge, we want the onboarding experience to be really great. So if they sign up for Forge and they're like, oh, I immediately have to go over to some other server provider, which one do I choose? I gotta sign up for that, I gotta put my credit card there. We would really rather just have one quick flow where you can sign up for Forge and immediately have a server in seconds. And to me, that is really the big long-term unlock with Laravel VPS and Forge. And I think it was just kind of must-have as we start to think about the threshold of like, pain tolerance devs have these days is pretty low and we can't just immediately sign people up and then send them somewhere else to grab an API key. That's just not good enough anymore. So we needed this in Forge and I'm excited to see how it plays out over the long term.

Matt Stauffer:
I mean, I told you before several times that I was excited about Cloud because we have our clients and we say, up for the smallest Forge account, sign up for the smallest digital account, share the keys with us, yada yada. So I was excited about Cloud, but there are some clients who are like, managed is good, but for some reason cloud is not a good fit for you, usually because they need something a little bit less managed. And so we have been sending them through the traditional format. And I'm like, okay, now I have my two patterns. It is gonna be, go sign up for Forge and VPS, it's gonna be a single sign up or whatever, and then go sign up for Cloud.

And that really simplifies the workload for us. And a lot of these times you guys have been talking about developers, which I'm very grateful for as a developer. But a lot of our clients who are not super technical but own an app are really benefiting from these Cloud and kind of Forge improvements.

Taylor Otwell:
And I think you know one thing we're interested to explore which I kind of mentioned in my talk briefly is like for the growth and business plan customers Like we want to offer you discount incentives to use VPS and the more you use VPS the more we would like to do that, you know. So I think there's gonna be other other reasons you might choose VPS, especially as you start to scale up Which is particularly relevant for like our our agency partners and things like that where hopefully we can make it we can incentivize a lot of Laravel VPS development I think it's a good user experience for the customers clients but also just from a pricing perspective.

Matt Stauffer:
Well, I'm also really happy that you're putting on a digital ocean because personally that's what I put all my stuff on. And so I was just so I'm like, if you're to say AWS, like how's that going to change my workflow? You put on DO and I was like, great. I'm just going to keep using DO but now easier.

Taylor Otwell:
Yeah, DigitalOcean's been a great partner. We love working with them. I've used DigitalOcean a lot in the past. It's a good partner.

Matt Stauffer:
OK. So I want to talk about Cloud. I know that you already described the preview environments in your talk. one of the things about preview environments is because I've talked with some folks who tried to build them for Forge in the past. Just seeing it sounds like a simple idea, right? You make a pull request. That pull request spins up a preview environment. You test it. It deletes it. OK, that can't be that hard, right? That's just a couple shell scripts. And we could see some of the complexity that came through as you started showing, or whoever it was that showed it showed the different, well, you got to do a trigger. And the trigger's built this way and whatever.

Can you talk a little bit about what all went into building the feature?

Taylor Otwell:
You know, there's been preview environments have been something that have been more predominant in maybe the front end space historically. And you know, it is quite a bit easier to, if you just have HTML and CSS and JavaScript, to spin up a new environment and throw that out there. But with Laravel apps, it has always been a much more complicated topic because many of us are using MySQL databases and Redis caches and queues and object storage. And it's not as simple as just duplicating that because we don't want to mess up our existing database stuff. So when we started building preview environments for Cloud, which was something people have been asking for and even trying to build themselves using APIs on Forge and things like that. We knew it was going to be something we really needed to think about and get right.

A lot of it revolved around the resources attached to the app. So that's something we tried to solve. So when you create a new automation in Cloud and you say, when a new PR comes into this app or this repository, I want to make a new preview environment, we do give you some options about those resources. So you can either use the same database, you can create a new database on that database server.

A MySQL instance can have many databases. So we can make a new database that's isolated from the other databases. And the same with cache. We can use the same cache. We can make a new cache for you. And once the PRs merge, we tear all that down. So it's super convenient. You can also inject environment variables that are specific to preview environments if you need to maybe use a different email sending key with your email provider or whatever. So we really try to think about it from a Laravel application developer perspective. What would we need to make preview environments viable?

It was a big project, I'm really happy with the way it turned out. I think it's a really big unlock on Cloud. It's something that's really hard to hand roll and do it right, like with your own infrastructure or your own scripts. It is just not trivial. Yeah, and I think it worked out really well on Cloud and feels really nice and easy to use.

Matt Stauffer:
I mean, even in the midst of you talking, I started thinking through some things I had not considered. I'm like, oh yeah, it's going to make the database, which I knew was hard. But then what data is in the database? Is it migrate fresh? Is it a copy of this? Is it something? So is there tooling kind of for all of that?

Taylor Otwell:
Yeah, there is tooling for all of that and I think during Joe's talk he recommends, know, like normally people will if you're using Cloud you would have a production environment and maybe like a staging environment. Yeah. And you would set up your preview environment automation to duplicate the staging environment. You can have it size down the resources. So if your staging environment is normally let's say like eight gigs of RAM of compute, maybe you only need like one gig for your preview environments and you don't need to spend the money for all the power on the preview environments.

Matt Stauffer:
Nice.

Taylor Otwell:
And you know same with the database and all of that. So we tried to really think through all of these work and it was actually pretty complicated to try to like distill it down into something that feels very simple and obvious to use and yeah, but it's out today and people can give it a shot.

Matt Stauffer:
I'm excited to try it out. I'm actually really looking forward to it. So one last thing before my last thing. The last thing before my last thing is with Nightwatch, there were a few really cool features that you guys pushed out that I don't have big questions about. But the dark mode, light mode thing was what I was most curious about. I know that enough time and effort and energy was put into that that I keep talking about money, but just like that's a lot of developer time for a light mode, dark mode switch. Tell me about that. Do you think of it as like a we just should always have both sides?

Taylor Otwell:
The Nightwatch team is very fast. They're a very fast, productive team. I don't know the exact amount of hours, but actually it was not months of time. They're pretty fast. We started joking around about the light mode way back before Nightwatch launched. There were some early screenshots. I think Jeremy, the designer on Nightwatch, had mocked up. like, this would be kind cool at some point. Nightwatch has only been out for maybe five weeks now. We just had a few small updates with the cache stuff in slack integration and then of course the day shift light mode. But yeah, it was just a fun thing You know, I cool the team is so fast. They can rapidly build stuff kind of mind-blowing honestly.

Matt Stauffer:
I love that and I one of the things I think it's I hear people who don't know you and don't know Laravel but who are in the Laravel world Reflect on kind of decisions you all make and I think the biggest thing that I feel like I want to correct when I'm hearing that is people looking at it as if because of the last, you know year and a half of Laravel's history this is now big company making big company decisions. That's why a lot of these things I poke at is like well what is the financial motivation behind this whatever because if it is a big company those are gonna be your answers and each time your answer is because it made sense, because we wanted to, because it felt good, you know?

Taylor Otwell:
Sometimes we do projects that are fun, that the community will like. We always try to also balance projects that appeal to the solo developer all the way up to enterprise customers. That's maybe one of our biggest challenges is just balancing all of that. And it always kind of has been, even when Laravel was a smaller team.

Keeping everyone happy across the extremely wide diversity and variety of Laravel users has always been a big challenge. Maybe even more so now, know, as the scale of the company has gotten bigger, kind of the stakes have gotten bigger, but it's always been a challenge.

Matt Stauffer:
Yeah, and the breadth of diversity of Laravel developers I think keeps broadening as you get more and more people who don't know PHP at all and you get these bigger and bigger enterprises using it. It's like there's just...

Taylor Otwell:
It's such a hard, like, who is the typical Laravel developer? Or what is the typical Laravel company is almost like this impossible question to answer. In the same way it is for other frameworks, like Ruby on Rails or Django. They're just general purpose programming tools, so it's hard to make these specific audience to define that way.

Matt Stauffer:
Yeah, okay. I had one last question for you before I asked this last question, which is not technical at all. Is there anything we didn't cover today that you wanted to make sure we got to?

Taylor Otwell:
I don't think so, but we do have a blog post up of everything we announced in the keynote, so you can go out to the Laravel blog and catch up. If we did miss anything, it should be there.

Matt Stauffer:
Well, I did ask on Twitter like I always do and said, hey, does anybody have any questions for Taylor? And I only give them a couple hours. We didn't get a lot. But Will Kelly, who is a technical reviewer, recruiter, he was here last year. And we talk about sneakers and watches and other goofy stuff. OK, so he said, what kind of sneakers does he vibe with? He looks like a J1 low guy. So you've got to tell the people.

Taylor Otwell:
I don't think I have any Air Jordan 1 lows right now. A lot of the sneakers I bought when I like got older were like sneakers I always wanted as a kid, but we could never like afford or like my parents we just never got them. So like I stocked up on Jordan 11s because that was like the hot basketball shoe when I was like in know middle school or whatever. So I bought like some of those like holy grail shoes that I always wanted as a kid. These days I've been wearing like just simple low Reeboks or like you know dunks or something something like that. I'm getting old. I can't be like too cringe, try too hard, my kids make fun of me.

Matt Stauffer:
You've to really walk that line like you can't be too dorky, you can't be yeah, there's...

Taylor Otwell:
There's like the cool dad that tries too hard.

Matt Stauffer:
Nobody wants to be that guy Awesome. Well, thank you so much for hanging out as always, of course Thank you for everything here, but thanks for your time answering all these questions. Okay. We'll see you all next time.

Taylor Otwell:
Yeah, thanks very much.