Laravel Cloud: The Complete Guide to Deploying and Scaling Your Apps

Hey there, my name is Josh. I work on the Laraveville team and I want to show you Laravel cloud. When I first started building Laravel apps, I was always looking for the quick and easiest way to actually deploy that application. Even before I worked on the Laravel team, as someone new to the Laravel ecosystem, it felt like it should be easier to deploy a Laravel application from what I was familiar with. And Taylor and team thought the same thing. In fact, at the announcement of Laraveo Cloud and Laracon 2024, which you can find right up here, Taylor said on stage that the goal, the whole reason Laravel cloud exists is because there was this nagging in the back of his mind. What if we could deploy and ship a Laravel application in less than 60 seconds? And that's why Laravel cloud exists to give you and your team the ability to ship and scale your Laravel and Symfony applications fully managed by the same team who continues to build Laravel. And so this video is meant to be a full walkth through, not just a short snippet on what Laravel Cloud is. We're not going to talk too much about the marketing side of things. I really just want to show you everything that Laravel Cloud has to offer and some tips and tricks as you're setting up your application on Laravel Cloud. So you'll find every chapter that you might need on the bottom. And if you want to skip ahead to a specific section that fits best for where you're at right now, go ahead and do that. So, you have your account or you signed up with GitHub or Google and you're in the dashboard. Now, we can get started by connecting your preferred Git provider. And while my screen doesn't show it because I've already done it, you can start with GitHub, Bitbucket, or GitLab. After you've connected your Git provider, you can select any repo that your Git provider owns or at least has access to. Or if you're just wanting to try Laravel cloud out and see what it has to offer. You can always start with a template as well which includes any of the starter kits that Laravel currently has. I know this one repository that I've been working on and I can start deploying it and that's called wire. So I can search for it and select it right here. This is where I can select the region that I want this to be deployed to. And typically this is best to select one that's closest to you or your users. Since it looks like I already have an application with this name, I'm just going to call this wired two. So we've done essentially everything that Laravel cloud really cares about in the sense of getting your application up and running. Where does it live? What git provider is it connected to and what git repo is it? Next, we can deploy our application. This is where you're going to spend most of your time when it comes to setting up and configuring everything that your application might need in order to deploy. First off, you might notice that I have selected the main branch. That was the default option because I don't have any other branch associated with this particular git repo. If I did, I could create a new environment or even select a different branch. I could deploy automatically, but I know that this application is probably going to fail because I need at least a database. But even this particular application does need websockets as well. Specifically, Larvo Reverb is what I was using locally and it would be nice to get it up and running for this application. We can configure our application cluster which we'll get into some of those settings in a little bit or we can add specific resources that would be available or necessary for our application to run. In this case, I'm going to add a database. I'm going to create a new database cluster which gives me the options of using Laravel MySQL, Laravel serverless Postgres 18 or Laravel serverless Postgres 17. At the time of this recording, I'm going to stick with Laravel MySQL. I can select a different region, but it's best if it's in the region that's in your app cluster. And then I'm going to set it to the lowest configuration, this dev setting. Creating the database cluster. Now that that database cluster has been created, I'm going to go ahead and save this. I'm not going to deploy it just yet because I know that I need a websocket connection. I'm going to use an existing websocket cluster that I've already created. But we can create a new one down here. If we wanted to set the specific concurrent connections and consequently the price that we would have for this cluster as a whole. I'm selecting an existing one because we can share resources in Larvo cloud. You don't have to create a new database for every single application that you have. You could share resources. Lastly, I know this application needs cues. So I could configure this in my app cluster to run a Q instance or after saving I could select a managed Q cluster. The default settings are perfect for me. Now this should be everything I need to actually have that first deployment not fail and succeed. But that's not entirely true because I've built this application and I know that there are some specific settings that I need. So we can actually jump right into how would you configure build step selecting deploy. If I was to do that right now because I know my application it would fail because I have not set up the specific build settings that I prefer for my application including a private composer package that I need credentials for. So jumping ahead a little bit before we actually see that first deploy kick off we can go into our settings. Now this is the settings for this application specifically for this environment. the main environment. This is where we can change that git branch if we ever had additional branches to change it to set the PHP version, node version, any custom environment variables, or see what's already been injected. In this case, what is set up with that connection to the database and the websocket connection. But in my case, what I want is the deployments tab right here. push to deploy is already enabled for every single application that we create, but I want to change these build commands. Now, it's already recognized that I'm using bun, or at least I prefer bun, but I still need that private composer package. So, I'm going to paste that in. I'm going to hit save, and then I'm going to deploy. And immediately, we see that deployment start to kick off. Here's where we can see and kind of review what's happening on each specific step during this deployment phase. And just over a minute and a half, that deployment has finished and I can go ahead and visit this application, which is my real time application where I am voting on a would you rather question and other people can join this page as they see fit and can vote in real time, too. Okay, that's great. We have this set up. But then how do I change where people actually access this URL? Well, you're given a larville.cloud domain right out of the box. But we can change that. We can configure it. Going into settings into network. I can change this Laravel cloud domain to be hi there YouTube. Laravel cloud if I wanted. And I could save and deploy that and then have hi there YouTube. cloud be the final version of this application for you. We're not going to dive too deep into the weeds on this just yet, but I do want to show off that Laravel cloud does have a separate API as well as a CLI, the cloud CLI. You can install it globally using this composer global require laravel/cloud CLI command which includes shell completions for what is actually possible with the cloud CLI. So if I want to deploy that same application instead of it doing it from the dashboard, which I wanted to show you because that's the bread and butter of Laravel cloud anyways, the cloud CLI comes in handy, especially when you're thinking of CI and agents down the line. You can see in this deployments as I'm selecting which application, this is the wire 2 one, it's going to start deploying to that and we see it pop up right there. And don't worry, we'll come back to the cloud CLI later to go into it in a little bit more detail. So, we've gotten a brief overview of the environment page and a quick look at the settings page, but what's everything in between? We took a look at deployments. We can see the deployments in detail, but we can also use this an individual deployment to redeploy. If for some reason you do have a deployment that fails, you'll see why. In this case, I did not have the proper package in order to use managed cues. Since I do have managed cues set up for this application, managed cues allow you to see the cues at a distance, what's happening right then in the moment or at least the last day and if there's anything that has failed. Of course, I have the ability to also uh change the settings of this particular managed Q cluster or pause or purge jobs. Within the commands page, I can run artisan commands that are either relevant to Laravel itself or relevant to my application. For example, this is not the best way I would want to do it, but I could run phpartisan down to put the application into uh maintenance mode. Going back to an environment, clicking on our new hi there YouTube.lar.cloud domain and it's unavailable because it is in maintenance mode. I didn't have to redeploy. It was using the artisan command that Laravel has available. There's one that I have for my particular application as well. PHP artisan question fetch which should fetch a new would you rather question. Yeah. Would you rather stop using YouTube or stop using Google? Let me put my application out of maintenance mode. PHP artisan up. Logs are where you would expect to find everything that is happening within your application or even your specific access logs as well. In this case, what's happening? what has been requested from your site. Of course, similar to the Q information, this can be configurable, whether that's in the last 5 minutes, last hour, last 6 hours, day, 7 days, and so on. This is helpful to be able to just dive in real quick to something that might be happening within your application. Or if you are debugging and sending specific logs, you can always copy that log message, the context, or all the above. Metrics. There's not too much to show here. So, let me go to an application that actually gets a lot of traffic. And then the last 24 hours, I don't have any 500 errors specifically for this application, but quite a bit of 4xx. So, I should probably dive into that a little bit more. In settings, while we glossed over it, you can change which PHP version as well as which node version is useful for your application. This is where we can also have application specific settings as what this application name is. Maybe we want to add a custom avatar that we can identify it right up here. Say I want to talk about the difference between an application and an environment. For example, we have our wired 2 application which clicking into it, we just go to the default environment, the main environment. If I want to configure a new environment for this application, selecting new environment means I can select a specific branch to connect to this environment. In this case, I only have main, but maybe I wanted this to be the dev environment. And of course, I probably should have a dev branch along with that, but just for the sake of being able to show you what's actually happening, I'm going to create a new environment. Now, this environment can have different resources. It can have a different database. It can have a different cache bucket or websockets. Or going back to our settings, we can use preview environments. Preview environments allow you to have automation so that when a new PR is pulled up or when a new branch is created, you can have a new environment, a new uh version of your application spun up so that you can use it or share it how you like. In this case, maybe this automation is new PR. I want to replicate the main environment. So anytime there is a new PR on the target branch of main or maybe just any new branches itself, maybe any new branches that start with the feature flag. I'm just going to say any new pull requests. And then I can configure what actually happens when this environment is created. Replicate and downsize is the default, but we could say that there's hey a new cluster that's created or just the identical settings. sharing resources, of course, creating the new database within that specific cluster that we already have connected to our main environment or we can even use the same database if it's something that maybe doesn't have uh confidential information. In this case, I would probably want to create a new database but have the same websocket. Now that I have configured the settings the way I want, I can create that automation. So now anytime there is a new PR that is pulled and requested against the main branch, I'm going to have a new environment automatically created. And when that PR is deleted, the environment gets deleted. Preview environments are actually something that the Laravel team makes heavy use of as well. It's great to be able to have a PR and a preview environment already set up with that PR and even a comment that Laravel cloud leaves in that PR with that preview environment link. It's great to just have that available and ready to go. All right, next up, let's talk about databases. In this case, what are some of the additional settings that we might be able to have as well as how can we connect them outside of Laravel Cloud. I'm going to delete this particular environment just cuz I don't need this dev environment anymore. So, we have a database already selected, that MySQL database that we initially configured. Now, at any time, we can change the settings for this particular database. Maybe we want to edit this database in order to scale it up. So this is the current server size, but I could scale this up even more. Or I could enable a public endpoint which enables us to access this database outside of Larvo cloud, maybe in something like table plus. Now I have this deep link that I can immediately open in a database client like table plus. There's that main database and we have those votes, those two votes that I created. We can create a new database in this database cluster, this database resource if we wanted to. Or of course, you can do that from the application screen if you're creating a new environment or a new application entirely, but just want to share resources. Of course, as always, we can see metrics for this particular database, too. And last but not least, the backups. Now, Laravel MySQL databases configure backups automatically. Automatic backups occur during a daily 3-hour backup window, which is scheduled between 3:00 a.m. and 6:00 a.m. EDT, or you can create a new manual backup as well. I want to change that backup attention to, I don't know, 5 days. I can do just that. So, we've connected a websocket server, but we haven't actually looked into what's actually happening with that and what other resources that you might have available. So, websockets is the Laravel Reaver, which is a managed websocket connection cluster that is given to you. And of course, you can share this just like any other resource within Laro Cloud. I'm using it in two environments right now. Just like the database, I can configure these settings even while it's connected without having to restart this cluster or redeploy my application. For example, if I want to change these settings so that this cluster is not just a 100 concurrent connections, but maybe I know that I'm going to be sharing this demo and I want to scale this up to let's say 5,000 connections. I can go ahead and hit save and it's just done for me. The only thing we can't change is the region after we already create that cluster. But we also can create a cache or add a cache resource to our environment. And of course, all of these resources can be created separately outside of an environment, outside of an application. If you just wanted to create a Laravel websocket cluster and just have it existing outside of a Laravel application, you could do that. I'm going to create a new cache. This cache is powered by Laravel Valky. Oh, we haven't talked about this too much and we will in just a little bit. Laravel Valkyrie is one of those resources that can also be scaled to zero as well as a bucket. A bucket is Laravel object storage which is S3 compatible R2 buckets. By default, all buckets are private, but you can allow them to be public as well. Just like other resources, these can be shared across environments across applications. One thing to note is if you add a bucket to your Laravel cloud instance, you have to install the fly system AWS S3 package and Laravel cloud will actually bug you about this if you deploy without this package installed. pulling up a new application. I want to go into some of the settings specifically for app clusters. I will go into the scale to zero and autoscaling in a little bit. I want to talk about these two pieces here. The scheduler or any background processes. Now, we already talked about how we have this manage Q aspect to be able to say, okay, your Q now is managed. It can scale up. It can scale down depending on specific workers and it can scale to zero when there's nothing in the queue. But the app cluster, if you didn't want to have that separate managed queue, you could just do it all within the singular app cluster. For example, I could add a new background process. I could say this is a Q worker or even a custom worker, something that runs and is a longunning process, any configurable number of processes. So I could have a separate queue from my managed cues to do maybe menial tasks that the Q worker doesn't necessarily need to be bogged down with. And then if you have scheduled tasks within your layer application, it's just as simple as turning on theuler, hitting save, and deploy. Okay. Well, that preview domain is great. If I'm just sharing it with friends, if you are there on the internet watching this and you want to go to hide there.cloud, it's a good domain, right? But in the real world, you have real domains or you should. And so how do we add one to your application or really to your environment because that's where the domain is associated with the particular environment that you have. In this case, clicking on this domains allows me to go to that network setting for this environment. I can configure any of those edge network settings, and we'll get into that in a little bit. But we could also configure a custom domain. It's as simple as adding it here. In this case, maybe I had the domain, which I don't, of cool laraveldemo.com. Adding it would then give me specific settings. And after choosing these particular settings for this particular domain, in this case, uh maybe I don't want to support the subdomain. I want to redirect and keep these all recommended for downtime and I'm not using Cloudflare. Now I have the IP settings I need to enable or set up within my DNS. And if you do have the cool Larville demo.com domain, go ahead and configure this for me. We'll be good to go. In this case, here's a demo application that I set up a year or so ago at roundis.jhseri.com. And that's already been configured and ready to go. And it just redirects to my Laravel cloud instance. Roundis.jseri.com. The neat part is once you connect a custom domain and even if you don't and you're just using the laravel.cloud free domain SSL and HTTPS are automatically configured for you. You don't have to do anything else. I just set up that custom domain, pointed my DNS to the IP addresses that Laravel Cloud gave me, and it's good to go. I don't touch anything else. Next up is something that no one really wants to talk about, but you probably are asking the question, well, how much am I spending? How much can I configure to know what if I'm spending is accurate? And can I stop it from spending more if I don't want it to? So, first off, let's go into our usage setting. This is where we can get a good bird's eye view of how much everything is costing us. Specifically going back to some of our app cluster settings that compute as we are selecting particular settings within our app cluster is going to be a set fixed rate. Everything that you see below me right here is what you would pay if you have that specific app cluster selected. So if I have this one, it's capped at $24 a month. I know that I'm not going to be spending any more than that, but I can be spending less. And again, we'll get to that in just a little bit, I promise. But this is helpful when you looking at our usage overall because we know that there are things that are fixed rates that we know we'll never spend any more than a certain amount. We could spend less depending on if we are scaling it down to zero if we having that sleep. But this usage page gives us an upto-date view on how much everything that we have configured within Laravel Cloud is costing us from our applications to our specific resources. In this case, maybe that's a database, cash, websockets. But so, how can we set up alerts and stop this from going over what we would prefer to spend even if you do know that fixed limit for applications, for resources, for your environment? In settings, in billing, I can go down to this spending limit right here. I can see what I'm currently spending and when it resets. But I can also update this limit that I've already set. I have this $300 limit that is just an alert right now for my particular account right here. So I'm going to get notified because I'm an admin when the spend approaches and reaches that limit. I could change that to $50 or whatever I prefer to set. Or I can stop compute when it reaches that limit. In this case, if I say a $300 limit once I hit that $300, I will not spend a cent more and every compute just gets shut off. Now, this might be something that you prefer to do. It might be something that you might not prefer to do, and that's okay. But it's helpful to know that it's there. But going back to our app cluster settings, this is why autoscaling matters because one, we can scale to zero and have less spend than even that uh up to $48 a month number there. But we could scale this up and say, okay, maybe there's times when I need more compute for this particular application. There's times I'm not going to be spending $168 a month, but I could spend that much. And so we have this balance of okay yes you can have this autoscaling limit for your app compute even for your managed cues where they can scale up depending on what you prefer to set and when those thresholds meet. For example, if the CPU threshold is above 60%. And the memory threshold is above 60% I'm going to scale it up to the next replica. Of course, I could just turn this off and just know that I'm going to be spending up to the limit of the particular app cluster setting that I've already set. In this case, the $24 a month. It's capped at that. Okay, you're not spending any more. Again, you could spend less. Hopefully, that makes sense with the pricing and with usage and limits. The the goal is to make this as transparent as possible so that you know exactly how much you're spending or how much you could spend but then also have some wiggle room in there where you could spend less. And that leads me to not just the autoscaling aspect that we already talked about but scale to zero. It's configurable on app clusters and then trickles down to your managed queue as well as the databases and even laravel valky scale to zero just means that when your application is not in use it sleeps the app cluster the manage the databases your cache so not only do you have the option of autoscaling to say okay when it's not sleeping I want it to go all the way up to 10 replicas but when it is sleeping. I wanted to sleep after maybe you know 19 minutes, 5 minutes, 60 minutes of time without HTTP requests. Once this limit has been hit, let's say 5 minutes, then my application is going to sleep. And again, my application and any resources that can sleep that can scale to zero will sleep with it. Managed cues, databases or laral valky which is cache. The good news is cold starts are not really a thing with Laravel cloud. And if you're familiar with that term, it just means that typically within serverful or even serverless environments, you have this aspect of okay, yes, it's hibernating, but when I need it, it's going to take a little bit longer to spin up. That's not the case with Laravel Cloud. Laravel cloud spins up in less than 500 milliseconds and up to sometimes 500 milliseconds, but usually less. And those are all the resources attached to your specific environment. That's the database. That's the app cluster. That's the manage cues. So that means if I have no requests within 5 minutes, it scales down to zero. It sleeps. And then when I need it or someone accesses my website, well then I just get it up and running within 500 milliseconds. So the time that it's not awake, I'm not paying for it. I'm not paying those cents while it's sleeping. And so that up to $6 a month is true. It could be $6 a month. It could be much less. And this is where that edge network comes in as well because the goal is to get your application to sleep for as long as possible. And so bots shouldn't wake it up. It should stay in sleep. It should stay scaled to zero as long as you don't have users who are trying to access it. And so we do have firewall specific settings that you can configure as needed. We do have response rules that you can configure as needed, but the defaults out of the box should be great for you. We have tightened up on that. we have had it be as good as it possibly can be for you and for your users. And then lastly, specific cache settings. And so this is if you have more additional cache settings that you might need outside of the ones that we automatically set up on the edge for you. And so this is specifically if you want to bypass the caching for this particular environment, the edge caching, the CDN that we set up for you. So you might start to see that there are specific instances within your application, within your needs that maybe just a fixed cluster might be best for you. Maybe there's a specific always on cluster that's just going to be better than if you had a scale to zero cluster. Maybe you just need to spend as little as possible and so the cheapest compute cluster with scale to zero at a small rate is going to be best for you and for your application. Maybe your application needs scaling to zero because you want to be as budget conscious as possible, but you also have weekends or maybe uh specific days of the month that are just automatically more traffic and you don't want to spend time having to come into Laravel cloud and reconfigure or set this up on a schedule using CI which you definitely can do with your agents even to set up to scale Laravel cloud with the cloud CLI But maybe you just turn on autoscaling with scale to zero and say, "I'm just going to spin this up and have this be as big as possible while also scaling to zero when I don't need it." The goal is to be configurable for you, for your purposes, for your application, for the needs that you have. So that can be that fixed size, it can be always on or it can be scaled to zero or it can be autoscaled. It really is depending on what you need. Going back to our cloud CLI, there's so much that is available out of the box that you can use, not just from an API standpoint, but from a CLI standpoint to maybe configure your agents to use or even in CI. Maybe you don't want a preview environment up anymore if someone comments something in the PR, I don't know, but you can do that within the Laraveo cloud CLI to say, okay, let's delete that environment. It's as simple as cloud environment delete. The thing I want you to take away is that the cloud CLI along with the API is so incredibly powerful that you can really do anything that you can do in the dashboard. Anything that I've showed you up until this point, even being able to spin up cloud Tinker and being able to run Tinker commands within an application. I don't want to sound like I'm just pawning this off for you to read the docs, but it is helpful because I don't know what you want to do within your automations, within your agents, within your CI, but it's probably possible. And the good news, if you just spin up cloud skills install, it will automatically install skills specifically for the cloud CLI so that you can have your agents know what's actually available within this preconfined settings of the cloud CLI. Lastly, I want to go over some access settings. So, not only can you invite individual users to your team, to your organization, but you can have specific settings for them, whether they're a developer, and they can access development features, but they can't access things like billing features or if you want to give them full access to everything. This is where you can have application and environment specific level access. And just to touch on it, there is Slack integration in order to add notifications to a particular channel in a Slack workspace, which enables you to select what channel these notifications should go to. and then what actually gets sent to that channel. In this case, what particular things about your application or about your organization and resources should be sent to Slack. And then in each application in their notification settings, this is where you can configure on an application basis if it should be sent to those Slack notifications or not. There's so much the Laravel cloud offers. the ability to connect everything that you might need to have a full stack application deployed, ship, scale fast. And of course, yes, you can configure every single thing. How much you want to spend, how much you are spending, what's actually the scaling aspect of each specific app cluster and each specific resource as well. But if there's one thing you take away, it's that everything should be specific to you, specific to your team, specific to your application. Nothing's going to be the same across every single application. And that's what makes Laravel Cloud so unique. So yeah, if I can put on my marketing hat just for a little bit as I wrap this up, that's what it's like to deploy on Laravel Cloud. That's everything or at least almost every single feature that I can talk about. And I know this video got a little bit long, so hopefully you beared with me throughout it. But you connect your code, you deploy your app, you connect your database, you attach the resources you need, you can put on a real domain, you can control what you spend, you can scale it when it needs to scale, you can scale it down when it needs to be scaled down. You can make it sleep. You can preview changes before they merge. You can preview changes when they merge. You can set up new environments when new PRs are pulled up. And you can do all that in the dashboard by clicking around like a human being. Or you could have your agent do it all for you. But hopefully that gives you a little bit of an insight to how much care the Laravel team has put into building and maintaining and bettering Laravel cloud so that you can ship and scale your applications. So hopefully you go and do just that. Again, if you missed anything, you can click on the bottom for chapters on what specific feature you might be looking to get more in-depth knowledge on. Hopefully you have a fantastic day and just ship.