Currently, Laravel Cloud supports PHP 8.2 and 8.3 with 8.4 to follow when stable. As such, you may deploy applications running Laravel ≥ v9.
You may select the PHP version required by your application from the environment’s general settings page. After changing the PHP version, a redeployment is required in order for the changes to take effect.
You may define how both the frontend and backend of your application are built during deployment from the “Deployments” section of your environment settings.
PHP Build Commands
The “PHP Build Commands” section allows you to customize the backend build of your application. Typically this will involve choosing how you wish your composer dependencies to be installed or you may wish to run some composer scripts specific to your project.
<aside> ℹ️
Cloud will use the same PHP version configured in the general settings section of your environment when building your application.
</aside>
Node Build Commands
Here, you may configure how you wish the frontend of you application to be built. Typically this will involve installing npm dependencies and using Vite or Mix to build your production frontend assets ready for deployment.
You may also choose the Node version required to build your assets.
Deploy Commands
Before your latest deployment is promoted to production, you may run an additional set of commands. Typically, this is where database migrations are run.
Changes will be reflected the next time your application is deployed.
The environment variables section allows you to make configuration changes to your application. Cloud will automatically inject the configured environment variables into your running application.
<aside> ℹ️
If you have attached any additional resources, such as a database, to your application, Cloud will automatically inject the relevant environment variables into your running application on your behalf.
</aside>
You can manage the compute used to run your environment in two places: “Web” and “Workers.”
Web
Web represents the settings and primary compute that will run your environment’s code. The Web’s “App Instance” is the most versatile compute option for your environment. It can serve web traffic, hibernate, run the Laravel Task Scheduler, and it also manage long-running processes like Queue Workers. Click “Edit” on the App Instance to customize the compute size, number of replicas, Task Scheduler, and Custom Processes.
<aside> ⏳
Larger compute sizes may take longer to provision and deploy
</aside>
Workers
Workers are optional compute resources that can be added to your application. They are a mirror copy of Web’s App Instance - using the same repository, branch, php version, environment variables, deployment commands, database, and other resources. The difference is that each Worker can be independently sized and can run a custom set of Queue Workers or Custom Processes. This can be useful for larger applications where you want to use the primary App Instance to serve web traffic, but offload background workloads to a separate compute resource.
<aside> ℹ️
Workers do not serve web traffic. If your application needs more compute capacity, go to your Environment’s “Web” settings and edit the App Instance to increase the Compute Size or Replica count.
</aside>
You may attach a database to your application from the “Database” section of your environment settings. From here, you may create and attach new database cluster and database or attach an existing database. That’s it! Once set, Cloud will inject the required connection credentials into your environment during the next deployment.
Coming soon…
Coming soon…
Cloud makes it very easy to test your application before attaching a custom domain by providing every new environment with a vanity domain. A vanity domain is created the moment your environment is deployed successfully.
<aside> ℹ️
The vanity domain is made using a combination of your application and environment name. If either of these names are changed, the vanity domain will be updated to reflect update. A redeployment is required for the change to take effect.
</aside>
Coming soon…
Laravel Cloud makes it easy to run your application using Laravel Octane. Simply toggle on the “Use Octane as runtime” option in your Environment Settings. Then Save & Deploy your environment and Laravel Cloud will build, configure and serve your Octane application on a FrankenPHP image.
Prerequisite: Make sure Laravel Octane is installed in your application. https://laravel.com/docs/11.x/octane#installation
<aside> 📖
Octane boots your application once and keeps it in memory for each request. Please review the Laravel Octane docs to learn about some caveats you should keep in mind when building your application.
https://laravel.com/docs/11.x/octane#dependency-injection-and-octane
</aside>
Cloud makes it simple to run a Scheduler on a cron.
Determine where you want to run the Scheduler (Web or Worker).
Open the Instance Details slideout (click “Edit” on an existing instance or click “Add Worker” on the Workers tab)
Toggle on the “Scheduler” option
<aside> ⚠️
If you have scaled your compute to use a Replica count greater than one, make sure you are using the onOneServer method for your scheduled tasks. Otherwise, your tasks will run on every replica, which may lead to unexpected behavior in your application. For more info, please see https://laravel.com/docs/11.x/scheduling#running-tasks-on-one-server
</aside>
Your Web compute is able to hibernate if no requests are received within the specified time limit. Environments that enter a “hibernating” state will not be charged for compute until they are “woken up” again. Hibernating environments will take ~10 seconds to wake up and will be woken up automatically when a new http request is received. Hibernating environments can also be woken up manually from the Cloud dashboard.
To enable hibernation:
<aside> ℹ️
Scheduler, Queue Worker(s), and/or Custom Process(es) enabled on your App instance will all pause during hibernation and will resume automatically when the App instance wakes back up. If this is not the expected behavior of your application, you may move those settings to a separate Worker instance (Worker instances are always on).
</aside>