
Open-Dispatch
github.com/matthew-selvam/open-dispatch- Category
- Developer Tools
- Rank
- No. 1152Tools index
Previous survey · No. 1160 ·
- Pricing
- Open Source
- Platform
- web · cli · desktop
- Type
- TOOL
- Builder
- matthew-selvam
- GitHub
- 10 stars
- Latest release
- v0.4.0
- Date
About
Open-Dispatch is a self-hostable API and dashboard that dispatches a single content payload to seven social platforms — Twitter/X, Instagram, Telegram, Bluesky, LinkedIn, Threads, and YouTube Shorts — via one HTTP call. It offers a queue with retry/error visibility, an AI caption-adaptation endpoint, and an MCP server, positioning itself as a free MIT-licensed alternative to paid schedulers like Buffer or Hootsuite.
What it does
Open-Dispatch turns each publishing request into separate queued jobs, then routes them through platform-specific adapters. You can compose distinct text and media formats per network, schedule delivery, receive completion webhooks, inspect failures, and retry jobs through either the browser interface or automation clients.
Why it's ranked here
The project covers the operational middle ground between a posting script and a hosted scheduler. Multiple queue backends, per-account credentials, webhooks, health reporting, and several installation routes make it practical. Its strongest case is controlled distribution infrastructure, while unfinished analytics, inbox, and video-upload work narrow the replacement claim.
What's good
The queue can start as local JSONL storage, then move to Redis or Postgres without changing its public role. Requests support per-platform formats and named accounts. The CLI can enqueue through HTTP or directly, while the MCP layer exposes health, dispatch, queue inspection, retries, deletion, and caption adaptation.
Tradeoffs
Operators must obtain, store, and maintain credentials for every network. Named profile credentials are persisted as plaintext, so the data directory needs protection. Video transcoding is explicitly unfinished, bulk upload remains planned, and analytics plus inbox webhooks appear as future work. The default JSONL backend is described as single-process storage.
How to use it well
Use it for a self-managed publishing pipeline driven by scripts, cron, n8n, an AI agent, or its composer. Start with JSONL for one process, then select Redis or Postgres when workers multiply. Put authentication around team deployments and protect stored credentials. Keep a separate product for analytics, inbox management, and bulk video workflows.
Technical notes+
pyproject.toml requires Python 3.11+, uses setuptools, defines CLI, server, and worker entry points, and provides optional Redis, Postgres, MCP, and test dependencies. api/app.py implements FastAPI routes plus content-negotiated HTMX pages. api/queue.py defines a shared queue protocol with JSONL, Redis, and Postgres implementations; Postgres uses row locking with SKIP LOCKED. api/schema.py defines ContentUnit, target parsing, caption limits, and validation. cli.py supports HTTP dispatch, direct local enqueueing, queue listing, worker startup, and a Telegram connectivity check. profiles.py stores named credential sets in plaintext JSON and temporarily injects them into environment variables under a threading lock. mcp_server.py wraps the REST API with FastMCP tools over stdio or SSE. media/__init__.py states that image resizing exists while video transcoding remains future work.
Observed
- License
- MIT
- Primary language
- Python 3.11+
- Install surfaces
- Homebrew, shell installer, Docker Compose, direct Git installation with pip, and a macOS menubar app
- Interfaces
- FastAPI HTTP API, HTMX dashboard, command-line client, and MCP server with stdio or SSE transport
- Platform support
- Twitter/X, Instagram, Telegram, Bluesky, LinkedIn, Threads, and YouTube Shorts
- Queue backends
- JSONL, Redis, and Postgres
- Python packaging
- Setuptools package with optional Redis, Postgres, MCP, and test dependency groups
Read from README.md, pyproject.toml, requirements.txt, cli.py, docs/HANDOFF.md, docs/DEMO_SCRIPT.md, docs/migrating-from-zernio.md, profiles.py, mcp_server.py, api/app.py, api/queue.py, api/schema.py, ai/__init__.py, media/__init__.py.
What it can do
Dispatch a single content payload to multiple social platforms (Twitter/X, Instagram, Telegram, Bluesky, LinkedIn, Threads, YouTube Shorts) via one HTTP call
Content payload (via API call) → Posts published to seven social platforms
Adapt captions using AI via a dedicated endpoint
Caption text → Adapted caption text
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.