Managed Queues

Introduction

Background jobs allow your application to defer slow or expensive work, such as sending email, generating PDFs, calling external APIs, or processing media, so that it can respond to web requests quickly. Managed queues are available for Laravel and Symfony applications. To run custom background processes on any supported runtime, see Workers. Managed queues isolate background jobs from your web traffic and run them on dedicated workers that scale with the work waiting to be processed. Flex workers scale to zero when idle, so you pay for compute only while jobs run. The Queues dashboard provides metrics, failed-job visibility, and retry controls without requiring you to manage queue infrastructure.

Managed queues vs. workers

Managed queues are the preferred choice for all new and existing Laravel and Symfony applications. Laravel Cloud provisions and operates the queue infrastructure, scales workers based on queue depth and job duration, and provides failed-job management in the dashboard. This keeps job processing isolated from web traffic and removes the need to manage queue workers or drivers yourself. Use Workers when your application needs a custom long-running process or must continue using a self-managed queue driver, such as Redis or a database queue. Workers are available for every supported runtime, but you configure the command, process count, autoscaling, and operational behavior yourself.

Managed queues give your application dedicated workers that scale based on the work waiting to be processed. Each queue has its own worker pool, memory allocation, and autoscaling range. Flex workers scale to zero when idle, while Pro workers remain available for long-running jobs and steady throughput.

Each managed queue is provisioned in its environment’s region. The number of queues available is based on your plan and applies to each environment:

Plan	Managed queues per environment
Starter	1
Growth	10
Business	Unlimited
Enterprise	Unlimited

A single queue is sufficient for most applications. Create separate queues when workloads need different memory allocations or autoscaling ranges.

Configure managed queues

Creating a managed queue

Open your environment, click Add compute on the canvas toolbar, then Managed queue. Provide a queue name, choose its queue type, memory allocation, and worker autoscaling range, then deploy the environment. Once deployed, Laravel Cloud creates the queue, configures access from your application, and starts its worker pool. Queue names may contain letters, numbers, hyphens, and underscores, and must be 39 characters or fewer, including the .fifo suffix for FIFO queues. Each managed queue handles one queue name. The first queue you create becomes the environment’s default queue. You can select Set as default from a queue’s canvas menu to change it.

Queue types

Each managed queue is either a standard queue or a FIFO queue. You choose the type when creating the queue and cannot change it afterward. Standard queues provide at-least-once delivery with best-effort ordering and support per-job delays of up to 15 minutes. They are the right choice for most workloads. FIFO queues deliver jobs in dispatch order and deduplicate jobs on arrival. They suit order-sensitive workloads such as payment processing and ledger updates. FIFO queues do not support per-job delays and have a small operations premium. Laravel Cloud appends .fifo to every FIFO queue name. For example, a queue named orders becomes orders.fifo. A standard orders queue and a FIFO orders.fifo queue may exist in the same environment.

Compute classes

Every managed queue runs on either the Flex or Pro compute class:

Flex

Scales to zero when idle and wakes in under a second. The default class for spiky or idle-heavy workloads.

Pro

Always on, with larger sizes and no fixed job runtime limit. Best for steady throughput and long-running jobs.

	Flex	Pro
Scaling floor	Scales to zero	Always on, with at least one worker
Memory sizes	256 MiB to 2 GiB	256 MiB to 8 GiB
vCPU	Up to 1	Up to 4
Job runtime	Up to 90 seconds	No fixed limit
Price	Starts at $0.00000152 per second	Starts at $0.00000183 per second

Pro sizes are priced at a 20% premium over the equivalent Flex size. Flex is the default and works well for spiky or idle-heavy workloads. Pro is appropriate for jobs longer than 90 seconds, steady throughput, or jobs that need more than 2 GiB of memory. Pro is available on the Growth and Business plans. Enterprise customers on Private Cloud can use dedicated Pro sizes up to 16 GiB.

Memory allocation

