Faktory

Faktory uses a custom TCP protocol (FaktoryDB) for job push/fetch — not REST. Worker libraries abstract this into language-native patterns (e.g., Python: faktory-worker). The REST API is for management: GET /api/queues (queue stats), GET /api/jobs/failed (failed jobs), POST /api/jobs/retry, DELETE /api/jobs/{jid} (delete job). The TCP protocol uses a line-based text format (similar to Redis protocol). Job payloads are JSON. The REST API is limited; primary interaction is via worker libraries for job lifecycle and TCP for custom workers.

Faktory is a language-agnostic background job server created by Mike Perham (the Sidekiq author), designed to bring Sidekiq-style job processing to non-Ruby languages. It provides a TCP-based FaktoryDB protocol for job push/fetch and a REST API for management and stats. Worker libraries exist for Ruby, Go, Python, JavaScript, Rust, and others. Agents can enqueue jobs via the worker library or TCP protocol and monitor job queues via the REST API. The Web UI provides a dashboard for job monitoring. Self-hosted; open-source under LGPL. Confidence is docs-derived.

Faktory supports password authentication on the TCP connection (HELLO command with password hash). The Web UI and REST API also use password auth (Basic Auth). Password is set in the FAKTORY_PASSWORD environment variable. No per-queue or per-user scoping — single password model. Self-hosted deployments must protect the TCP port (7419) and Web UI (7420) at the network level. Appropriate for internal-network deployments; not designed for public exposure.

Documentation lives primarily on the GitHub wiki (github.com/contribsys/faktory/wiki). Covers installation, configuration, the FaktoryDB protocol spec, REST API, and worker library links. The protocol documentation is detailed. REST API is less comprehensively documented. Community support via GitHub Issues. Documentation quality is adequate for experienced backend developers familiar with job queue concepts. Less polished than commercial alternatives but functional.

Faktory provides explicit job lifecycle states: ENQUEUED, WORKING, SUCCEEDED, FAILED, SCHEDULED, RETRYING, DEAD. Failed jobs have configurable retry policies with exponential backoff. Dead (exhausted retry) jobs are accessible via the REST API for inspection and manual retry. The FaktoryDB protocol returns clear error messages for malformed commands. The Web UI provides retry and delete controls. Error handling is pragmatic and operational.