Faktory: a language-agnostic job server for background work
Language-agnostic persistent background job server
At a glance
- What is it?
- Faktory is a persistent work server that holds background jobs as JSON and hands them to workers over a network API. Here is what the repository documents, what the Docker image actually starts, and where the project stops short.
- Who is it for?
- Adopt Faktory when several languages in the same stack need one place to put background work and you are willing to run a server plus Redis. Do not adopt it if you want a library that lives inside one application process, or if your deployment forbids a stateful service.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 27 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem Faktory solves for polyglot teams
Most background job libraries are tied to one runtime. A Rails app gets one queue, a Go service gets another, and a Python data pipeline gets a third, each with its own retry rules and its own dashboard. Faktory takes the queue out of the application and puts it behind a network protocol. The README describes it plainly: it is "a work server" and "the repository for background jobs within your application", where jobs have a type and a set of arguments and sit in queues until workers fetch them.
The audience follows from that. If your stack is one language and one process, a library inside that process is simpler and you do not need a server. If you have a Ruby web app, a Go worker pool and a Python script that all need to enqueue work, a shared server means one dashboard, one retry policy and one place to look when a job disappears. Faktory is aimed at that second case.
Jobs as JSON, reserved for 30 minutes, requeued on failure
The mechanism is small enough to state in a paragraph. Jobs are represented as JSON hashes. Producers push a job to a queue; workers fetch from that queue. A fetched job is reserved with a timeout, 30 minutes by default. If the worker sends FAIL, or simply never sends ACK before the reservation expires, the job goes back to the queue. A FAIL also starts a retry workflow with exponential backoff.
That reservation model is the part worth thinking about. It means a worker that crashes mid-job does not lose the work, which is the main reason to run a server instead of an in-process queue. It also means the 30 minute default is a real setting, not a detail. A job that legitimately runs for 45 minutes will be requeued while the first worker is still running it, and you get two executions of the same job. The README does not discuss extending the reservation or documenting a heartbeat, so treat long-running jobs as something to test against your own workload before trusting the default.
The repository layout supports the description: server/, manager/, storage/, client/, cli/ and webui/ are separate top-level directories, and go.mod shows the server depends on github.com/redis/go-redis/v9 alongside a TOML parser. Redis is therefore part of the runtime, not an optional add-on. The webui/ directory is what backs the management and monitoring interface the README calls comprehensive.
Installing Faktory and pushing a first job
The README does not carry install commands. It says to see the Installation wiki page for current installation methods, and links separate wiki pages for Docker and AWS ECS. So the honest route is: read that wiki page, or use the Dockerfile in the repository, which shows exactly what the image contains.
The Dockerfile is based on alpine:3.24, installs redis, ca-certificates and socat, copies the binary to /faktory, creates /root/.faktory/db, /.faktory/db, /var/lib/faktory/db and /etc/faktory, and exposes ports 7419, 7420 and 7421. Its CMD starts the server bound to all interfaces:
CMD ["/faktory", "-w", "0.0.0.0:7420", "-b", "0.0.0.0:7419"]Two flags are visible there. -b sets the address workers connect to, and -w sets the web UI address. From that, 7419 is the worker protocol port and 7420 is the web UI. The third exposed port, 7421, is not explained in the Dockerfile or the README, so do not assume what it serves.
If you build from source instead, the Makefile gives the prerequisites. Running make prepare installs the build tools the project expects:
go install golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize@latest
go install github.com/benbjohnson/ego/[email protected]The Makefile's own comment says that after this you should be ready to run "make", and the default goal is help. Note that go.mod pins go 1.25, so the toolchain you build with needs to be at least that.
Once a server is up, the first real use is to enqueue a job and watch it in the web UI. The README describes the shape of a job rather than a command: a type, a set of arguments, and a queue. The client/ directory and the example/ directory, which contains example/config.toml, are where the concrete client calls and server configuration live. The README does not print a push example, so take the exact call from those sources rather than from memory.
Where Faktory is the wrong tool
The reservation timeout is the clearest failure mode. Any job whose runtime can approach 30 minutes needs either a shorter job or an explicit reservation strategy, and the README does not document one. Teams that schedule long batch work should check this before migrating.
Redis is the second constraint. go.mod lists go-redis as a direct dependency, and the Dockerfile installs a Redis server into the image. That means Faktory is not a single static binary you can drop on a box with no other services. You are operating two stateful components, and the durability of your jobs depends on how Redis is configured, which the README does not cover at all.
Third, the README's installation section is a pointer, not instructions. It sends you to a wiki page and to separate Docker and AWS ECS pages. That is a normal split for a project with packaging/ and Ent-Changes.md in the tree, but it means the repository alone does not tell you which package format to pick for your distribution. If you need a self-contained install story in the repo, this is not it.
Faktory compared with in-process job libraries
The real alternative for most teams is a job library that runs inside the application, such as the background job systems built into a given framework. The difference is architectural, not cosmetic. An in-process library stores jobs in the same database as your application and runs them in the same process or a sibling process. There is no protocol, no separate server, no second network hop, and no Redis requirement beyond whatever the library already uses.
Faktory trades that simplicity for language independence. Because jobs are JSON hashes pushed to queues over the Faktory API, a Ruby producer and a Go worker can share a queue without either side knowing the other's runtime. You also get the reservation and requeue semantics described above, plus a web UI for management and monitoring, which in-process libraries typically leave to you.
The cost is operational. You now run a server, you now run Redis, and you now have a port to secure. For a single-language monolith, that is a poor trade. For a stack where three runtimes already need to hand work to each other, it removes duplicated retry logic and gives one place to inspect.
Maintenance, licensing and upgrade cost
The last push to the repository was on 2026-09-03, and the most recent release listed is v1.10.0 from 2026-08-10, following v1.9.4 in February 2026 and v1.9.3 in July 2025. The repository is not archived. The Makefile carries VERSION=1.10.1, which is ahead of the newest tagged release, so the tree is moving between releases rather than sitting still.
Upgrade cost is mostly about the client libraries you use on the producer and worker side, not the server binary. The server speaks a protocol; the README does not describe protocol version negotiation or a compatibility matrix, so if you pin an old client, verify it against the server version you deploy rather than assuming forward compatibility.
Licensing needs care. The repository metadata reports the licence as NOASSERTION, and the tree contains both LICENSE and COMM-LICENSE alongside Ent-Changes.md. Two licence files and an enterprise changelog mean the open source and commercial parts are separated somewhere in this project, and the README does not explain the boundary. Read LICENSE and COMM-LICENSE yourself before you ship, and treat the naming of Ent-Changes.md as a signal that some features are not in the open source build. This is a description of what is in the tree, not legal advice.
Editorial conclusion
Adopt Faktory when several languages in the same stack need one place to put background work and you are willing to run a server plus Redis. Do not adopt it if you want a library that lives inside one application process, or if your deployment forbids a stateful service. Before committing, verify the reservation timeout against your slowest job, confirm the queue names your workers will poll, and read the Installation wiki page for the current package list, because the README only points there.
Frequently asked questions
Can I use Faktory from Python or Node.js?
Yes. Faktory is language-agnostic: the README states that jobs can be executed with any language by clients using the Faktory API to fetch a job from a queue. The server itself is written in Go, but producers and workers are not tied to Go.
What ports does the Faktory Docker image expose?
The Dockerfile exposes 7419, 7420 and 7421, and its CMD starts the server with -b 0.0.0.0:7419 and -w 0.0.0.0:7420. That makes 7419 the worker protocol port and 7420 the web UI; the README and Dockerfile do not explain what 7421 serves.
Does Faktory need Redis?
Yes. The Dockerfile installs redis into the image, and go.mod lists github.com/redis/go-redis/v9 as a direct dependency of the module. Faktory is not a standalone binary with no other services.
How do I install Faktory?
The README does not include install commands. It points to the Installation wiki page for current installation methods, with separate wiki pages for Docker and AWS ECS. The repository's Dockerfile shows what the container image contains and how the server is started.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/contribsys-faktory)