Each managed queue worker runs on an instance with configurable memory, and CPU scales proportionally with the selected size. Flex queues offer sizes from 256 MiB to 2 GiB. Pro queues offer sizes from 256 MiB to 8 GiB, with more vCPU on the largest sizes. The default, 256 MiB, is sufficient for typical jobs such as sending email, processing webhooks, updating records, and light data transformation.

Plan	Flex	Pro
Starter	256 MiB to 2 GiB	Not available
Growth	256 MiB to 2 GiB	256 MiB to 8 GiB
Business	256 MiB to 2 GiB	256 MiB to 8 GiB
Enterprise	256 MiB to 2 GiB	256 MiB to 16 GiB

Give workloads with different resource needs their own queue. If a job exceeds its worker’s memory allocation, the worker restarts and Laravel Cloud redelivers the job. The failure usually appears as a PHP fatal error reporting that the allowed memory size was exhausted. Check the Memory chart on the Queues dashboard when workers repeatedly restart. See the queue worker memory sizing guide for guidance on selecting a size.

Managed queue sizes are independent of App and worker cluster sizes. Queues created before Flex and Pro remain on their existing size and pricing until you upgrade them.

Worker autoscaling

Each queue scales between a configured minimum and maximum number of workers. Flex queues may use a minimum of zero, while Pro queues keep at least one worker available. Choose a maximum that your database, APIs, and other downstream systems can handle in parallel.

Plan	Maximum workers per queue
Starter	3
Growth	100
Business	Unlimited
Enterprise	Unlimited

Laravel Cloud measures queue depth and job duration to add and remove workers. It gradually scales Flex workers to zero when the queue drains. Start with a conservative maximum and raise it after confirming your database and downstream APIs can absorb more parallel work. Scheduled autoscaling. Managed queues also support scheduled autoscaling, which temporarily changes the minimum and maximum worker count on a one-time or recurring schedule. Scheduled overrides follow the same rules as scheduled autoscaling for compute clusters. Advanced settings. Organizations with the advanced managed queues entitlement can override visibility and graceful shutdown timeouts from a queue’s Advanced tab. Most applications should use Laravel Cloud’s defaults.

Connect your application

Laravel
Symfony

Requirements

Managed queues require Laravel 11.55.0, 12.63.0, 13.19.0, or newer and the aws/aws-sdk-php package in your composer.json:

composer update laravel/framework
composer require aws/aws-sdk-php

Queue connection

When you deploy a managed queue, Laravel Cloud sets QUEUE_CONNECTION=cloud for the environment. Jobs dispatched without an explicit connection use the managed queue.

Any job dispatched without an explicit connection, including jobs previously processed with the database, redis, or another driver, routes to a managed queue once one exists in the environment.

To continue using another driver for some jobs, set QUEUE_CONNECTION to that driver and dispatch managed-queue jobs explicitly with ->onConnection('cloud'). Laravel applications that use the default database driver are the most likely to be affected.

Setting a default queue

The default managed queue receives jobs dispatched without an explicit queue name. For example, dispatch(new SendEmail) uses the default queue rather than a queue literally named default. You may rename the default queue without changing these dispatch calls.

Requirements

Symfony applications use the laravel/symfony-on-cloud package, which provides a cloud Messenger transport:

composer require laravel/symfony-on-cloud

return [
    // ...
    Laravel\Cloud\Symfony\LaravelCloudBundle::class => ['all' => true],
];

The package does not ship a Symfony Flex recipe, so register the bundle manually.

Routing messages

The package provides a cloud Messenger transport with no DSN configuration required. Route messages to it in config/packages/messenger.yaml:

framework:
    messenger:
        routing:
            '*': cloud

If your application uses the conventional async transport, Laravel Cloud injects MESSENGER_TRANSPORT_DSN=laravel-cloud://managed-queue so it works without changes.

Multiple queues, FIFO, and retries

Use CloudQueueStamp to dispatch a Symfony message to a named queue. Without a stamp, messages use the environment’s default queue:

use Laravel\Cloud\Symfony\Queue\Messenger\CloudQueueStamp;
use Symfony\Component\Messenger\MessageBusInterface;

