Developer ships water-tracking Telegram bot on Cloudflare Workers and Durable Objects
A developer has shipped Drinky, a Telegram bot for tracking water intake, using Cloudflare Workers, Durable Objects, and the grammY framework. The open-source project offers a practical look at serverless bot architecture - though the "free forever" hosting claims deserve scrutiny.
The Stack
The bot uses Cloudflare Workers for serverless execution, Durable Objects for per-user state persistence, and grammY (a TypeScript Telegram bot framework with 5K+ GitHub stars) for API interaction. The developer chose this over web apps or mobile development for lower friction - users just message the bot.
The Durable Objects choice is notable. Unlike Cloudflare's D1 database (which the developer abandoned due to cold start times), Durable Objects provide near-zero latency for state operations. Each user gets their own isolated storage. For a personal project, this works. For enterprise bot deployments handling thousands of concurrent users, the pricing model shifts considerably beyond Cloudflare's 10M daily request free tier.
Implementation Details
The developer hit standard serverless gotchas: webhook configuration required explicit setup via Telegram's API, and the stateless environment needed bot.handleUpdate() calls to process messages. Commands can be registered dynamically via API rather than through BotFather - useful for teams managing bot fleets.
The project avoided unnecessary AI: timezone detection uses lat/long from Telegram's location API rather than LLM inference. Smart trade-off.
What This Means
Telegram's 950M+ monthly active users and 10M+ active bots make it a viable channel for enterprise notifications and internal tooling. This stack - Workers, Durable Objects, grammY - handles conversational state without managing infrastructure.
The real question for enterprise teams: Does your use case justify Durable Objects' per-GB storage and request costs? For simple notification bots, Workers alone suffice. For complex state management (think customer service bots, approval workflows), the Durable Objects model makes sense - but budget accordingly. The "free tier" messaging from tutorials doesn't reflect production costs at scale.
Worth noting: grammY's active maintenance matters. The developer rejected Telegraf for being unmaintained - a reminder that framework choices affect long-term support costs.