Queues

SKE maps your Laravel queue configuration to native cloud services. On AWS, queues use SQS. On GCP, queues use Cloud Tasks.

How it works

SKE reads your application’s queue configuration and provisions the corresponding infrastructure during deployment. Your Laravel jobs dispatch to these queues without code changes — the SKE adapter translates between Laravel’s queue interface and the cloud service.

The adapter binary handles:

• Receiving queue messages from SQS or Cloud Tasks
• Routing them to your Laravel application via the bridge package
• Reporting success or failure back to the queue service
• Managing dead-letter queues for failed jobs

Queue provisioning

Queues are provisioned automatically during deployment based on your ske.yml configuration:

name: my-app
environments:
  production:
    queues:
      - default
      - notifications
      - exports

Each named queue creates a corresponding SQS queue or Cloud Tasks queue in your cloud account, plus a dead-letter queue for failed messages.

Cloud service mapping

Feature	AWS	GCP
Queue service	SQS	Cloud Tasks
Dead-letter queue	SQS DLQ	Cloud Tasks retry config
Message retention	14 days (configurable)	N/A
Max message size	256 KB	1 MB

Environment variables

SKE sets queue-related environment variables automatically:

QUEUE_CONNECTION=sqs
SQS_PREFIX=https://sqs.us-east-1.amazonaws.com/123456789012
SQS_QUEUE=my-app-production-default

On GCP:

QUEUE_CONNECTION=cloud-tasks

Queue operations

Runtime queue management is covered in Operations: Queues.

How queue processing works

The SKE adapter receives queue messages and forwards them to your Laravel application through the bridge package:

1. SQS/Cloud Tasks delivers a message to the adapter
2. The adapter converts it to a synthetic HTTP POST to /__ske/queue
3. The bridge package’s queue handler processes the job via Worker::process()
4. The adapter reports the outcome back to the queue service

On AWS Lambda, the adapter uses batchItemFailures to report individual message failures within a batch, so successful messages aren’t retried. On Cloud Run, the HTTP response status determines success or failure.

Dead-letter queues

Failed messages (after exhausting retries) are moved to a dead-letter queue. You can inspect and retry dead-letter messages through the dashboard or API.