$bus->dispatch(new ProcessReport($report), [new CloudQueueStamp('critical')]);

Use CloudFifoStamp with a .fifo queue when you need to set its ordering or deduplication key:

use Laravel\Cloud\Symfony\Queue\Messenger\CloudFifoStamp;
use Laravel\Cloud\Symfony\Queue\Messenger\CloudQueueStamp;

$bus->dispatch(new ProcessOrder($order), [
    new CloudQueueStamp('orders.fifo'),
    new CloudFifoStamp(
        messageGroupId: 'customer-'.$order->customerId,
        messageDeduplicationId: 'order-'.$order->id,
    ),
]);

On a standard queue, CloudMessageGroupStamp enables SQS fair queues, so one noisy tenant does not starve the others. Unlike FIFO, the group ID does not impose ordering or deduplication.

Delays and retries

A DelayStamp on a standard queue maps to an SQS per-message delivery delay, capped at 15 minutes. Requesting a longer delay throws. FIFO queues do not support per-message delays.Symfony Messenger controls retries for the cloud transport:

framework:
    messenger:
        transports:
            cloud:
                retry_strategy:
                    max_retries: 3
                    delay: 1000
                    multiplier: 2
                    max_delay: 0

A message that exhausts its retries, or throws UnrecoverableExceptionInterface, is recorded as a failed job in the Laravel Cloud dashboard.

Local development

Override the cloud transport in your dev environment to process messages inline without SQS:

when@dev:
    framework:
        messenger:
            transports:
                cloud: 'sync://'

See the laravel/symfony-on-cloud documentation for all stamps and configuration options.

Laravel Cloud provisions the queue, configures access, and manages the underlying infrastructure. No additional credentials or setup are required.

Operate managed queues

How jobs are processed

Laravel Cloud long-polls each queue and delivers jobs directly to workers. Jobs are usually picked up within milliseconds when workers are running and within a second when a Flex queue wakes from zero. There is no polling interval to configure. Laravel Cloud extends a job’s visibility timeout in three-minute increments while it runs. If a worker crashes or stops before the job completes, the job is retried. Design jobs to tolerate at-least-once delivery. When a worker must stop, Flex workers have 90 seconds and Pro workers have one hour to finish their current job. Run jobs that may exceed 90 seconds on Pro.

Filesystem

Each managed queue worker has its own ephemeral filesystem. Every 1 GiB of worker memory provides 512 MiB of temporary disk space. Files are not shared between jobs and are reset whenever a worker is replaced. Use Laravel Object Storage for persistent files.

Observability

The Queues dashboard, under an environment’s Monitoring tab, shows job volume, processing duration, memory usage, active workers, and failed jobs for every managed queue. Failed jobs can be inspected, retried, or deleted from the dashboard or the Laravel Cloud API. Retries and deletions require edit access to the environment.

The Queues dashboard showing per-queue metrics and failed jobs

Worker output is included in the environment’s Logs tab.

Pausing and purging

Pause a queue from its canvas menu to stop processing while allowing in-flight jobs to finish. Laravel Cloud stops polling and scales workers to zero, so no worker or polling charges accrue while it is paused. New jobs remain in the queue until you resume it. The queue:pause Artisan command is not supported. Pause and purge actions require edit access to the environment. Purging removes every waiting job and cannot be undone. It may take up to 60 seconds and does not affect jobs already being processed.

Preview environments

Managed queues work in preview environments. Each preview receives isolated queues and workers, billed like other preview resources.

Pricing

Managed queues are billed for worker time and queue operations. Flex workers are billed only while running, while Pro workers are billed continuously. For example, a Flex queue that runs three workers for 20 minutes is billed for 3,600 worker-seconds. Standard queue operations cost $1 per 1 million operations and FIFO operations cost $1.10 per 1 million operations. Dispatching, starting, and deleting a successful job each count as an operation. Long-running jobs record additional visibility-extension operations while they run. Payload-bearing dispatches and starts are measured in 64 KB chunks, and a job payload may be up to 1 MiB. Laravel Cloud’s polling baseline is approximately $0.13 per queue each month. See Managed queues pricing for current regional pricing and plan limits.

