Laravel Azure Storage Queue

Storage Queues are the cheap option on Azure: no namespace to provision, no per-operation pricing surprise, and adequate for most background work. What they are not is generous about message size.

The 64 KiB problem

Azure caps a queue message at 64 KiB, and that ceiling applies after base64 encoding — so the real budget is smaller than it looks. A serialised Laravel job carrying a couple of Eloquent models will cross it more often than you would expect, and the failure arrives at dispatch time as an opaque rejection.

The driver compresses any payload that would breach the limit with gzip and marks it with a gz: prefix, decompressing on the way back out. Jobs that fit are left alone, so there is no cost for the common case.

Configuration

'azure' => [
    'driver'       => 'azure-storage-queue',
    'account_name' => env('AZURE_STORAGE_ACCOUNT_NAME'),
    'account_key'  => env('AZURE_STORAGE_ACCOUNT_KEY'),
    'endpoint'     => env('AZURE_STORAGE_QUEUE_ENDPOINT'),
    'queue'        => env('AZURE_QUEUE_NAME', 'default'),
    'timeout'      => env('AZURE_QUEUE_TIMEOUT', 60),
],

The custom endpoint is there so the driver works against Azurite, the local storage emulator — worth having, because the alternative is a shared development storage account and the race conditions that come with it.

Limits worth knowing before you adopt it

• Maximum TTL is seven days, and later() delays are capped at the same figure.
• Ordering is best-effort FIFO across concurrent workers, not guaranteed. If you need strict ordering, Storage Queues are the wrong primitive and Service Bus sessions are the right one.
• bulk() loops individual push() calls, because the Storage Queue API has no native batch enqueue.

It is Horizon-compatible, so job monitoring works as usual.