Weave Code
Laravel Google Cloud Tasks Queue Laravel Package
stackkit/laravel-google-cloud-tasks-queue
Use Google Cloud Tasks as a Laravel queue driver. This package dispatches Laravel queued jobs to Cloud Tasks with support for queues, delays, retries, and secure HTTP handlers, making it ideal for serverless and App Engine workloads without managing workers.
Google Cloud Tasks queue driver for Laravel
Frequently asked questions about Laravel Google Cloud Tasks Queue
- How do I install and configure the Google Cloud Tasks queue driver for Laravel?
- Install it with composer require stackkit/laravel-google-cloud-tasks-queue, publish the package config, and add a google-cloud-tasks connection to config/queue.php. Supply your GCP project ID, region or location, queue name, and service account credentials through environment variables, and make sure the app exposes a publicly routable HTTPS route Cloud Tasks can call back to. Most of the effort goes into IAM and service account scoping rather than the package API. Budget roughly a day for a first working queue plus a security review of the OIDC callback path.
- Does stackkit/laravel-google-cloud-tasks-queue support job delays, retries, and multiple queues?
- Yes. The driver maps Laravel queue features onto Cloud Tasks: named queues become Cloud Tasks queues, delayed dispatch maps to a task schedule time, and job retries map to Cloud Tasks retry configuration. You configure all of this through the queue connection in config/queue.php. Check any per-job tries or backoff settings against the Cloud Tasks queue's own retry limits, because Cloud Tasks enforces its own caps on attempts and backoff.
- Which Laravel and PHP versions does this package support?
- The package follows Laravel's release cadence: v5.x targets Laravel 11 and 12, while v6.0.0 is a Laravel 13 support release. Because v6.0.0 is a major bump for a framework-support-only change, expect it to drop older Laravel lines and possibly raise the minimum PHP version. Verify the illuminate/* constraints and the PHP floor in composer.json before upgrading, and check the changelog and CI matrix for the exact supported combination rather than assuming.
- How does Cloud Tasks execute a Laravel job, and how is the callback endpoint secured?
- Jobs are serialized into a Cloud Tasks HTTP target task, and Cloud Tasks makes an authenticated HTTPS request back into your application, where the package hands the payload to Laravel's queue pipeline. The callback route is protected with OIDC token verification so only Cloud Tasks, or a principal holding the correct service account, can invoke it. That means your app must be reachable over HTTPS, at least from Google infrastructure, and the invoking service account must be allowed to mint tokens for the target audience. Review ingress, firewall, and CSRF exemptions for that route before going live.
- Can I use this driver on Cloud Run or App Engine without running queue workers?
- Yes, that is the main appeal. Cloud Tasks handles dispatch and pushes the work over HTTP, so your application executes the job inside the incoming request instead of relying on long-running queue:work processes. That suits Cloud Run, App Engine, GKE, or any autoscaled HTTP-only environment where keeping workers alive is awkward or expensive. Remember the request still has to finish inside the platform timeout and the Cloud Tasks dispatch deadline.
- What Cloud Tasks payload size and timeout limits should I check before migrating?
- Cloud Tasks enforces a per-task payload ceiling of roughly 100 KB including headers, a bounded dispatch deadline, and per-queue rate and concurrency limits. These are constraints of Cloud Tasks itself, not of this package, so they apply to any driver you put in front of it. If your jobs carry large models or blobs, persist that data elsewhere and pass a reference in the payload instead. Compare your slowest job's realistic runtime against your queue's max dispatch deadline before committing.
- Do I still need Redis or a database queue table with this package?
- No. When a job is dispatched on this connection the task lives in Cloud Tasks rather than in Redis or the jobs table, so you do not need to operate Redis or run queue:work for that connection. Other connections in the same application can keep using Redis or the database driver, so you can migrate queue by queue. You should still plan failure visibility, using Cloud Tasks logs and retry configuration alongside your usual error reporting.
- How do I test Cloud Tasks jobs locally without hitting real GCP infrastructure?
- Keep most of your suite on Laravel's sync or fake queue so no real HTTP calls are made, and run the queue feature suite against a non-production Cloud Tasks queue. For the callback path, exercise the route with a locally signed JWT or a stubbed OIDC verifier and confirm that unsigned or wrongly-audienced requests are rejected. A single staging queue with a genuine OIDC round trip is the cheapest way to prove IAM and ingress are correct before production.
- What should I check when moving to v6.0.0 alongside a Laravel 13 upgrade?
- Treat v6.0.0 as a passenger on the Laravel 13 upgrade and move both constraints in the same branch, since you likely cannot adopt one without the other. The diff is framework support only, so expect zero application-code changes; if config keys, job classes, or dispatch calls need edits, your tests will surface it immediately. Verify the illuminate/* constraints, the PHP version floor, and the google/cloud-tasks SDK version, then re-test the surfaces most likely to drift with a framework major: chained jobs, dispatchAfterResponse, per-job connection overrides, rate limiting, and job middleware. Canary one low-criticality queue through staging with a real OIDC round trip before rolling production queue by queue.
- What are the alternatives, and is this package risky to depend on?
- Alternatives include Laravel's built-in Redis, database, and SQS drivers, or running your own worker fleet on GCP. Choose this package when you are committed to GCP and want managed dispatch without operating queue infrastructure, and avoid it if you need multi-cloud portability, large payloads, or very long runtimes. On maintenance, the codebase is thin but the release cadence is welded to Laravel's annual majors and it is a small-team package, so pin versions, watch the repository, and keep the driver swappable behind standard Laravel queue APIs as a fallback.
Weaver
How can I help you explore Laravel packages today?