Migration and compatibility

Limitations

Managed queues provide at-least-once delivery and best-effort ordering. Use a FIFO queue when strict ordering is required. Standard queues support delays up to 15 minutes; FIFO queues do not support per-job delays. Laravel Horizon and the queue:failed, queue:retry, and queue:clear Artisan commands do not support managed queues. Use the Queues dashboard or Laravel Cloud API to manage failed jobs.

Upgrading from earlier managed queues

The latest managed queue generation automatically manages polling, visibility, and shutdown timeouts. To upgrade an earlier queue, update Laravel to a supported version and commit the updated composer.lock, select a Flex or Pro size in the queue settings, and deploy. Your queue keeps its earlier runtime and settings until you select a new size. After upgrading, its previous polling interval, visibility timeout, and shutdown timeout settings no longer appear. Failed jobs carry over, but the queue cannot return to its earlier runtime. Queues that have not been upgraded retain their current settings and pricing until the earlier generation is retired on September 30, 2026. Those queues stop processing after that date. Because the underlying SQS queue retains a message for at most 14 days, jobs that remain unprocessed for longer than 14 days are lost.

Migrating from queue clusters

Queue clusters are deprecated and will be sunset on September 30, 2026. To move a queue cluster to managed queues, create a managed queue with the same queue name, choose an appropriate memory size and worker maximum, deploy, then verify jobs process through the Queues dashboard. Let the old queue drain before deleting its queue cluster. If a queue cluster processes several queue names, create a managed queue for each name. For complete instructions, including migration to worker clusters, see Migrate from queue clusters.

Queue workers and Scale-to-Zero

When a Laravel environment can scale to zero, it wakes to process queued jobs. However, its App cluster stops when the sleep timeout elapses, even if a job is still running. Use managed queues for queued jobs on environments that scale to zero. Their dedicated workers scale independently of your App cluster, so background processing is not interrupted when your application sleeps.

Get started

Basics

Private Cloud

Resources

Monitoring

Billing

Other

Managed Queues

Introduction

Managed queues vs. workers

Managed queues

Configure managed queues

Creating a managed queue

Queue types

Compute classes

Flex

Pro

Memory allocation

Worker autoscaling

Connect your application

Requirements

Queue connection

Setting a default queue

Requirements

Routing messages

Multiple queues, FIFO, and retries

Delays and retries

Local development

Operate managed queues

How jobs are processed

Filesystem

Observability

Pausing and purging

Preview environments

Pricing

Migration and compatibility

Limitations

Upgrading from earlier managed queues

Migrating from queue clusters

Queue workers and Scale-to-Zero

​Introduction

​Managed queues vs. workers

​Managed queues

​Configure managed queues

​Creating a managed queue

​Queue types

​Compute classes

Flex

Pro

​Memory allocation

​Worker autoscaling

​Connect your application

​Requirements

​Queue connection

​Setting a default queue

​Requirements

​Routing messages

​Multiple queues, FIFO, and retries

​Delays and retries

​Local development

​Operate managed queues

​How jobs are processed

​Filesystem

​Observability

​Pausing and purging

​Preview environments

​Pricing

​Migration and compatibility

​Limitations

​Upgrading from earlier managed queues

​Migrating from queue clusters

​Queue workers and Scale-to-Zero

Introduction

Managed queues vs. workers

Managed queues

Configure managed queues

Creating a managed queue

Queue types

Compute classes

Memory allocation

Worker autoscaling

Connect your application

Requirements

Queue connection

Setting a default queue

Requirements

Routing messages

Multiple queues, FIFO, and retries

Delays and retries

Local development

Operate managed queues

How jobs are processed

Filesystem

Observability

Pausing and purging

Preview environments

Pricing

Migration and compatibility

Limitations

Upgrading from earlier managed queues

Migrating from queue clusters

Queue workers and Scale-to-Zero