Skip to content

What is Conveyor? ​

Conveyor is a multi-backend TypeScript job queue that brings the BullMQ developer experience to any runtime and any database — without requiring Redis.

Why Conveyor? ​

  • BullMQ is great but requires Redis as the sole backend
  • Small-to-medium projects don't always have Redis in their infrastructure
  • PostgreSQL is often already in the stack — why add Redis just for jobs?
  • SQLite is perfect for local dev, CLI tools, and embedded apps
  • No existing solution offers a unified multi-backend API with native Deno support

Key Features ​

FeatureDescription
SchedulingDelays, cron, human-readable intervals ("in 5 minutes", "every 2 hours")
Retry & BackoffFixed, exponential, or custom backoff strategies
ConcurrencyPer-worker and global concurrency control
Rate LimitingSliding window limiter per worker
DeduplicationBy payload hash or custom key with TTL
PriorityNumeric priority ordering (lower = higher)
FlowsParent-child job dependencies with failure policies
BatchingProcess multiple jobs as a single unit
ObservablesSubscribe to job state changes with cancellation
GroupsPer-group concurrency, rate limiting, round-robin
EventsReal-time lifecycle events for every job state transition
Graceful ShutdownWait for active jobs before closing

Supported Stores ​

StoreBest For
MemoryTesting, prototyping, local development
PostgreSQLProduction workloads, existing PG infrastructure
SQLiteEmbedded apps, CLI tools, single-server deployments

Architecture ​

Conveyor uses an adapter pattern — the core never depends on a concrete driver. Each store implements StoreInterface:

┌──────────────────────────────────┐
│          @conveyor/core          │
│  Queue · Worker · Job · Events   │
├──────────────────────────────────┤
│          StoreInterface          │
│  save · fetch · lock · update    │
├──────────┬───────────┬───────────┤
│  Memory  │ PostgreSQL│  SQLite   │
└──────────┴───────────┴───────────┘

Next Steps ​

Released under the MIT License.