Telegram Q&A Bot — Whitelisted Knowledge Base with Admin Dashboard

Background

People already spend a huge share of their phone time inside messaging apps. So when a group needs a convenient, secure way to get answers or do a small piece of work, the best interface is often the one they’ve already got open — not one more app to install and learn. Telegram already handles auth (a phone number), delivery, and notifications; building on top of it means the “app” is something people already trust and use every day.

That’s the idea behind this bot: a small Telegram bot that answers repeated questions for a whitelisted group straight from a shared knowledge base, with no new app, login, or interface to learn.

What I built

A Telegram bot (aiogram 3) plus a lightweight web admin panel, running as one process:

Q&A matching — incoming messages are matched against a stored knowledge base and answered automatically when a close-enough match is found.
User whitelist — only approved Telegram users can interact with the bot, keeping it a closed tool rather than an open one anyone could message.
FastAPI admin dashboard — mounted in the same process as the bot’s polling loop, rendered server-side with Jinja2, and protected by HTTP Basic Auth.
Knowledge base editor — questions and answers can be added, edited, and deleted straight from the dashboard, so updating what the bot knows never needs a redeploy.
Usage stats — a small chart shows messages answered and unique users over the last 7 days, so I can tell at a glance whether the bot is actually being used.

Outcome

The bot is live and answering questions for its whitelisted group. In its first week it handled 19 replies across 3 unique users — enough to confirm the core loop (match question, answer, log it) works end-to-end, and that the admin dashboard is a genuinely faster way to update the knowledge base than editing rows by hand.

Stack rationale

aiogram 3 handles the Telegram polling loop and update dispatch — an async-first framework that fit naturally with running the bot and the admin server in the same process.

FastAPI mounted in the same app as the bot, started alongside its polling task in the app lifespan, rather than a separate service. The admin dashboard doesn’t query the database directly — it goes through the same SQLAlchemy repo layer (app/repo.py) the bot itself uses, so there’s exactly one code path into the data, not two that can drift apart.

SQLAlchemy over SQLite. A single embedded database file is nothing to manage for a group this size, and SQLAlchemy keeps both the bot and the dashboard talking to it through the same models.

Jinja2 renders the admin UI server-side — no separate frontend build for a page that’s really just a couple of tables and a chart.

HTTP Basic Auth, deliberately minimal: one hardcoded username, a password from ADMIN_PASSWORD in .env, no real session. “Logout” is faked by returning a 401 with a different WWW-Authenticate realm, which makes the browser drop its cached credentials. The login path itself is rate-limited and the admin panel is only reachable from an IP allowlist, so the minimal auth isn’t the only thing standing between the dashboard and the internet. Good enough for a single-admin private tool — not something I’d reach for if this ever needed real multi-user auth.

Docker, self-hosted. Consistent with keeping this cheap and simple rather than reaching for a managed platform for a tool with a handful of users.