IronWorkers in PHP

This approach uses our depreciated workflow. Please see for the current process.

PHP has grown to be one of the most popular languages to write web software in. You can add some power to your current PHP application using PHP workers on IronWorker. This article will help you get started with PHP workers, but you should be familiar with the basics of IronWorker.

Table of Contents

Quick Start

Get the CLI

We’ve created a command line interface to the IronWorker service that makes working with the service a lot easier and more convenient. It does, however, require you to have Ruby 1.9+ installed and to install the iron_worker_ng gem. Once Ruby 1.9+ is installed, you can just run the following command to get the gem:

Command Line
$ gem install iron_worker_ng

Get the PHP Client Library

You can download the PHP client library, iron_worker_php, from Github. If you’re using PHP 5.3 or greater, you can just download the iron_worker.phar file. If you’re using an earlier version of PHP, you need to download the IronWorker.class.php file and the IronCore.class.php file from here.

If you aren’t sure which version of PHP you’re using, you can run php -v from your shell to find out.

Create Your Configuration File

The PHP library uses a configuration file or environment variables set that tell it what your credentials are. We have some pretty good documentation about how this works, but for simplicity’s sake, just save the following as iron.json in the same folder as your .worker file:

  "project_id": "INSERT YOUR PROJECT ID HERE",

You should insert your project ID and token into that iron.json file. Then, assuming you’re running the commands from within the folder, the CLI will pick up your credentials and use them automatically.

Write Your PHP Worker

Save the following as hello_worker.php:

echo "Hello from PHP";

Create a .worker File

Worker files are a simple way to define your worker and its dependencies. Save the following in a file called hello.worker

# set the runtime language. PHP workers use "php"
runtime "php"
# exec is the file that will be executed:
exec "hello_worker.php"

You could include gems and other files in there too. You can read more about .worker files here.

Upload the Worker

Command Line
$ iron_worker upload hello

That command will read your .worker file, create your worker code package and upload it to IronWorker. Head over to, click the Worker link on your projects list, then click the Tasks tab. You should see your new worker listed there with zero runs. Click on it to show the task list which will be empty, but not for long.

Queue Up Tasks for Your Worker

Save the following as enqueue.php:

/* If your PHP is less than 5.3,
   comment out the line above and uncomment the two following lines */

$worker = new IronWorker();
$res = $worker->postTask("PHPWorker");

You can now queue up a task by calling php enqueue.php from your shell.

Another way is to use CLI:

Command Line
$ iron_worker queue hello

Now look at the task list in HUD and you should see your task show up and go from “queued” to “running” to “completed”.

Now that we know it works, let’s queue up a bunch of tasks from code.

Note: Once you upload a code package, you can queue as many tasks as you'd like against it. You only need to re-upload the code package when your code changes.

Deep Dive

Payload Example

Retrieving the payload in PHP is the same as it is on any other language. Retrieve the -payload argument passed to the script, load that file, and parse it as JSON.

Fortunately, the iron_worker_php library includes a helper function with your worker that makes this easy. Just call getPayload(); to retrieve the payload.

$payload = getPayload();


The PHP environment that the workers run in on IronWorker is as follows:

PHP Version Version 5.3.6

Installed Modules


You can just use require_once('{MODULE_NAME}'); to use these modules in your workers.

Note: While it is possible to use these modules without bundling them, we highly recommend that you include modules your code is reliant upon in the code package whenever possible. Most of these modules are included in the environment because they are binary modules, making it impossible to supply them at runtime. The ones that are not binary modules are some of the more popular modules, which we include to allow users to try things out and test things with minimal setup and pain. We cannot guarantee which version of the module will be available, and we may update them without warning. Reliance on these modules may cause some unexpected conflicts in your code.