Skip to main content

​
Introduction

Each environment deployed to Laravel Cloud runs on at least one App compute instance, which is assigned a specified amount of CPU processing power and available RAM. Your environment’s App compute instance is responsible for handling incoming HTTP traffic to the environment. In addition, you may add dedicated worker compute instances to your environment to process queued jobs or execute other background processes. Compute resources assigned to an environment may be managed from the environment’s infrastructure canvas dashboard.

​
App cluster

Your environment’s App cluster represents the primary compute and infrastructure that will run your application. This compute cluster can serve web traffic, scale to zero, and manage long-running processes such as queue workers. Laravel and Symfony applications can also run scheduled tasks. To scale or customize your environment’s App cluster, simply click the cluster in your environment’s infrastructure canvas dashboard.

​
Laravel Octane

Laravel Octane is available for Laravel applications only.
Laravel Cloud makes it easy to run your application using Laravel Octane, which boots your application once and keeps it in memory for each request. When editing your App cluster, simply toggle on the “Use Octane as runtime” option. Then, save and deploy your environment and Laravel Cloud will build, configure, and serve your Laravel application using Laravel Octane and FrankenPHP.
Please review the Laravel Octane documentation to learn about the caveats you should keep in mind when building your application to run on Octane.
Before enabling the Laravel Octane runtime, make sure Laravel Octane has been added to your application via the Composer package manager.

​
Inertia SSR

Inertia SSR is available for Laravel applications only.
Laravel Cloud also allows you to serve your Inertia based pages via server-side rendering. Inertia SSR pre-renders your HTML server-side before sending it to the client, which can improve your application’s SEO. When editing your App cluster, simply toggle on the “Use Inertia SSR” option. Then, save and deploy your environment and Laravel Cloud will render your Laravel application’s templates using Inertia’s SSR engine. In addition, if you are using one of Laravel’s official starter kits, you should update your environment’s build commands to use the npm run build:ssr command instead of npm run build:

​
Worker clusters

Worker clusters run background processes on compute that is separate from your App cluster and web traffic. See Workers to learn how to create worker clusters and configure background processes.

​
Autoscaling

Laravel Cloud can automatically scale the compute resources attached to your environment based on demand, CPU usage, and memory usage. To configure your environment’s autoscaling strategy, click on your environment’s App or Worker compute cluster on the infrastructure canvas dashboard, and select the autoscaling strategy that is appropriate for your environment. For maximum flexibility, Laravel Cloud currently supports three different autoscaling strategies:
  • None: run your App / Worker compute on a single instance without autoscaling.
  • Custom: automatically scale your App / Worker compute clusters up and down horizontally within a specified minimum and maximum replica range.
  • Unlimited: automatically scale your App / Worker compute clusters up and down indefinitely based on demand.
After adjusting your environment’s autoscaling strategy, re-deploy the environment in order for the changes to take effect.

​
HTTP traffic autoscaling

For App clusters, Laravel Cloud automatically scales HTTP applications based on real-time traffic pressure in addition to your configured CPU and memory thresholds. Laravel Cloud scales based on whichever limit is reached first. Laravel Cloud’s ingress layer continuously tracks active requests currently being processed by your application and adds replicas when demand exceeds available capacity. For PHP applications, each replica’s capacity is based on the amount of memory allocated to the application. Laravel Cloud estimates that each PHP worker uses approximately 30 MB of memory and can process one request at a time:
For example, a 512 MB PHP application supports approximately 17 concurrent requests per replica. If active HTTP requests rise above that capacity, Laravel Cloud launches additional replicas; when traffic subsides, excess replicas are removed. JavaScript, Go, and Python applications use the same traffic-based scaling signal, but their per-replica capacity depends on the runtime, application configuration, and workload. Because this scaling signal is based on active requests instead of trailing CPU or memory metrics, faster response times reduce the number of replicas needed to serve the same amount of traffic.

​
Scheduled autoscaling

Scheduled autoscaling is available on the Business and Enterprise plans. It allows you to define time-based overrides for clusters that scale between a minimum and maximum number of replicas. This is useful for predictable traffic patterns like product launches, marketing campaigns, or business hours. Each scheduled override temporarily changes your cluster’s:
  • minimum replicas
  • maximum replicas
  • CPU threshold
  • memory threshold
