04 / PLATFORMS & WORKFLOWS
BotForge
Shared bot infrastructure without mixing each bot’s users.
Two bots run concurrently with per-bot user registration and language preferences.
01 / CONTEXT
The problem.
Running several bots independently duplicates infrastructure. Sharing a backend introduces a different problem: user preferences and activity must remain attached to the correct bot.
02 / IMPLEMENTATION
The approach.
A dedicated polling worker runs two aiogram bots. FastAPI exposes read-only admin endpoints, PostgreSQL stores per-bot state and a React dashboard shows the API’s operational data.
Simplified flow. Implementation details and boundaries are documented in the repository.
03 / TRADEOFFS
Decisions that matter.
Separate execution from administration
The bot worker handles polling; the API serves health and admin views. A bot failure can retry independently without putting polling inside web requests.
Model the bot as part of identity
Registration and language preferences are stored per user, per bot. English and Arabic handlers share the same backend implementation.
Make local operations reproducible
Docker Compose runs the database, API, worker and dashboard. Alembic applies schema migrations; admin requests require an API key.
04 / EVIDENCE & BOUNDARIES
What was checked.
- Backend pytest checks and frontend TypeScript build
- Docker build verification
- Documented two-bot registration and language scenarios
- Admin key rejection and API health checks
Checks summarized from the project documentation. See the repository and CI for current details.
Scope of this reference project
Public local proof of concept, not a hosted multi-tenant SaaS. Requires two Telegram bot tokens for polling. The admin API key is a local administration mechanism, not a production identity system.
Run it locally
Follow the repository README for prerequisites and configuration before running:
docker compose up --build -dWORKING ON A SIMILAR PROBLEM?