php-queue puts one interface in front of Redis, Memcache, MongoDB and CSV

One abstraction over four bundled backends

The premise of php-queue is stated as a list of frustrations: choosing between backends such as Beanstalk, Amazon SQS or RabbitMQ and not knowing which is efficient, the learning curve of each client library, the time it takes to write the application code around it, being locked into one vendor, and having to make large code changes when the use case shifts. The library's answer is to sit between your code and the implementation. Several backend drivers are bundled: Memcache, Redis, MongoDB and CSV, and the documentation says these can serve either as the primary job queue server or as an abstract FIFO or key-value access layer. That dual role matters. The same driver can hold a work queue in one part of your system and a plain cache in another, and the abstraction is what lets the second use case reuse the first one's plumbing. The consequence is that php-queue is not a broker. It does not implement delivery guarantees, priority, delayed jobs or visibility timeouts, because those belong to the backend you plug in.

Queues hold work, workers process it, runners keep the loop alive

The vocabulary is small and worth learning precisely, because the classes are the API. A job queue is referenced by name, and the code asks the queue for the next item, receiving a Job object carrying the data and a job id. Each JobQueue can be configured to carry one type of work or several kinds of target worker, and the developer controls both the retrieval of job data from the backend and how it is instantiated as a Job object, so the Job records which workers it is targeted at. Workers are independent of the queues: a worker only has to process input data and return the result, and the queue dispatcher handles the rest, which also makes workers chainable. The recommended project layout mirrors that division, with an htdocs folder, a queues folder holding one queue class per queue in CamelCase naming, a workers folder with the same convention, a runners folder, a cli.php file and a config.php file, and the demonstration application inside the vendor directory shows the shape of a real setup. The runners are where the long lived process lives, and the repository points at its own runner documentation for that part.

Composer install and a config file that points at your folders

Installation follows the usual Composer route. You add coderkungfu/php-queue as a dependency, install Composer itself, and run the installer.

curl -s "http://getcomposer.org/installer" | php

php composer.phar install

Dependencies land in a vendor folder, and you load Composer's autoloader from your own entry point.

<?php
require_once '/path/to/vendor/autoload.php';
?>

The recommended next step is to move that autoloader statement and your application configuration into a separate config.php file, and to point the library at your queue and worker directories.

<?php
require_once '/path/to/vendor/autoload.php';
PHPQueue\Base::$queue_path = __DIR__ . '/queues/';
PHPQueue\Base::$worker_path = __DIR__ . '/workers/';
?>

There is a second way to do the same thing, by declaring namespaces instead of paths, with the queue and worker namespaces set on the base class. The documentation notes that the library will then try to instantiate the JobQueue and Worker classes using your namespace with the queue or worker name appended, and it also warns about mixing the two approaches: if you set both the paths and the namespaces, the files are loaded with require_once from the folder path and instantiated with the namespaced class names, so a mismatch between the two produces a confusing failure rather than an obvious one.

The REST server exposes enqueue and trigger over HTTP

The library ships a REST server so that other systems can add work without talking to the queue backend directly. You copy the htdocs folder from the demonstration application into your installation, and the index.php file calls the defaultRoutes method, which prepares an instance of the Respect\Rest server. You may need to adjust the path to config.php inside index.php, and the recommended deployment is a new virtual host with htdocs mapped as the web root. The routes are simple. Adding a job is a POST to the queue name, either as a form or as JSON.

# Form post
curl -XPOST http://localhost/<QueueName>/ -d "var1=foo&var2=bar"

# JSON post
curl -XPOST http://localhost/<QueueName>/ -H "Content-Type: application/json" -d '{"var1":"foo","var2":"bar"}'

Triggering the next job is a PUT to the same path.

curl -XPUT http://localhost/<QueueName>/

The documentation points at the Respect\Rest documentation for extending this further, and gives basic authentication as the example of what you would add. Worth noting for a security review: the default routes are unauthenticated, so anything that can reach the virtual host can enqueue work, and the library deliberately leaves that decision to you.

The CLI mirrors the REST routes for shell driven workflows

The command line interface is the other half of the same abstraction. You copy cli.php from the demonstration application into your installation, adjust the path to config.php inside it, and you can add a job with a data payload.

$ php cli.php <QueueName> add --data '{"boo":"bar","foo":"car"}'

Triggering the next job is a work command.

$ php cli.php <QueueName> work

The documentation notes that you can extend the CLI class to build your own batch commands, and gives importing data from a MySQL database into a queue as the example. That extension point is the practical reason to include the CLI in your deployment rather than treating it as a convenience: a data import that has to run on a schedule, in a specific order, with a specific payload shape, is exactly the kind of work that a queue is for, and the class is designed to be subclassed. The same openness applies to the REST server and to the core library files, which the documentation explicitly invites you to include in your own application.

AtomicReadBuffer is the one behaviour that changes the failure model

The interfaces section describes the contracts a backend may support, and the first one named is AtomicReadBuffer, described as the recommended way to consume messages. It provides a popAtomic method taking a callback, and the documented property is that it rolls back the popped record if the callback exits with an exception.

    $queue = new PHPQueue\Backend\PDO($options);

    $queue->popAtomic(function ($message) use ($processor) {
        $processor->churn($message);
    });

That single feature is what separates a queue that retries failed jobs from one that loses them, and it is the reason the interface list is worth reading before choosing a driver. But the wording is careful: the backends support one or more of these interfaces. Support is not universal, and the documentation does not enumerate which of the four bundled drivers implements AtomicReadBuffer. If your work involves side effects that cannot be repeated, a driver without rollback semantics is a different product from one with them, and a short script that pushes a message and pops it with a throwing callback will tell you which case you have. The example in the documentation uses the PDO backend, which suggests a SQL queue is at least possible, though it is not one of the four bundled drivers named in the benefits section.

A single release, a Travis build and no stated licence

The project status deserves a plain statement. The repository listing reports no licence identifier, which for a library on Packagist is a real obstacle for adoption, since the terms in the repository are what a legal reviewer needs and the metadata does not point them out. The release list contains one entry, version 1.0.3, published on 2026-05-06, and the last push carries the same timestamp, so the tagged release and the current state of the tree are the same moment. The default branch is master, and the build badge in the README points at a Travis build, with a.travis.yml file and phpunit configuration files for the test suite, a composer.json manifest, and a src directory alongside a test directory and the demo application. The homepage is the Packagist package page rather than a separate site. With only one tagged release listed, the practical advice is to pin 1.0.3 exactly, read the source of the driver you plan to use rather than assuming the documentation covers it, and settle the licensing question with the maintainer before you put it in a commercial product.

Editorial conclusion

php-queue is a reasonable fit for a PHP application that wants to try more than one queue backend, or that needs a simple HTTP endpoint to enqueue work without giving workers direct access to the broker, since the REST server and the CLI give you both from the same abstraction. It is a poor fit for a team that needs delivery guarantees, visibility tooling or a clearly stated licence, because the library is a thin wrapper rather than a broker and the repository listing reports no licence identifier. Verify three things before you depend on it: which behaviours are actually shared across the four bundled drivers, since the interface list names AtomicReadBuffer and others as supported by one or more backends rather than by all of them, how the AtomicReadBuffer rollback behaves with your chosen backend, and what happens to a job when a worker process dies mid job. The project is published on Packagist as coderkungfu/php-queue, the only release listed is 1.0.3, and the last push was on 2026-05-06.

Frequently asked questions

Official sources

1. CoderKungfu/php-queue on GitHub
2. Issues
3. Project website
4. README
5. Releases