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.