Self-hosted HTTP message broker
Http Messaging
& Scheduling
Enqueue durable jobs over HTTP. Schedule execution, control throughput, deliver signed webhooks and recover from failure — all from a single service.
100%
Free Forever · Fully open source
99.99%
Delivery success with retries
<5ms
Enqueue acknowledgement
0-9
Priority levels per queue
Built on dependable infrastructure
- RocksDB
- SlateDB
- Raft
- Prometheus
- Docker
- S3
- Cloudflare R2
- Any S3-compatible object storage
Why betterMQ
Reliable delivery shouldn't require a fleet of services
Most job systems require queues, schedulers, workers, retry systems and monitoring stitched together. BetterMQ combines these capabilities into a single deployable service.
Traditional Stack
- 01Queue
- 02Workers
- 03Scheduler
- 04Retry Logic
- 05Rate Limiter
- 06Webhook Sender
- 07Monitoring
7 services. 7 deployments. 7 things to monitor.
betterMQ
1 binary. 1 deployment. Everything included.
How it works
Push jobs through a durable delivery pipeline
Every job follows the same lifecycle.
Accept
Job written durably before acknowledgement.
Schedule
Delay, cron or interval evaluation.
Control
Rate limits, parallelism and priority.
Deliver
Signed webhook dispatched.
Recover
Retries, backoff and DLQ.
Capabilities
Everything required for reliable job execution
Messaging
Durable named queues, fan-out groups and publish APIs over plain HTTP.
Scheduling
One-time delays, recurring intervals and full cron expressions.
Flow Control
Rate limits, parallelism caps and per-key isolation lanes.
Priority
Priority 0-9 scheduling keeps urgent work ahead of bulk traffic.
Reliability
Exponential backoff, dead letter queues and circuit breakers.
Operations
Control panel, Prometheus metrics, health checks and OpenAPI.
#01 — Messaging
Durable HTTP queues
Store jobs safely and deliver them when ready.
Named queues
Organize work into isolated queues with their own settings.
Fan-out groups
Publish once, deliver to every subscribed endpoint.
At-least-once delivery
Every accepted job is delivered or dead-lettered. Never lost.
Idempotency keys
Duplicate publishes are deduplicated automatically.
curl -X POST http://localhost:8080/v1/enqueue \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"queue": "jobs",
"key": "user-42",
"body": { "task": "send_invoice", "invoice_id": 99 },
"priority": 8,
"idempotency_key": "inv-99",
"sign": true
}'
HTTP/1.1 202 Accepted
{ "message_id": "7c9e6679-…", "queue": "jobs", "duplicate": false }#02 — Scheduling
Run jobs when they matter
One-time delays, recurring intervals and cron schedules.
Cron expressions
Full cron syntax for precise recurring execution.
Recurring intervals
Run every N seconds, minutes or hours without cron math.
One-time delays
Defer a single job into the future with a simple delay.
0 9 * * *Daily digest — every day at 09:00every 30 secondsHealth probe — recurring intervaldelay 60 secondsAbandoned cart — one-time delay
#03 — Flow Control
Control throughput before overload happens
Protect downstream systems from bursts.
Rate limits
Cap requests per second on any queue or lane.
Parallelism
Bound concurrent in-flight deliveries per destination.
Live lane updates
Tune limits at runtime without redeploying anything.
Per-key isolation
One noisy tenant never starves the rest.
bursts absorbed — downstream protected
#04 — Priority
Urgent work moves first
Priority 0-9 scheduling keeps critical jobs ahead of bulk traffic.
10 priority levels
Assign 0-9 per job. Lower numbers dispatch first.
Starvation-free
Bulk traffic still progresses while urgent work leads.
Per-job override
Set priority at enqueue time, not at queue creation.
- p0payment.capture
- p2order.confirmed
- p5email.welcome
- p9analytics.batch
- p0 dispatched first — always
#05 — Reliability
Failures are expected
Automatic retries and recovery.
Exponential backoff
Retries spread out automatically to let systems recover.
Dead letter queues
Exhausted jobs are captured for inspection and replay.
Circuit breakers
Failing destinations are paused before they cascade.
Idempotency
Safe redelivery without double-processing side effects.
- +0sattempt 1503
- +2sattempt 2503
- +8sattempt 3timeout
- +32sattempt 4200 OK
- exhausted retries route to dead letter queue
#06 — Delivery
Every webhook is verifiable
Signed deliveries with timestamp validation and HMAC verification.
HMAC signatures
Every payload is signed with your endpoint secret.
Timestamp validation
Replay attacks rejected outside the tolerance window.
Key rotation
Rotate secrets with zero delivery downtime.
BetterMQ-Timestamp: 1717189200
BetterMQ-Signature: v1=9f2ab8…e41c
// verify on your server
const expected = hmacSHA256(
secret,
`${timestamp}.${rawBody}`
)
✓ signature valid — within tolerance#07 — Operations
Everything operators need
Control Panel
Inspect queues, jobs and deliveries from a built-in UI.
Metrics
Prometheus endpoint with broker and queue metrics.
Health Checks
Liveness and readiness probes for orchestrators.
OpenAPI
Complete spec for every endpoint, ready for codegen.
Scalar Docs
Interactive API reference served by the broker itself.
HA Cluster
Raft-backed replication for zero-downtime operation.
Developer Experience
Just HTTP
No client lifecycle. No worker runtime. No protocol lock-in.
POST /v1/enqueue
Authorization: Bearer $TOKEN
Content-Type: application/json
{
"queue": "jobs",
"key": "user-42",
"body": { "task": "send_invoice", "invoice_id": 99 },
"priority": 8,
"sign": true
}
# → 202 { "message_id": "…", "queue": "jobs", … }Architecture
A modern broker built from proven components
Battle-tested storage engines, consensus-backed clustering and a delivery core designed for failure — packaged in a single deployable binary.
1
Binary
0
Per-message fees
100%
Infrastructure ownership
∞
Scale potential
API Layer
Broker Core
Storage
Cluster
Comparison
How betterMQ compares
| Feature | betterMQ | QStash | Hookdeck | Svix | Kafka |
|---|---|---|---|---|---|
| Self-hosted | Yes | No | No | Partial | Yes |
| HTTP-native API | Yes | Yes | Yes | Yes | No |
| Cron & interval scheduling | Yes | Yes | No | No | No |
| Priority queues (0-9) | Yes | No | No | No | No |
| Fan-out groups | Yes | Yes | Yes | Yes | Yes |
| Flow control & rate limits | Yes | Yes | Yes | Partial | Partial |
| Signed webhook delivery | Yes | Yes | Yes | Yes | No |
| Dead letter queues | Yes | Yes | Yes | Yes | Partial |
| No per-message fees | Yes | No | No | No | Yes |
| Single binary deploy | Yes | No | No | No | No |
SupportedPartial / limitedNot available
Competitor capabilities reflect publicly documented behavior and may change.
Installation
Running in under a minute
One binary. No external dependencies. Your first durable job delivered before your coffee cools.
macOS · Linux
curl -fsSL https://bettermq.com/install | bashWindows, Docker Compose and source builds — all install options →
- 1Run the install command
- 2Create token
- 3Send first job
- 4Configure scheduling
- 5Monitor deliveries
$ curl -fsSL https://bettermq.com/install | bash
✓ betterMQ installed — running at http://localhost:8080
$ curl -X POST http://localhost:8080/v1/enqueue \
-H "Authorization: Bearer sk_local_…" \
-H "Content-Type: application/json" \
-d '{
"queue": "jobs",
"key": "user-42",
"body": { "task": "send_invoice" },
"sign": true
}'
✓ 202 Accepted — delivery in progressFAQ
Frequently asked questions
How is betterMQ different from Kafka or RabbitMQ?
betterMQ is HTTP-native: producers enqueue with a POST request and consumers receive signed webhooks. There is no client library, consumer group protocol or broker-specific wire format. It also bundles scheduling, retries, rate limiting and priority — features that traditionally require extra services around a raw broker.
Do I need to run workers or consumers?
No. betterMQ pushes jobs to your HTTP endpoints. Your existing web servers are your workers — any service that can receive an HTTP request can process jobs.
What happens when my endpoint is down?
Deliveries retry automatically with exponential backoff. If a destination keeps failing, the circuit breaker pauses it, and jobs that exhaust their retries land in a dead letter queue where they can be inspected and replayed.
Is it really a single binary?
Yes. The API, scheduler, delivery engine, storage (RocksDB/SlateDB) and control panel ship in one binary or Docker image. For high availability you run multiple nodes clustered with Raft.
How do I verify webhook authenticity?
Every delivery carries an HMAC-SHA256 signature and timestamp header. Verify the signature against your endpoint secret and reject requests outside the timestamp tolerance window.
What does it cost?
betterMQ is self-hosted with no per-message fees. You pay only for the infrastructure you run it on, and your data never leaves your network.
Build reliable delivery infrastructure in minutes
Deploy BetterMQ and start running durable jobs, schedules and webhook workflows on infrastructure you control.