Architecture
How a post moves from a config to a published tweet, and the processes that make it happen.
Pegacraft is a NestJS backend (Postgres + Redis/BullMQ) and a Next.js frontend, run as three backend entry points from one codebase: the HTTP API, a BullMQ worker, and an elizaOS-based "engine" worker that owns metrics ingestion. There is no official-API integration for X: posting happens by replaying a saved browser session through headless Playwright, a deliberate cost trade-off covered in the publishing model.
The pipeline, end to end
The three processes
src/main.ts: the HTTP API. Every request runs behindJwtAuthGuard, which also seeds tenant context for the request.src/worker.ts: a headless BullMQ worker (concurrency: 1) consuming thegeneration,publish,competitor-scrape, andmention-scrapequeues.src/engine-worker.ts: a separate headless process embedding elizaOS as the metrics and topic-performance substrate. It owns themetricsqueue and is the only process that reads or writes elizaOS's own database.
Where to go next
- Multi-tenancy: the Postgres RLS model every table in this system is built on.
- The publishing model: why posting is browser automation, not an API integration, and what that costs in risk.
- Content generation: the actual draft-to-dedup-to-approval pipeline.
- Data model: the Prisma schema's key tables.
- API overview: REST endpoints by module.