> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tai42.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# backend-rq

> RQ execution backend for the TAI ecosystem — background tool runs and schedules over Redis.

<Info>`Backend` plugin · listing `tai42/backend-rq`</Info>

## Install

```bash theme={null}
tai plugins install tai42-backend-rq
```

## Permissions

| Capability | Declared |
| ---------- | -------- |
| Network    | yes      |
| Subprocess | yes      |
| Filesystem | no       |

## Provides

<h3 id="rq">
  rq
</h3>

`Backend` — RQ execution backend — background tool runs and schedules over Redis.

RQ is Redis-only like arq, with a worker, a scheduler, and the RQ dashboard.

## Enable it

```yaml manifest.yml theme={null}
backend_module: tai42_backend_rq
```

## Configuration

The `RQ_` env group. `RQ_REDIS_URL` falls back to the shared
`TAI_DEFAULT_REDIS_URL` when unset; a set `RQ_REDIS_URL` always wins.

| Variable           | Default                    | Effect                                                                              |
| ------------------ | -------------------------- | ----------------------------------------------------------------------------------- |
| `RQ_REDIS_URL`     | `redis://localhost:6379/0` | Broker and results.                                                                 |
| `RQ_RQ_PREFIX`     | `rq:`                      | Key prefix for every RQ structure in Redis.                                         |
| `RQ_TASK_TIMEOUT`  | `300`                      | Seconds a synchronous dispatch waits for a result.                                  |
| `RQ_MANIFEST_KEY`  | `MANIFEST_KEY`             | Env var the worker stores the manifest JSON under, inherited by forked work-horses. |
| `RQ_TOOL_NAME_ARG` | `backend_tool_name`        | Queued-job kwarg naming the target tool.                                            |

## Run the processes

```bash theme={null}
tai backend worker --pool prefork
tai backend beat
tai backend dashboard
```

The `worker` runtime runs RQ's work loop on a dedicated thread, so the process's
event loop stays free for worker-bus ops. Its lifecycle is the shared one every
backend gets: it waits for the app to finish booting before it consumes, then
SIGTERM (or SIGINT) drains it warm — no new jobs, the current one finishes, the
process exits after teardown — and a second signal kills the running work-horse.
An idle worker stops within one dequeue poll (5s).

`beat` and `dashboard` pull no queued work, so they run on the event loop and
keep whatever signal handling their own CLI installs. Nothing else runs in those
processes, so that is deliberate.

## Quirks

* RQ has no disabled-schedule state, so `backend_list_schedules` always reports a
  schedule as enabled, and disabling one deletes it.
* `backend_registered_tasks` and `backend_list_failed_tasks` are not implemented.

## See also

* [Backends](/concepts/backends) — the contract all three shipped backends implement.
* [Schedule a tool](/guides/schedule-a-tool) — putting work on a schedule.