Overrides may be configured as one-time or recurring schedules. Recurring schedules support daily, weekday, weekend, or weekly patterns, and each schedule uses its own timezone so the configured start and end times match the hours that matter to your team. If multiple schedules overlap, Laravel Cloud applies the most specific matching override. One-time schedules take precedence over recurring schedules. Among recurring schedules, schedules for specific days of the week take precedence over weekday or weekend schedules, and weekday or weekend schedules take precedence over daily schedules.
Scheduled autoscaling changes are applied automatically around the configured boundary times, typically within about one minute.

​
Scheduled autoscaling limitations

  • Scheduled autoscaling is only available for clusters that scale between a defined minimum and maximum replica count.
  • Recurring schedules must start and end on the same day. If you need an overnight window, create two schedules.
  • One-time schedules run once, then automatically stop applying after their scheduled window ends.

​
Compute classes

Laravel Cloud applications run on the latest generation of AWS Graviton EC2 servers with an optimized cost to performance ratio, allowing us to pass on best-in-class compute performance and pricing. Laravel Cloud offers two classes of compute:

Flex

Lightweight and cost-efficient. Perfect for dev environments or applications that need the flexibility to support periodic traffic bursts.

Pro

Larger compute sizes designed for sustained, heavy utilization. Best for large-scale, mission-critical production applications.
Within each class, there are multiple sizes of CPU and RAM available. Prices vary by region - see Plans and Pricing for more information.

​
Compute metrics

Your environment’s compute metrics may be viewed by navigating to the Metrics tab of your environment. When graphed, CPU and memory usage for your environment’s App and Worker clusters will be averaged across all replicas.

​
Scale-to-Zero

Your environment can scale to zero when it does not receive an inbound network request to your application (port 8080) within a specified time limit, known as the sleep timeout. While an environment is sleeping, you will not be charged for its compute until it is woken up again. New Flex compute sizes wake in under 500 milliseconds when the environment receives a new inbound request, which is fast enough that your application’s users will not notice. Legacy Flex sizes use the previous wake behavior and typically take 5-20 seconds to wake. You can enable Scale-to-Zero by clicking on your environment’s App cluster on the infrastructure canvas dashboard, enabling the Scale to Zero toggle, saving the compute cluster settings, and re-deploying the environment.

​
Scheduled tasks and queues

For Laravel applications, a sleeping environment wakes automatically to run scheduled tasks and process queued jobs, so nothing falls behind while your environment sleeps. Symfony scheduled tasks should run on an always-awake worker cluster. When your environment wakes for a scheduled task or a manual wake interval, it stays awake for the duration of the sleep timeout. Any inbound request resets this timer. Make sure your scheduled tasks and background processes can complete within that window.
If a queued job is still running when the sleep timeout elapses, the App cluster will stop and the job may be interrupted. We recommend managed queues for queued jobs so that background processing is never interrupted by Scale-to-Zero.

​
Manual wake interval

You may configure a manual wake interval to wake an environment on a fixed schedule, which is useful for background processes like self-managed queue:work processes that must run periodically. As with scheduled tasks, a wake interval shorter than your sleep timeout can keep the environment awake continuously.

​
Worker clusters

Each Worker cluster can either stay awake at all times or follow the App cluster and sleep alongside it. You may configure this behavior within the Worker cluster’s settings.

​
Limitations

  • Only Flex compute sizes can scale to zero.
  • Sub-500 millisecond wake times apply to new Flex sizes only. Legacy Flex sizes keep their previous wake behavior.

​
Maintenance mode

This section applies to Laravel applications. Symfony applications handle maintenance mode differently.
By default, Laravel uses the file driver for maintenance mode. If you run php artisan down from the Commands tab, the maintenance mode state will not persist across deployments or apply to multiple replicas. To ensure a consistent maintenance mode state across your application and its replicas, set the maintenance mode driver to cache and use either a database or Laravel Valkey (Redis-compatible) as the maintenance mode state backend in your environment variables.