What Are Laravel Cloud Managed Queues?
Laravel Cloud's managed queues feature is a ground-up rebuild of how background job processing works on the platform. It solves three fundamental problems every team faces with queue infrastructure: reliability, observability, and cost.
Workers scale to zero when queues are empty and wake in under one second when new jobs arrive—30× faster than the previous Kubernetes pod cold-start time of ~30 seconds. You pay only for the compute and queue operations that actually ran.
Problems the Previous Approach Had
The earlier queue clusters solution had several pain points that shaped the managed queues rebuild:
- Queue depth could only be read through the application, so idle apps kept workers running.
- Multiple workers shared a single pod; one OOM crash took everything down.
- Scaling added large capacity increments (whole pods) rather than individual workers.
- Failed jobs were invisible—teams had to dig through logs to diagnose failures.
Key Features
Isolated Workers (One Worker, One Pod)
Every managed queue worker runs in its own Kubernetes pod with a guaranteed memory allocation. A 512 MB worker gets exactly 512 MB—nothing else shares it. One worker failing cannot affect another, and horizontal scaling now adds 256 MB increments instead of 4 GB ones.
Autoscaling Based on Queue Pressure
The scaling algorithm weighs both queue depth and average job runtime. Five jobs that each take two minutes require more workers than five jobs that complete in milliseconds. The algorithm can scale from 1 to 10 workers the moment it detects the workload won't clear fast enough—no manual tuning required.
FIFO Queues for Ordered Delivery
Two queue types are now available:
- Standard queues – high throughput, best-effort ordering, at-least-once delivery.
- FIFO queues – exactly-once delivery, strict first-in-first-out ordering. Use these for payment processing, ledger updates, or any workflow where sequence matters.
FIFO queue names carry a .fifo suffix, the type is fixed at creation, and high-throughput mode is on by default.
Scheduled Scaling Overrides
Know a nightly batch import or promotional window will spike your queue? Create cron-based scaling rules to pre-warm workers before demand hits, then return to normal autoscaling when the window closes.
Failed Job Dashboard
Failed jobs surface in a real-time dashboard with full detail—job volume, duration, average memory, and replica counts. You can drill into any failure to see why it failed and retry it with one click, without querying a database or escalating to engineering.
Bulk Failed-Job Actions
Retry or delete failed jobs across an entire queue in one operation instead of handling them individually.
Flex vs. Pro Compute
| Feature | Flex | Pro | |---|---|---| | Scale to zero | Yes | No | | Cold start | <1 second | None | | Max size | 2 GB | 8 GB (16 GB dedicated) | | Hardware | Spot | On-demand | | Availability | All plans | Growth and above |
Flex is the default and suits spiky or idle-heavy workloads. Pro stays warm at all times and handles job runtimes of approximately one hour, with automatic visibility timeout extension.
Pricing at a Glance
Managed queues are billed per second plus per million queue operations.
| Tier | Max Workers/Queue | Queues/Environment | |---|---|---| | Starter | 3 | 1 | | Growth | 100 | 10 | | Business | Unlimited | Unlimited |
Key Takeaways
- Workers scale to zero and wake in under one second, eliminating the cost-vs-latency trade-off.
- Each worker runs in its own pod—resource guarantees are real, not shared.
- The scaling algorithm uses job runtime and queue depth, not depth alone.
- FIFO queues guarantee exactly-once, ordered delivery for sensitive workflows.
- Failed jobs are visible and retryable directly from the Cloud dashboard.
- Existing managed queue users can access all improvements by running
composer updateand deploying.
Full configuration details are in the managed queues documentation.
Source: Managed Queues: Autoscaling Queue Workers on Laravel Cloud
