Queue background jobs from an API so requests return immediately.
Run a lightweight task queue without setting up Kafka or RabbitMQ.
Connect workers written in Python, Node.js, Go, or any language with a Redis client.
Automatically recover in-flight tasks after a worker or server crash.
| entgriff/ezra | carterperez-dev/exs-cyberjob-scraper | caudena/beam_weaver | |
|---|---|---|---|
| Stars | 26 | 21 | 20 |
| Language | Elixir | Elixir | Elixir |
| Setup difficulty | easy | easy | moderate |
| Complexity | 3/5 | 2/5 | 4/5 |
| Audience | developer | general | developer |
Figures from each repo's GitHub metadata at analysis time.
Runs as a single Docker container backed by a local SQLite file, no separate broker needed.
EZRA is a task queue server: a place where one part of your system can drop a job, and a separate part picks it up and does the work. The common use case is an API that receives a request, hands off the heavy processing to a queue so it can respond immediately, and lets a worker handle the time-consuming part in the background. Without a queue, the API blocks until the work finishes, and any jobs in progress are lost if the server restarts. What makes EZRA different from larger queueing systems like Kafka or RabbitMQ is that it is a single binary with no cluster to set up, no separate broker to manage, and no topics or queues to configure in advance. Everything is stored in a SQLite file on the same machine. The first time you push a task to a named queue, that queue is created automatically. You can start the server with one Docker command and be writing tasks within minutes. Workers connect using any standard Redis client library, in any programming language. EZRA speaks the same wire protocol that Redis uses for a specific feature called Streams, which tracks whether each message has been explicitly acknowledged. This means Python, Node.js, Go, Ruby, Java, or any other language that has a Redis library can talk to EZRA without modification, just pointed at a different port. EZRA does not implement general Redis commands like get and set, only the four Streams commands needed for the task queue pattern. Every task has an explicit lifecycle. A task is pushed, then claimed by a worker, then either acknowledged as successful or rejected as failed. If a worker claims a task and then crashes without acknowledging it, the task becomes available again after a configurable timeout. If the server itself restarts, all in-flight tasks return to available automatically. Tasks move to a dead queue after exhausting their retry count, where they can be inspected. The project is written in Elixir and runs on the Erlang runtime, which handles concurrency and reliability. It is maintained by a single author who does not accept pull requests but welcomes bug reports. The full README is longer than what was shown.
A single-binary task queue server that speaks the Redis Streams protocol so any language can push and process background jobs.
Mainly Elixir. The stack also includes Elixir, Erlang, SQLite.
The README does not state a license.
Setup difficulty is rated easy, with roughly 5min to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.