The Build Blog
X-Manager v0.2.0: building a self-hosted X command center for humans and agents
X-Manager started because I was tired of paying social SaaS to hold my data, limit my automation, and treat bots like an awkward extra instead of a first-class use case. I wanted something local-first, inspectable, and usable from both a dashboard and an API.
It is now a self-hosted X command center with three connected account slots, scheduling, threads, replies, likes, reposts, drafts, analytics, and a secure bridge for external agents. The bigger story, though, is not the feature list. It is the hardening work that made it safe to trust for real output.
One control plane for posting, scheduling, and agent-driven publishing
At the simplest level, X-Manager lets me connect X accounts, schedule posts, build threads, import CSVs, and manage publishing from one place. That is the useful baseline.
The part that makes it different is the agent layer. The app exposes a machine-readable manifest, slot-aware APIs, and a secure bridge so other tools can publish through it without inventing their own ad-hoc auth, queueing, and account routing. It is meant to be a local social operations backend, not just a prettier compose box.
I wanted self-hosted control instead of another subscription.
Local custody of credentials
X keys, account tokens, scheduling state, and uploads stay under my control. That matters more when agents are involved, because the blast radius of a bad integration gets larger fast.
Humans and agents both matter
Most tools pick one side. Either the UI is nice and the API is weak, or the API exists and the operator experience is miserable. I wanted one system that does both competently.
Low-friction infrastructure
SQLite, Next.js, and local services are enough for this problem. The goal was not to engineer a platform for a venture deck. The goal was to ship something practical that runs on a cheap VPS.
It started as a scheduler idea and turned into a real operations tool.
The early shape was straightforward: connect an account, queue some posts, and have them publish on time. That alone is already useful when you want control without paying for another SaaS dashboard.
Then the obvious adjacent needs showed up. Threads need to chain properly. CSV import matters if you are planning content in batches. Drafts matter if people are iterating. Analytics matter if you want to know whether this is worth running. And once agents start interacting with it, a bridge API, clear auth, approvals, and auditability stop being optional.
By that point X-Manager was no longer just “a scheduler.” It was a local command center with an opinionated workflow: one place to hold accounts, queue work, expose safe APIs, and keep enough operational visibility that you can trust it in the background.
The hardening pass was the real release.
Scheduler reliability
I audited the live scheduler, found overlapping-cycle risk and stale queue behavior, then fixed it with serialized loops, explicit posting claims, stale-claim recovery, and safer readiness checks.
Third slot support
The app now supports three connected X accounts instead of two, and I proved live posting from the new slot rather than assuming the shared auth model would behave correctly.
Slot-aware audit logs
Fresh X API logs now preserve the actual slot context for replies, likes, reposts, and bridge writes. That sounds boring until you are trying to debug which account actually did what.
Bridge cleanup
The OpenClaw bridge now works cleanly against slots 1 through 3, with auth enforced and route-level behavior aligned with the live service instead of an optimistic config story.
Service durability
I moved the running instance onto a cleaner systemd user service path so it survives better across restarts and reboots instead of relying on a half-remembered dev shell.
Queue hygiene
The overdue queue was backed up, exported, and neutralized safely instead of letting a restart flush old scheduled work unexpectedly. That is the kind of operational detail that matters once software touches real accounts.
What the current release actually gives you
- Three connected X account slots from one dashboard
- Scheduled posts, replies, media, CSV import, and thread support
- Live-proven posting, replying, liking, reposting, and bridge publishing
- Safer scheduler execution with claim-based posting and stale recovery
- Real readiness checks backed by scheduler health and queue counts
- Slot-aware X API audit logs for current writes
- systemd user service support for cleaner local or VPS operation
- Secure bridge auth with slot allowlists and optional HMAC signing
What is still not done
The main remaining gap is DM automation. The app has DM plumbing, but the live instance currently hits X access limits on the legacy DM endpoint, and the modern OAuth2 PKCE plus v2 DM path still needs implementing before I would present DMs as production-ready.
That matters to me because I would rather ship a tool that is explicit about what is proven than pretend every box is green because the UI looks complete. Posting and agent publishing are in good shape. DMs are the next real piece of work.
Project, repo, and next steps
X-Manager project page
The higher-level overview: what it is, how it works, and why it exists.
GitHub repo
Read the code, run it yourself, or follow future changes directly.
@getboski on X
I post build notes, release updates, and whatever ships next.
The Build Blog
More release write-ups, architecture notes, and product updates from other TylerBuilds projects.
Why this project matters to me
X-Manager is exactly the kind of tool I like building: local-first, a bit opinionated, useful on day one, and improved by real operational pressure rather than abstract feature planning. It solves a problem I actually have, which is why it kept getting better.