Overview

Sepp aims to be a small, language-agnostic, easy to set up, durable job queue. It is distributed as a single binary with no external dependencies, meaning you don't need to set up an additional database or message broker to use it.

What is a job queue?

A job queue is a system that allows producers to enqueue jobs for workers to complete in an asynchronous manner, including across different programming languages. For example, a Rust backend service might schedule a job to send an email, which is then picked up by a Python worker that has access to a SMTP server. Durable job queues like sepp persist these jobs onto disk so that they are not lost in the event of a server crash or restart.

Reasons to use sepp

• Easy to set up, manage and run. Sepp is a single binary with embedded storage, so there is no database or message broker to install alongside it.
• Excellent performance whilst being fully durable. Every operation is persisted before it is acknowledged, and enqueue throughput is still roughly 10x beanstalkd and 20x NATS JetStream. See the benchmarks.
• Works from any language. Producers and workers talk gRPC and don't need to share a language, and you can build your own client from the published protocol.
• The hard parts of a queue come out of the box: leases, retries, dead-lettering, scheduling, priorities and idempotent enqueue. Building these correctly on top of a general-purpose datastore is harder than it looks.
• Ready for production debugging, with OpenTelemetry tracing and metrics and a built-in admin UI for inspecting jobs and server state.

Reasons not to use sepp

• Sepp is not distributed. It runs on a single node with no replication or failover, so if the machine goes down, the queue is unavailable until it is back.
• Delivery is at-least-once, not exactly-once. Workers must be able to tolerate the occasional duplicate.
• Jobs cannot be enqueued atomically with your own database writes. If a job must commit in the same transaction as your data, a queue inside your database is a better fit.
• Sepp is a job queue, not an event stream. There is no pub/sub fan-out, replay or consumer groups; Kafka or NATS are better tools for that.
• Sepp is pre-1.0 and hasn't had years of production hardening yet. Expect some rough edges and breaking changes.

Start here

Core feature map

• Fully durable by default — every job is persisted to disk before responding. Durability
• At-least-once delivery — leased jobs return to ready if a worker dies. Delivery guarantees
• Priority & scheduling — run-at timestamps and per-job priority. Scheduling
• Retries & dead-letter — bounded retries, then sideline for inspection. Retries
• Idempotent enqueue — dedup keys collapse duplicate producers. Idempotency
• Language-agnostic — one gRPC line protocol, any client. Build your own
• Built-in admin UI — real-time server state, job inspection, configuration and more. Admin UI