Laravel Cloud Office Hours

Okay. Hi everyone. Happy Tuesday. We should be live. I always say it like I have no clue, but we should be live. Hi everyone. I hope everyone's having a great Tuesday so far. It's really cold here today, right? I heard it's snowing. Really? Where is it snowing at? That's what Hannah and Ethan said. Oh yeah, Hannah's like more in a mountain town, so she's like I think a little bit higher elevation, so it probably is snowing there. It's not snowing here, but it is like 30 degrees, so it might snow later, so I would put past it. Zero Celsius for everybody else listening. Yeah, it's cold. Maybe even one technically. You remember the time I think it was you was I think it was me and you on stream. We were talking to Florian and we were like, "What?" Because I said military time. He was like, "Military time?" And I was like, "What do you call it?" He's like, "Time?" Time. Yeah. I feel like if we asked, "What do you call the temperature for Celsius?" He'd be like, "Temperature." Temperature. Yep. It's just Celsius everywhere else. But hi, Florian. Welcome in. I always make the joke when uh people from Europe are asking or saying something about the temperature. I'm like, "Can you give that to me in freedom height?" Like saying freedom units. Oh, for like all of our metrics basically. Yeah. My uh my fun fact, nerd fact of the day is uh the foot used to be measured by how long the foot of the king of England was. And so it changed over time and then the US after we you know threw all that tea and threw a fit decided to keep the the king's foot as our measurement. So, for some reason when you started saying that and you started saying like the K sound, I thought you were gonna say a kangaroo's foot and I don't It was a kangaroo's foot actually. The Australians invaded us and with kangaroo's feet. Yeah. I mean, that makes sense. It tracks, right? I don't know why my brain jumped the kangaroo. Like, yeah, we kangaroo. Wish to be back in Australia. Same. That's true. And I have a new camera now. And one of the first things I thought when I got the camera is, man, I wish I was going to Australia again to take pictures of my new camera. Oh, well, it's possible I will be in Australia this year. I don't think I am. I kind of want to break the latter part of the year because I'm non-stop traveling until after September. Wow. Hi, Roxy. Welcome in. Also, for everyone who's here so far, I'd love to know where you're tuning in from. Peruge, I'm in Connecticut and it's uh the opposite of cold. It's like 86 degrees freedom height today. So, we got the AC kicking. I think it's 37 here. So, what? Somewhere 0 to 5 degrees C. Yep. Somewhere in there. I'll let Florian figure out the calculation of 86. I want to say it's like 35 degrees C or something like that. I think so. I think that's right. somewhere around there. Hi. Anyways, it's too hot. Yeah, it's um 60s something I think in San Francisco. So, I'm really excited that I'll be there by the latter part of today. Nice. Yeah, until Carl rolls in later today. Then it'll be freezing again. We have Roxy in Houston. It's probably hot there. I'd be shocked if it's not already humid in Houston. Well, it's it's it's always hot in Houston. Also, it's okay, Florian. I think that's usual. I can't even pin it now. But he said, "Sorry I stopped listening to you, Deon." T typical Florian showing his colors. Yeah, Roxy, it's 37 degrees here because it rained. It's been raining a bunch. It also sporadically hailed the other day pretty bad. Um, but it's been raining and so now we have a cold front and now it's cold and it's like 37 degrees. It's knowing where Hannah and some of our other um marketing people are too because they're kind of more in the mountains. Uh what I have to think of directions now. Northwest out of Denver. Hi Sol S Solomon. Welcome in from Nigeria. Yeah, thank you all for being here. I guess we'll go ahead and kind of jump into it. So Devon and I are here for Laravel Cloud office hours. If you're wondering, hey Leah, you mentioned there's a special guest. Where's Andy? Something came up. So Andy can't actually be here today. Just he's in our hearts. So just pretend he's in the background. Just kidding. It was a valid reason. House repairs are never fun. No. Yeah, that's a house repair thing because of like I guess it's raining a lot there too and there was a leak. So completely understand. Devon and I will have to fill in for Andy today. Um so yeah. Hey everyone. This is Larville Cloud office hours. Let's do a quick intro first. So my name is Leah Thompson. If you've been to any of these live streams, you've probably seen me around and yeah, I'm a deval engineer at Laravel and I'm here today with Devon who does the Laravel cloud office hours with me. So you've probably seen him too. But Deon, do you want to do a quick intro real quick? Yeah, absolutely. Devon Garbalosa. I'm a solutions engineer here at Laraveville. I work at our sales team. Uh I do the technical part of our sales. So I help people who are considering Laraveville cloud and Laravel private cloud uh who may have complex requirements figure out a path forward. Which means that Devon is really good at answering specific questions too. Um because I know when we do cloud office hours a lot of people have questions for migrating their specific apps or if Laravel cloud is good for their specific use cases. And so Devon is the guy to answer those kind of questions. So, uh, this is Laravel Cloud office hours where we're able to kind of rapidfire answer people's questions about Laravel Cloud. We usually go about an hour. We might stop about 5 minutes early today. So, we have what about 50some minutes to answer everyone's questions about Laravel Cloud briefly kind of talk about things you can expect from Laravel Cloud coming soon. And yeah, so that's kind of the focus of the stream today and the topic. Hi Ezra, welcome in. Yeah, the topics Laravel cloud answering people's questions about Laravel Cloud. Um, and let me go through some of these real quick though. Hi Chip, welcome in. Chip was on stream with me last week, a really fun stream about talking about migrating blarbell.com from blade and alpinegs to react and inertia. So if you missed that stream, you should definitely watch it because it was really good and really interesting. It also kind of went into how some people are using AI internally because Chip and I talked a lot about how he used AI for that migration. Hi Flavius or Flavius, welcome in. Hi Zora, welcome in. Yeah, so let's um jump into the slido. Let me share the slido link again. It's also in the description. Oh, we have questions in the slido today already. Seven. Yeah, rapid fire. Let's do it. Rapid fire. I love when I actually post these on like Reddit and we get some questions. Let me uh pin this too. This is the slider link. You can also find it in the description. You should be able to find it on LinkedIn and on um YouTube here. I don't know if it shows in the description on Twitter, but if you go here, you can fill out the side. You can also just drop your question in chat, but let's rapid fire start with um the slido first. So, first one's from Ben. Why has cloud chosen to decouple key code level items to configurable options in the UI over inapp config eg node/php versions Q settings. Well Ben if you are here definitely need more details on this one to answer that. Um I would make a strong argument that node and PHP versions are usually a server side setting um that you would choose. It's not necessarily app level. Um, but having it in the UI makes those extremely easy. Um, there has been talks about doing something like a cloud YAML like uh how uh what's it called? Vapor did that um and potentially expanding into something like that. But that also has its own shortcomings and benefits that you'd have to weigh out. It was path of least resistance. And then Q settings um those are normally done uh also in your Damon config in supervisor unless you're using something like Horizon um which horizon is an is an awesome package that we have for helping manage Q scaling. Um but Horizon runs really well on VPS's uh where it has control over a lot of the infrastructure itself whereas Horizon on cloud has some limitations with vertical scaling um and that those pods are tuned on Laravel cloud to run extremely hot and so you need to set them to basically be exactly what they're they're used for and then essentially they will then run efficiently. But if you try to say, "Hey, I want this pod to scale both vertically and horizontally and you leave that up to the code, then it may uh it may tank the machine." And with a VPS, you just get slow churn. It'll hit swap, it'll hit other things, it'll drag it to its knees. Uh with pods, it kills them and then you get a new pod and the the thing recycles. So, uh, lots of different considerations, but if you have anything more specific, uh, be happy to, uh, dig in a little more on more specific line items. We also got a question. There's more on Slido, so I'm going to mark this when answered real quick. But again, Ben, if you're here, like Devon said, feel free to expand on that. You can also drop in chat um, and say like that was my question and then expand on the specifics and I'll bring that up so we can get into it. Walmart, that one is answered real quick. Um, novice dev said, "When are we going to have Laravel domain like for sale?" Which to that I would say if you have specific features or even if there's specific regions that you're interested in having for Laravel Cloud, the best thing to do is to go into the UI for Laravel Cloud and then open up that little chat box and send a like support message basically or send a message about the feature that you would love to see in cloud. Yeah, absolutely. Uh this is an interesting one. We've considered adding domain purchasing and registration and things in the cloud directly. Um it's a lot of it's a lot of work to manage DNS. Um so this would probably be a strategic partnership that we'd be looking at. Um but it's uh it's definitely something I'd say relatively comfortably is on the road map at some point, but it's just not something we've tackled yet. And sorry, I'm bringing tabs over. There we go. And if you are interested in the feature, you can go to your user. You can hit help and then I guess would send feedback be the best way? Yep. Hit send feedback and then you could type in here any feature requests. Again, if there's specific regions you would love to see on cloud, this is the place to enter those things. It lets our team know what you would want to see, which helps them plan their road maps and stuff like what Devin said. Yeah. and be as descriptive as possible and include what like your business case would be for that feature. It helps us as we're prioritizing it to see um you know having a Laravel domain like Versell is can be a very broad thing of topics but if you're like zoning in on like listen I just want to be able to buy my domain right from there like put put that explicitly in there because it'll help us to know that. Mhm. And then also it helps us for if we did implement it, it be closer to what the user's expecting too instead of us just like guessing. Okay, we have another one from Ben because I'm answering the slid ones first and we will get into chat as well. So Ben said, why does a QC cluster instant use so much more memory than an app cluster background process for a simple Q work process? And then they do they did link a ticket a plane ticket. So maybe we look at that later. Yeah, I'm not gonna bring that up right now on stream. Um but we'll take a look and we'll we'll send that over to the team to take a peek. Um so the cube cluster, there's three kind of clusters out there or four I guess. There's your app cluster which is intended to serve as your web worker. Uh you can also run background processes and schedules on that if you don't want to break that out into its own compute instance which adds cost and overhead. Um then in the worker section you have worker clusters which you could use to run any command you want and those are meant to basically be the same as the app clusters but without any um engine X or PHP fpm well I guess PHP FPM is still on there without engine X serving the web requests essentially and nothing being served from the web directly. So, it' all be command line based instances like Q work or or any longunning processes you might create. Um, Q clusters were supposed to be an intelligent way to scale cues. Um, and they did not work the way that we wanted them to. They were supposed to scale both vertically um, horizontally as well as scale processes on the pods and they caused some memory issues from that perspective. And so we actually deprecated those um and those are being replaced with managed cues which are going GA soon TM soon. Uh which Andy was Andy was going to show us some a little bit of the peak behind the curtain on that. So next time we'll have to tune in check those out. Uh but managed cues, the intention of those is to take away all of that from you. And so it it does the scaling more intelligently um using using replicas um appropriately to do uh better and faster scaling up and scaling down for you. And so that's something that's coming that would be better um as to answer the question directly, why does the Q cluster use more memory than the app cluster? Because the Q cluster is doing a lot more than the app cluster is. it's trying to measure that intelligently and um for 80% of use cases it worked really well for the other 20 it would run into out of memory errors and CPU crashes and so um because we couldn't narrow that gap closer we said let's start over and see if we could do something better and that's what what we are aiming for managed cues to be do you know um and completely fine if you don't too do you know how managed Q managed cues compare for the memory um much better because they don't have um they don't have multiple processes running on a single pod and they don't have anything on the pod monitoring itself um to to try and scale. It has its own monitoring and health checks and all that, right? But it doesn't have anything saying like, "Hey, can I squeeze some more juice out of this orange or not?" built onto the pod. And so it's it's a lower compute requirement. So love that. So yeah, Ben, definitely check out manage cues, which again coming out soon. That's what Andy was going to talk about today, but Devon just gave us some insight into like what you can expect about manage cues as well. I've been pretty deep into early access and helping some customers that were in our beta program for that use them and they're they've been fantastic. So I'm really excited to get those into G and uh see see what the reactions are because they are they are much better. Yeah, me too. shipping so much stuff with clouds. We must ship. We must ship. Um, and then anonymous said, "Will managed cues also be the Q driver?" So, continuing on the managed cues as opposed to having to use the database or sharing the single cache resource for caching and cues. Yes. So, well, kind of. There is a Q driver that you must use to use manage cues. It is ultimately SQS under the hood currently. Um, and I believe we are trying to spike that out into its own like cloud driver that you would use, but that gets provisioned for you when you set up the manage cues and we inject all those variables for you. So, no management of that that you have to do, but it will be tied directly to that because of the affordances we get with some of the SQS APIs and the way that we're scaling with Kubernetes. Uh, it was the best fit for the job for the V1 of Vanishes. Got you. Mark this one. They answered um Lataro added one too. Is the transition from having cues, schedules, storage, and cache on the main app instance to separate instances simple? Does Laravel cloud handle it automatically? So it does not handle it automatically uh because it is an opinion and your app's specific workload that would dictate when and how you do that. Um I'd say it's probably like 60% opinion and 40% your workload uh type. Um most workloads would benefit from separating them but it comes at a cost impact and so you got to measure that for yourself. um cues, schedules, and cache. Cache you probably should not run on the main app. You should run that on the database or you should use a Reddus cluster on smaller apps. Um and then the other the storage on Laravel cloud is ephemeral because they're they're pods and so you shouldn't use the storage on there. You should use object storage for that. Um it roughly equates to about half the available RAM is available as disk space for like temp file uploads and things like that. Um, but it definitely shouldn't be anything that persists across cycles. And the main reason for that is you have, you know, a web request come in, it hits one pod, and then a web request comes in, it might hit a different pod, especially if you have horizontal scaling on. And so that file will not physically be on both pods. It will only be on one. And so you really want to make sure that's contained and does that. Um, and that's kind of the same thing for the cache. If there's any scaling activities on your cache, then your cache would get blown out between different hits. So you definitely want to move that to the database to Reddus um use something external and uh so that you can get the benefits of that but it's it's really easy. You click a couple buttons in the UI, you set it and then you just press deploy. So it does not handle it automatically, but it makes it really easy to implement those. Some would say too easy. I don't think I'd be one of the people love easy. Okay, that's a good So, we answered all the slido questions right now. We'll check this again because it is live. So, if you are to put a question in here, it will populate on the slido. So, I will keep checking it. But right now, we have some questions in chat. So, I'm going to quit screen sharing right now as we do chat. Um, also, hi, welcome in from Argentina. We have Aloy from the UK. Welcome in. We have um Boin from Ghana. Welcome in from Argentina. We have people everywhere. That's so great to see. Hi. I know. That's so exciting. Sometimes like when it's a morning stream, sometimes I'll just like have people from the US. So nice. See all the international people out. Okay. And then M asked why should we choose Laravel cloud instead of other cloud hosting platforms and what are the key differences in performance. It's a really interesting one. So Laravel cloud uh is first party which just put that one out front. Obviously Laravel built it for Laraveville and I could make a pretty strong argument that nobody knows Laravel better than Laravel. So I think that that is uh one thing that you get that uh definitely doesn't translate to other hosting providers. Um the kind of on the performance side of it, it runs on Kubernetes. It has really great scaling affordances. Um and allows you to not have to think about DevOps, which is a lot of times the biggest barrier in someone's path to production of like great I got this app working locally. It does exactly what I want it to do. Now I need to get it out there. And PHP over its 30 plus years has done a really great job of making it as easy and accessible to launch a PHP app into production as possible. But there's still a barrier to entry for for doing that. You need to understand Linux, you need to understand Apache Engine X, um all these different services and things that are not just your code. And so what Laravel Cloud does excellent at is it takes that all away from you. Um, and it gives you the details you need so you could fine-tune when necessary for a lot of that. Um, but a lot of it we're we're doing it the best way possible. So, like some of the some of the things you'll see is we don't um we don't allow you to set any of the PHP FPM workers or things on the pods. This comes up especially with some of our um our enterprise customers of like, oh, we tune we tune this a ton. It's like yeah, you you tuned it a ton because you're on a server. that server is running your supervisor your cues your things and you've got to make all these affordances for all the different things that PHP FPVM is running on Laravel cloud PHP FPVM is only responsible for the pod only for the apps compute itself and so we can actually run those pods extremely hot as in as far as workers go. Um and so we tune those pods based on CPU and RAM to have allocated as much as possible without toppling themselves so that you get the best performance out of the that that. So um those are kind of the key components and then kind of the the fringe benefit is cloud is um as one of our our major commercial products helps support Laravel as the company which then gets reinvested back into the open source. um just last week you could see a ton of stuff that went into open source that indirectly was funded because cloud is helping to get that forward. So um those are kind of the main points of why we would say choose cloud. Um and we say and I would also candidly even if I didn't work here say it is the easiest way to launch a Laravel application right now. Yeah, because we even test other ways to deploy laral applications sometimes just to I don't know see how other people are doing it and what the experiences to also be able to make better educational content too of like are there things we can clarify better are there things um like how do other deployment platforms work for lar applications and a lot of other ones you have to set up kind of configuration files to deploy right you have deploy YAML or something like that it's hard to just hit a button and have your app deployed with other hosting platforms for like cloud hosting platforms for Laravel applications. Um, but also Laravel cloud like Deon says fine-tuned for Laravel and it makes it easy to enable a lot of things like inertia SSR. It's just a click of a a button octane and reverb. It's really easy to set up a reverb re Oh man, I can't speak today. but reverb server using Laravel cloud and like some of the community members found out at the Laravel road show in New York City. We're constantly shipping things for Laravel Cloud. Like we talked about managed cues which are coming soon, but there's a lot of other exciting things that are coming soon for Laravel Cloud. We're constantly iterating on it and shipping new features for cloud. Yep. A big shout out, we support Symphony now as well. So if you have any Symphony applications, you can launch those on cloud. Uh we're looking to expand that to more vanilla PHP in the future, possibly other languages, things like that. Um so the the cornerstone was get Laravel cloud to do Laravel extremely well and then after that you can add everything else. I also love um I just think of this but I love how easy it is to deploy like a real stack app there too like react inertia, Laravel, Telwind. You can just put it as the one repository. You don't have to worry about anything configuration wise either which I think other hosting platforms too you can maybe like maybe even if you could get a Laravel app up pretty simple it's harder to get one up that's like react inertia anything like that you have to mess with configurations a little bit so I love it's just like clicking a button we have a lot of affordances built in that like if we detect that you're using real stack when you put a brand new application up there we'll auto inject what we think your build commands are so you could just be like, "Oh, yeah, actually you're right. I do need to run npm install and npm rundev and just have it automatically whereas other places you got to remember that." And for most people, they probably do, but there's the one-off cases. I've done this hundreds of times in my life where you go and you hit deploy and you're like, "Oh, yeah." And then you fix that and you go, "Oh yeah." And you just like steamroll through errors until you get it. Four hours later, you get it deployed and you're like, "This is so dumb because this would have been easy, but I forgot about this stuff." Um, Solomon asked, "We currently use AWS. Can we use Laravel Cloud on AWS?" So, Laravel Cloud runs on top of AWS. They're currently our hyperscaler. Um, Laravel cloud is a fully managed platform as a service. So, you would run your your uh your workloads on our hardware that runs on AWS. Uh, there is nothing that deploys it directly into like your own AWS account that you would do. Um, with private cloud, however, you do have the ability to, um, we essentially, let me back up. With private cloud, we provision an AWS account and VPC that is owned, maintained, managed by Laravel. You'll never have access to that that we install Laravel cloud into and the control plane and everything. And then we hand that over and you have the ability to VPCP or transit gateway privately connect to other resources and existing AWS accounts. And so if you do have things that don't run on Laravel that you need to put other places, that gives you the ability to do that. Um, and we do have our SOCK 2 type 2, we're working on HIPPA, we almost have ISO 27001, uh, GDPR, CCPA, a bunch of those. So if people want to learn more about private cloud that you just talked about, where is the best place to go for that? The private cloud landing page. Yep. Private cloud landing page. our enterprise page. Uh just at me on Twitter, email me. We can get we can get a call together. Do those things. Let me link both of these as well. Also, if you were to go to the enterprise page as well, um it does also have a is that it or the contact private cloud? It's private cloud. Sorry. If you go to the private cloud page, it does have a contact form which you can fill out to get in contact with Devon and our enterprise team as well or sales team as Come talk to a Yeah, I was going to say talk to a Laraveville expert. You'll probably get me or one of my esteemed colleagues. It used to just be me. So now we have somebody else there. So used to be a guarantee and now it's not. Um, y but the links are larval.comcloudprivate-cloud and larval.comcloudenterprise which I think is a good call out too. Um, because Chip was on last week like I said earlier he was talking about the subdomain collapse and we actually moved cloud over the cloud marketing site over. It used to be cloud.l.com and now it's laravel.comcloud. cloud. So, it's been ported over and I think the enterprise page is also newer and it is very very nice as well. Beautiful. It is beautiful. Yeah, our designers at Laravel are top-notch. Yes, it is. Most days I look at design stuff and I'm like, you might be able to to make me uh get excited about a design. And I literally we we one of our designers released something the other day that we were doing that they were putting on top and I was like how do I get this as a desktop background and five seconds later desktop background. So beautiful Laraveville cloud. Yeah. Yeah. Yeah. That was great. It's like this. I was looking at enterprise page and I was like wait I love like so you see all the different compliance types that we offer. If you hover over them look at these little animations and I noticed it and Tim was like I didn't think anyone would notice it. And I was like, "Oh, yeah. I'm about to hover and click over everything." Hover everything. Yeah. Yep. So, these are samplings of the ones that we have right now. And we're, like I said, we're actively working on um HIPPA so we could sign baso 27001. Our European and uh Asia-Pacific colleagues will appreciate ISO 27001. Mhm. And then we do have customer stories as well which are linked on the enterprise page. Devon's done some webinars. I think we have we should have a webinar coming up soon too that we'll talk about probably next office hour stream as well if you want fun stories. Let me link this one too because this a good one. Hi Graham. L Hi Graham. And then um but if you wanted to see a customer story as well here is one of them. This was Pile's story, but I mainly just wanted to show off the Enterprise page because it's beautiful. Beautiful. It is beautiful. Let's see. I think I missed some questions. Um, but yeah, Goat Designers, Goat Marketing, web team chip. You're included in that. How do we get something over Goat? They're above Goat at this point. Like, how do you get better than greatest of all time? I don't know. I'm just goat. I think HYB. They're HYB. Oh yeah. Hell yeah. Brothers. Um, hell yeah, brother. Amato, um, sorry if I said your name wrong, but said, "How does Laravel handle secure user authentication, login sessions, API tokens, and when do you when should you choose Sanctum versus Passport?" There is an excellent uh, description of the two of them on either the Sanctum or the Passport docs. I believe it's on the Sanctum docs that says exactly why you should choose the two different ones here. Uh there's also Fortify in the mix, not to make it any more confusing, and Socialite and they all serve a different purpose. Um so essentially Fortify handles a lot of your uh password off flows and things like that. Um then socialite handles your social. So if you want to use like Google, Twitch X login, things like that, uh you would reach for socialite for there. Sanctum does your SPA authentication and your API token authentication. So there's kind of two different ways Sanctum splits and those are ones that you could take a look at. And then passport uh if memory serves me correct, passport is ooth 2 and so that's if you are looking to be an identity provider and so people can log into your service then you will send the right tokens and things to other downstream services. So, if you want to have a true OOTH 2 flow for your APIs, um, or if you want to be an identity provider, passports, what you reach for there. Um, I've seen apps with all four. I've seen apps with one. I've seen apps all over the place. So, it really depends on what you're trying to do there. Um, and then by default, Laravel does not handle login or API tokens. That's where you would reach for Fortify or Sanctum, respectively. Sessions are built in. They really don't mean much until you have like an authenticated user. I mean they do but they don't but they do and so sessions are built in and um those are handled uh fairly complexely. Uh I would say I'm not necessarily the expert on how sessions are handled but you have different ways to do that. You could do it with Reddus if you need a distributed storage for that. Um I think you could do it in the database. You could do it on the file system. That's mostly for local dev. Uh and then cookie is by far the fastest and easiest but that will load up with data too fast. And so if you can keep your sessions light, cookie will always be the fastest and most nimble for you. Um, so it's kind of up to you on which way you want to do that. I also link to the docs larvl.com/doccks 13xpassport. It's the passport docs that has a section on passport or sh oh my god or sanctum. I really can't speak today. But passport or sanctum. Let me link to the specific uh index in it. So, here's the link that should take you directly to that section as well. And that's the one that Devon was calling out. It's like right near the top of the docs there, and it details u whether you should use Passport or Sanctum, like what to think about for when you should use either one. Chase had said, "HIPA makes me scream. Just went through another healthcare client. It's always a mess. Couldn't imagine it at this scale." HIPPA. The elusive Hippo from HIPPA. Yeah, it's uh it's fun. It's uh trying to get that one. Uh my favorite thing about going through the different audits to get these uh security certifications is when you go through the uh observation period and then it's like, okay, no news is good news, but no news is also mildly infuriating. So, go those things. But yeah, so yeah, it's uh it's it's all good stuff. Once we have that, that'll be definitely a big help. And then uh I know some of these like ISO 27001 is a full company audit, not just like is your product, it's or all your products and all of your things. And so that's a a very complete certification. And so uh little bit in the sport behind the science here. when you are chasing after all of these certifications, there are there's essentially an order you can go in and you don't have to do like quadruple work because like this one will satisfy most of the requirements for this one and so we're burning those down in the right order to capture all the right ones there. But HIPPA heard heard the community and a lot of people heard we are we are going after HIPPA. Yeah. Then missed some questions from earlier. So, Zea asks, "Are there any plans to launch to launch Melly Search or any other search engine like Forge?" Yes. So, two things to this one. Uh, we brought this up internally a while ago and Taylor had mentioned that uh with some of the additions with PG Vector and what we were doing with AI SDK, the framework actually supports Postgress as a search engine pretty well now. And we actually launched a new docs page for search that kind of details how you can do that uh pretty well. So that is definitely something to check out for kind of low-end search utilities. Um ma search and uh elastic search and uh some of those we're looking on ways of how you could host that in a laravel cloud at some point. um that is an everchanging market because what's good for like LLM based um vectorization search is not what's good for search engine search and whatnot. So trying to weave what's the right call on that one is some of where that's uh kind of getting dragged down right now, but it's definitely something we are considering in the future. Um the other interesting thing we found is a lot of people just like Alolia. It's it's the most expensive. They only do cloud hosted. Uh but there's just something in the water. Alolia does something really well. So uh we see we see a lot of people opting for that. So um but definitely definitely something we are considering is adding um either me search or typense or something for that in the future. we have a question. If I need a Laravel app server, a LM server GPU intensive and several several customer specific SQL servers all currently running on AWS, how would I ar architect that in Laravel cloud? Uh, it's an interesting one. Um, probably need more details to get like into deep specifics, but the only thing there that wouldn't run on Laravel cloud natively would be your your GPU intensive LLM server. So we would recommend that you leave that in AWS. Um and then we can create on private cloud the VPC pier or transit gateway whatever is most agreeable for you uh to connect to that service through the private networking that that AWS would have there for you. Um the Laraveville app server easy that's what cloud is built for that'll go SQL servers are basically a first party unless you mean Microsoft SQL server then the best goes out to you. I I God bless I start I started my career on on Microsoft SQL Server and I'm I'm an expert in TSQL but man do I not like it mostly because they just charge it twice as much as the compute cost just for the license but um if you're using Postgress or my SQL we we support those both natively um on our public not public shared cloud just Laravel cloud you sign up you create an account you go out um we have Postgress serverless Postgress with our partner Neon we have Laravel my SQL uh which is our own Kubernetes operator version of of MySQL that's pretty good and then on private cloud that opens up to RDS and we have some other strategic partnerships uh with some database providers for specific workloads. So definitely something most of that could get handled and then your private cloud with the private networking solves your LLM problem. Again, just a reminder, every time Devon is talking about private cloud, if you'd like to learn more about it, here is the link for it. You're going to be posting a lot if it's every time Devon talks about private Well, I'm just going to pin it intermittently because I feel like we talk about private cloud a lot and so I want people to know where they can go to find out more about it. Yep. But yeah, I mean that's that's the majority of my day is you've got some unique requirements and those get solved oftentimes right now through private cloud as we're growing the product. So yeah, I think you got to show it again. I said private cloud. I'm just kidding. Private cloud. Private cloud. Uh grandma said to what you were saying earlier about the ISO um ISO 2007. He said yes. Done that. It's a big one. Hit his next one. He spelled it correctly in the next one. 27001. Yeah. 27001. I was like, I thought it had more numbers. Okay. And he added the exclamation mark. So, this one, yes, it is. It is a big one. It's a very comprehensive suite. It's actually kind of funny. Um, when you talk to customers all over the world like I do in the US, people could care less about ISO 27001. They're like, don't care. It means nothing to us. But SOCK 2 type 2 is like the gold standard. And then you talk to people in Europe and it's kind of uh I would say it's not 50/50. They mostly want ISO but it's there's some people that are like sock 2 is good enough. Um and then in the AP pack region it's just like ISO or bust. So yeah, it's funny seeing that difference. That's also why I like going to conferences and stuff in different countries because you also get to think like see how people in other countries think about things with their applications in general too. Like I think in Amsterdam at Laracanu we also got a lot of people who like don't use GitHub as much and when like GitLab and all this stuff too and it was very specific and just different than what we would expect and what we see here. So it's just cool seeing that. Um Kevin McKe asked when will you be able to sign a BAA for customers who need HIPPA compliance? Once once we get our HIPPA compliance squared away. Uh, so not a great answer, but TM soon. Um, and then we'll we'll be able to do that. If you have not already talked to somebody on our sales team, Kevin, reach out to us. Uh, you can go to our our enterprise page or our private cloud page, which Leah will link private and uh you can request to talk to a an expert or sales team and somebody will reach out and we can keep you in the know uh for when you're ready. Mhm. And if you go when you're ready for when we're ready at this point. But yes, the private cloud page that's linked, there's a contact form in the hero and you can fill out that form to be connected with the team as well. And then these are kind of more general questions than cloud. Actually, I think we have a slido. So let me jump to the slido real quick and let me screen share so everyone can see the slido. Okay, Laro asked, "Do I need to change how I use the cache storage facade in the code when switching from the app instance to Reddis compatible, KV, S3 compatible, etc." Maybe that is my first answer. Mostly no. Um, for a lot of I mean, the reason the facades exist is so that you do have the ability to kind of switch drivers under the hood. Um there is some stuff where people opt to use the Reddus facade instead of the cache facade and sometimes if you switch like Valky or memcache that doesn't work or if you want to switch between like the database and Reddus that definitely doesn't work. Um but as long as you're using cache and storage facades and doing those appropriately it should work for the most part. uh S3. The only thing I can think of off the top of my head is there's some considerations with large files and serializing them and you could just use uh temporary signed URLs for that and there's a lot of best practices in the docs for how to do that. Um but yeah, it's I would definitely say there's not a lot switching over. Um, especially if your app instance was already using like S3 or something like if you're just moving your app to from like a server over to Laravel Cloud, it's it's kind of just drop in for the compute at that point. Mark this one as answered. Jump back in. I see some general ones. I'll here I'll pin one of these and double check I didn't miss any cloud ones. I don't think I did. So um Ash had asked for full stack teams using React Review on the front end, how do you weigh the benefits of a unified single language TypeScript stack like NestJS versus the rapid DX of using something like Laravel with InertiaJS? I mean you said it. I don't even need to answer that one. The rapid DX of using Laravel with Inertia is exactly why I wouldn't reach for a unified single language. Um, PHP's not hard. It's not old anymore. Um, and but it is old in that it's supported in a lot of places. Um, there was a huge push for a while to unify the stack and that comes into considerations with staffing and things like that. Like if you've got a lot of uh JavaScript talent and no PHP, like maybe you don't want to go that way. Um, but when you have a blended team or you have somebody who's who's solo dev or a small shop, just couple couple devs, five, 10, you just can't beat you just can't beat speed. And that's really what it comes down to. And Laravel has really tried to make it so that the uh developer experience is one delightful, but one that also is accelerative. And so the other thing that's awesome about PHP and Laravel, it's been around for so long. And while there has been many additions and changes to the framework, it fundamentally a lot has not changed. Like the way the eloquence verbs of their different methods and things work has trans I'm turning into Leah right now has transcended. Oh my goodness. Words hard has transcended many versions of Laravel. And so what that means is there's a lot of code out there that these LLMs were trained on that know how to write Laravel code really well. And so when you enter into the AI era and you start going with that, it really makes it really easier than that. And everybody could say JavaScript's been around just as long, but yeah, those frameworks have been around for less long in total and there's a lot of code out there. Um, I personally think the AI stack right now of choice for me is React, Inertia, Laravel, and Tailwind because there is nothing that LLMs haven't crushed with that. And I'm I'm going to get view view hater hate over here, but React is is usually less code and you just have usually less code per component. Um, and then also has just a lot out there. And so there there's just a lot going for those stacks. But you you you wrapped it very eloquently here in your question. The DX and the speed is what matters to a lot of people and if somebody can get close to that, good on them. But right now, Laravel's Laravel's got that corner. Also to expand on what Devon said a little bit. Um Laravel is also very it's opinionated about specific things, right? and it's MVC structured model view controller which also is what allows AI to be so good at writing Laravel and then we also have different tools now such as Laravel wayfinder which makes the type safety easier. So I think before when you were thinking like okay I want the PHP lar backend but then react inertia for the front end but then I have to manage types in two different places. I don't really want to do that but Wayfinder closes that gap. So you don't really have to worry about that as a con for it anymore either. So I just think I personally use uh even if I'm just doing like a front-end app or anything, I personally spin up a real app every time. So react inertia laravel until when and then Chip said too uh cloud doing the Laravel side for you is better than a next monolith. Yep, I would agree with that. And I'll add for my credibility sake, I'm a recovering Python developer. So when I when I say that Laravel is that easy, I've I've handwrote a lot of Python in my life and I I've even said uh that I think in Python when I think for code um and so it's very interesting from that perspective that when I reach for something especially in LLM world and today to build a full stack application, Laravel is my first choice even though it's not my best language. Same. Yeah, because I would I the stack I feel like I spent more time with especially handwriting uh would be the mer stack. MongoDB, Express, React, Node. I'm not I'm not building my full my full JavaScript stacks. Absolutely not. I'm using Laravel on the back end. And I've worked on apps where we had again like a full JavaScript backend or even using um like kind of like a combined Nex.js front end and then like Node.js everything on the back end. And we actually ported it over to Laravel and PHP instead because we ran into certain issues even with like providers and packages and stuff that it just made sense to go to Laravel for. Laravel makes it easy, man. Can I love this question? Go ahead. How would you structure a large Laravel app to avoid becoming a monolith over time? I wouldn't. Monoliths. Monoliths are here. They're here to stay. after we just spent so much time talking about inertia too. I was about to say I love monoliths. I make off my monoliths. So this is actually really near and dear to my heart. I work with a lot of customers uh across many different industries and sectors that are coming to Laraveville cloud and in general and if you go look at my history you can see where I've worked in the past and micros service is is what I've worked on a ton and what we've found a lot of customers and a lot of people in the world are starting to see is that microservices were like this craze of like oh if you just design from here from the ground up you're going to get exactly where you need to go and like this that the other and Netflix does it and Fang does it and like all that and where microervices gets you every single time is try to test something end to end. Try to do a feature test local with microservices where you've got 19 listeners running for each service and whatnot. try to go those things and a leading indicator that you need to break something off into a service I won't even say a micros service but a separate service is that that thing cannot scale when the rest of the app needs to uh I'm sorry that thing is getting so much traffic that it cannot scale and the rest of the app is slowing it down and then the answer is you break that into a service you don't break everything into a service um and at some point You're right. 10 years down the road, your services keep booming, they keep going. You're probably looking at having 10 microservices running with different things and doing that. But at that point, you probably have the DevOps support. You probably have the staff to support it. You probably have the knowhow. And you made the decision because of a need, not because of a want. Um, which is always better to look back on, especially, you know, anybody who's worked on a growing dev team. You get somebody come in and they have shiny and they're like, "Oh, why do we do this?" and you're like, "Oh, well, because the internet told us to." That's never a good reason. But if you're like, "Hey, we went with this approach because XYZ, the monolith worked really well and then we hit this roadblock and we broke this service out because it was the only thing that was spiking and here's the reason why." You can get somebody to buy into that reason to understand as opposed to like you just don't want me to work on cool stuff, right? And so I think that's the big one that gets out there is like yagy is the the term. Shout out Matt Staler for every time I've heard him say that. you ain't gonna need it. And that's the approach that I take with everything that I develop now. Um, which is is a tough one for me. Most of my career has been spent in enterprise tech. So I've had to think, how do I scale this from zero users to 3,000 daily concurrent users? It's all they do to do their job all day from day one. And so as I've as I've come to Laraveville and I've started working with customers all over the arc on where they are and doing my own personal projects, I often find myself overengineering off the bat just because of where I was raised, if you will. Um but it it's usually no no better performant to be honest. It's much easier. Your devs are happier, you're happier, way less stuff to scale and if something breaks and you go to do a fix, you have to do one deployment instead of coordinate 14. Mhm. And even just like the simpler if you're just like having a separate front and back end versus having the monolith and like inertia um to connect your like react front end or any JavaScript front end with your Laravel back end. You're not having to write as much duplicate code. So you're not having to like duplicate your validation logic and all other kinds of logic. So it actually reduces the amount of time that you're spending writing code in my opinion. And it just feels cleaner and easier to maintain like you said. Yeah. And an approach I've actually used in real stack apps before live in production um with lots of users is when I got to a point where I was like doing the roundtrip for inertia is not worth it for this. I've created an API authenticated with sanctum using the CSRF token and make interactivity at the high level right from there. And like technically I'm breaking that out into its own service and maybe duplicating logic. Maybe I create a resource that calls it internally so it's the same throughout and whatnot. Um, but yeah, it's it doesn't lock you in is what's great about it. Just choose what's best for that uh for that moment in time. It's actually funny because I just saw there was this comment from earlier uh from like 7 a.m. I don't know if it was before I don't know if this is like messed up and put the comment somewhere else. It's like monolith for life, which if that was earlier when we just went talking about monoliths, that's really funny. Monolith for life. That's my boy Alex. I used to work with him. He's who introduced me to Laraveville actually. So everybody could shout Alex. Yeah. Yeah. I think he actually just for some reason the Streamyard UI was like Alex said this at 7:13 in the morning. I don't think Alex did. Sorry man. I uh I purposely ignored it. Just kidding. Um David said where can we bring up issues with the official Laravel starter kits? the starter kits uh repository have issues disabled which I did a live stream with Wendle Wendell Adriel from our open source team and we now have something called Laravel Maestro which he talked about in that stream as well and there's a blog post on it so I'll share it but Maestro is what like the orchestrator we're using to update the starter kits now so Maestro is the repository that you would open those issues on or you would open a PR for to add updates to the starter kits and then it would push out the update to the relevant starter kit. So, let me link that one because the starter kits are still open source. It's just you now have to go through the maestro repository for those updates to bring up issues or open PRs. So, here's the repository. is github.comarbalmastro um which is public and you are able to open issues and PRs on that but then also let me find definitely check out the video on that too. Maestro is work of art from Wendell. So yes and let me also link stream and then I think Devon and I are going to start wrapping up so we have hard stops today. Um, if you have questions, the slido should still stay open. So, you can drop the questions in the slido on the Reddit post, any of those, and I will um extract them. So, get them to answer for our next level office hour stream, which will not be next week, but the following one. So, these are every other week on Tuesdays now at noon Eastern time. There's uh there's one more in there that I would like like you to bring up if we have just a moment to answer it from Riley. One second. I will bring that one up. Um here is the blog post. So live.comblog blog, not blog. Meet Maestro. Um that blog post details what Maestro is. And then this is the live stream I did with Wendle where we talked about the starter kits. We talked about Maestro and Wendle also told everyone that we have a API starter kit coming soon because we get asked that a lot. And then you said from Riley. Okay, so Riley said, "Do y'all have any advice on how to stop falling in the trap of restarting projects when you find a better way to do something? There have definitely been times where I get into my own head about it and end up having several versions of the same app." That's a great question. That is a wonderful question. And when you figure out the sauce to this one, Riley, please come back and tell us because both of us I I know for a fact. I follow Leon X and and can definitely find this all the time. We both get stuck in this trap. But the answer is very simple. Just ship. If you just ship, you can get feedback from real users. You can get those things. And when you spend a ton of time on something, it becomes like this thing. And the concept that people use in infrastructure is we're not we're not naming cows, we're raising cattle. And so when you start to give it too much of a name before it actually has a purpose, then you get tied to it and it's hard to figure out how to scale. And so um I think that those two things, you're not you're not naming a cow, you're raising cattle, and just ship. Just put it out there. I would rather a hund times over have a user tell me a feature they wanted than try to fix something that I think a user might someday say and then nobody and then I never get a user. So just ship. I say just ship. And I also say because we have AI now and the AI agents are more advanced than they were even a year ago. If there's something you're thinking like, oh, it might be better if I restarted the project doing things this way. You could always test it with AI to see like how fast AI could spin up something with that and like is it worth it? Like maybe spent an hour or something on that and then kind of see where it's at and then think like is it worth it to keep going down this route with it? Because I feel like I've seen even now more people kind of restart things too because of AI because it makes it so easy to do that. It's less of a time sync doing that. But yeah, if you find the answer of how to stop following the trap, please let us know. I think like what Devin said, I just try to think what's the best use of my time and then just shipping, right? If it's going to stop me from shipping or like really hold me up, maybe not do it unless like weighing the pros and cons, the pros outweigh that. Like the great Taylor once said, we must ship. And we do. That's that's what we focus on. So, yep. I wake up every day. I look at my we must ship painting. I need a painting that's just like we must ship. Same like plaque. I fig like imagine all Larvon employees we just look at that plaque and we're like I'm going to ship. You're making it sound like a cult. It's just a company guys. We're we're cool. I was joking. This is a joke. I promise. But yeah, thank you for the question. That was a great question, Riley. Sorry we don't have like an actual solution either because we're like Devon said, we're both really bad about it. especially for side projects for me because for side projects I want to work on something I enjoy working on so I kind of pivot but we do have to wrap up office hours. Thank you all for being here. Thank you for the great questions. Drop any questions you have in Slido. We will see you um not next Tuesday but the next one. I will be live tomorrow though with Pavllis um for a Road to Laracon stream because he's speaking at Laracon. So please tune in for that tomorrow and I'll have it scheduled so you can see the time and link. But thank you all. Bye bye.