Overview

Run Steerpost yourself, connect your accounts and let AI agents work with them through a scoped MCP server.

• Getting startedRun Steerpost locally with Docker, configure it, apply migrations and run the test suites.
• Providers & OAuthWhat LinkedIn and Telegram support, how to add a provider and how to set up OAuth and the Telegram bot.
• REST APIEndpoints, error format, post lifecycle and publishing idempotency of the Steerpost REST API.
• MCP serverThe Steerpost MCP tools, their scopes and risk levels, and how to configure Claude Code, Cursor, Claude Desktop and other clients.
• ArchitectureThe single source of truth: services, domain rules, database schema, REST contract, MCP tools, scheduler and OAuth flow.

Why Steerpost#

• Built for agents, with limits you set. Claude, Cursor and other MCP clients can draft and schedule posts. Each agent gets a scoped, revocable key, risky actions wait for your approval, and every call lands in the audit log.
• Yours to run. One make up starts the whole stack. Your accounts, tokens and posts stay in your own database, with tokens encrypted at rest and no third-party trackers.
• Honest about networks. Each network reports what it really supports. An unsupported feature fails with a clear reason; nothing is faked.
• A post goes out once, on time. Publishing is idempotent and retried only when that is safe. A crash leaves a post marked for review instead of posting it twice.

Features#

Publishing

• Write a post once, tailor the text per network and check live previews against each network's limits.
• Publish now or schedule it. See everything in a month, week or day calendar, in your timezone.
• Attach images and video from a media library (S3-compatible storage: the bundled MinIO, R2 or S3).
• Follow every post from draft to published, with the reason for each failure and a retry button.
• A dashboard of what is scheduled, what went out and what failed.

For AI agents

• An MCP server with 14 tools, over Streamable HTTP or stdio.
• Keys carry only the scopes you tick. Tools outside a key's scope are not even listed, and the API checks every call again.
• publish_post, delete_post and disconnect_account are off by default, and every call needs your approval in Steerpost before it runs, unless you mark the key as trusted.
• Every agent action is in the audit log, with an "Agent actions" filter.

Self-hosting

• Docker Compose for local use. For production: automatic HTTPS, deploys with automatic rollback, backups, pull-based updates from GitHub Releases, and a mode for servers that already run a reverse proxy.
• Multi-arch images (amd64, arm64) on GHCR.

Not there yet: a drag-and-drop calendar, a posting queue with time slots, threads, first comments, team workspaces with shared approvals, and OAuth for MCP clients. The analytics page exists, but no connected network reports metrics yet. The prioritised backlog is in PRODUCT.

Supported networks#

Derived from the tiers in PLATFORMS (checked 2026-10-09). Only ✅ networks work today; the rest are plans, in roughly this order, with no dates.

✅ publishes today · 🔜 planned, needs no platform review · 🔐 needs app review, verification or a paid API · ⛔ no official way to post. Setup for the live networks: LinkedIn, Telegram, Discord, Mastodon and Bluesky.

Architecture#

flowchart LR
  U[You, in the browser] --> FE[Web app<br/>Next.js]
  A[AI agent] -->|MCP + API key| MCP[MCP server<br/>TypeScript]
  FE -->|REST, session| API[REST API<br/>Go]
  MCP -->|REST, the agent's key| API
  W[Worker<br/>Go] --> CORE
  API --> CORE[Use cases]
  CORE --> AD[Network adapters<br/>LinkedIn · Telegram]
  CORE --> PG[(PostgreSQL)]
  CORE --> R[(Redis queue)]
  CORE --> S3[(S3 storage)]

• The MCP server holds no state and no network credentials. It calls the REST API with the agent's own key, so it can never bypass authorization.
• The Go backend is hexagonal: pure domain rules, use cases behind ports, and adapters for Postgres, Redis, S3 and each network. The API and the worker are two binaries of one module.
• The database is the source of truth for schedules; Redis only carries jobs, and a reconciler re-enqueues anything due.

The full contract (schema, REST API, MCP tools, scheduler and OAuth flow) is in ARCHITECTURE, the REST overview in API, and the reasons behind the choices in DECISIONS.