wp-executor

Cross-plugin architecture showing wp-executor as the off-host runner that polls WP-PFWorkflow's remote queue

wp-executor is an open-source runner that takes your workflow events and runs them on your own machine, in your own tools — shell commands, scripts, the filesystem, your local apps and integrations. It bridges WordPress automation with your own environment: a workflow can trigger in WordPress and execute right where your tools live.

It is a single binary written in Rust, distributed independently of the WordPress plugins. The platform composes the intent of an automation; the executor performs the actions that automation requires, on the machine you operate.

Source code & releases: github.com/Project-Flash-Build/wp-executor
Licence: MIT or Apache-2.0, at your option.
Cost: free — you do not need a Setyenv licence to run wp-executor itself; you only need a WP-PFWorkflow licence on the WordPress side that publishes work for it.

Why a separate binary

Some operations should not run inside the WordPress request lifecycle: repository synchronisation, media transcoding, scheduled backups, anything that benefits from a separate execution boundary, a longer timeout, or access to a network the WordPress server cannot reach.

wp-executor runs on a machine you operate. WP-PFWorkflow publishes job intents to its own remote queue; the executor polls that queue on its own cadence, claims a job, runs it under its local capability allowlist, and posts the result back. The WordPress server never initiates a connection out to the executor.

Where to go next

Getting started — install and wire it to a Workflow site.
Capabilities — what kinds of work it can perform.
Configuration — the config.toml fields.
Security model — authentication, allowlisting, secret handling.
CLI — quick reference for the binary itself.

The canonical reference for every flag, default and protocol detail lives in the repository's README and scripts/config.example.toml — those move in lockstep with the source code.