Laravel Worker On Pivotal Cloudfoundry

Laravel Worker On Pivotal Cloudfoundry

Laravel workers requires a separate application to be spun up as its health check type, route and commands are different from running a Laravel application served through HTTP(s). In this post, I describe considerations to take, problems that you might face and how I resolved them.

State Management

Having a separate application process means that state has to be well managed. This is a concurrency problem. You can think of your two different applications as two different threads. States include: cache, application, queue and file. Preferably through non-file system drivers.

Hence, you’ll minimally require a simple database table as your queue driver. However, it is recommended to have something better than just that – Redis. For my filesystem, I use S3 to store and share files.

User Provided Services

Application secrets are shared through User Provided Services. This is to ensure the ease of secret sharing between your main Laravel application and your worker application.

The following is a manifest is a Laravel worker that I would like to share with you. And I hope you’ll find it useful for your Laravel projects running on Pivotal Web Services or any other Pivotal Cloudfoundry out there.


- name: laravel-api-v1-worker
  memory: 256M
  path: .
  services: [
  buildpack: php_buildpack
    CACHE_DRIVER: "redis"
    QUEUE_DRIVER: "redis"
    SESSION_DRIVER: "redis"
    MAIL_DRIVER: "ses"
  instances: 1
  health-check-type: process
  no-route: true
  command: php artisan queue:work --tries=3 --daemon --memory=256

Author: Woo Huiren

Currently a student at National University of Singapore. I contribute to opensource projects - primarily PHP and Angular related. I write about PCF and PWS related stuff too.

One thought on “Laravel Worker On Pivotal Cloudfoundry”

Leave a Reply