Case Study
Telegram Automation Systems
Production Telegram Automation
Built and deployed three independent Telegram automation systems for international customer communication and lead management. Python automation with Telethon, python-telegram-bot, SQLite persistence, and Linux VPS infrastructure with systemd.
The Challenge
I partnered with an international client to design, build, deploy, and maintain three independent Telegram automation systems used for customer communication and lead management. The project required production-ready software that could run 24/7 on Linux VPS infrastructure, recover from failures, and be easily managed remotely. The three systems were: a Telegram Menu Bot for interactive navigation and subscriber management, a Paidcations Auto-Reply Userbot for automated customer conversations, and a Client Auto-Reply Userbot for a second client account.
Technical Challenges
- ✓Telegram session management — Telegram invalidated sessions after use from multiple IP addresses, causing continuous crashes and systemd restart loops during deployment.
- ✓Production stability — services needed to run 24/7 on VPS infrastructure, recover from crashes, and avoid infinite restart loops after authentication failures.
- ✓Reliable authentication flow — deployment authentication needed to be separated from normal runtime so reauthorizing did not require rebuilding or restarting the application.
- ✓Multi-system isolation — three independent Telegram systems with separate credentials, databases, VPS environments, and session files.
- ✓Production debugging — extensive live debugging including Telethon session validation, Linux process inspection, systemd journal analysis, and network diagnostics.
Architecture & Evolution
The project covers three distinct Telegram automation systems, each with its own architecture:
System 1 — Telegram Menu Bot: Built with python-telegram-bot (Bot API), this system provides interactive inline keyboard menus with multi-level navigation, user registration and tracking, admin-only broadcast controls, rich media support with URL buttons, subscriber management, and SQLite persistence. Configured via environment variables with production logging.
System 2 — Paidcations Auto-Reply Userbot: Built with Telethon (MTProto), this runs as a real Telegram user account rather than a bot. It provides automatic private message replies, multi-message conversation flows, cooldown management, follow-up automation, an ignore system, human takeover detection, and owner commands.
System 3 — Client Auto-Reply Userbot: A second production deployment using the same Telethon architecture for another client account, with independent VPS deployment, environment isolation, separate Telegram credentials, and session authorization.
A critical production challenge emerged during deployment: Telegram invalidated the session after it had been used from multiple IP addresses. This caused continuous crashes, endless systemd restart loops, and failed deployments. Instead of repeatedly recreating sessions manually, I redesigned the authentication architecture.
The Solution
Architected three independent Telegram automation systems with a shared production architecture. The Telegram Menu Bot uses python-telegram-bot with interactive inline keyboard menus and SQLite persistence. Both auto-reply userbots use Telethon (MTProto) for real Telegram account automation. The key architectural innovation was separating deployment authentication from runtime: an interactive authorization mode (--authorize flag) with pre-startup validation, session integrity checks, automatic invalid-session detection, safe process exit, and systemd restart prevention using Exit Code 75 (EX_TEMPFAIL). This transformed the bot into a recoverable production service.
Tech Stack
Key Features
Screenshots
Deployment
Each system deployed independently on Ubuntu VPS:
— Python virtual environments for dependency isolation
— Systemd services configured for automatic startup on reboot
— Production monitoring with live journal analysis
— Separate credentials, databases, and session files per system
— SSH administration for remote maintenance
— Authorization validation pipeline that prevents runtime crashes
Lessons Learned
- →Separating deployment authentication from normal runtime transformed a fragile service into a recoverable production system.
- →Exit Code 75 (EX_TEMPFAIL) prevented systemd restart loops during authentication failures while preserving restart behavior for real crashes.
- →Production debugging on Linux VPS requires systematic isolation — Telethon sessions, systemd journal, and network diagnostics each tell a different part of the story.
- →Three independent deployments with shared architecture patterns reduced maintenance overhead while preserving isolation.
- →Building both Bot API and MTProto solutions required understanding two fundamentally different Telegram integration approaches.
Outcome
Successfully delivered three production Telegram automation systems:
- Telegram Menu Bot with interactive navigation and subscriber management - Paidcations Auto-Reply Userbot for automated customer conversations - Client Auto-Reply Userbot as a second independent production deployment
The completed solution enabled the client to: - Automate repetitive customer conversations across multiple Telegram accounts - Reduce manual response time for customer inquiries - Manage subscribers and broadcast updates efficiently - Run Telegram automation continuously on VPS infrastructure - Recover from authentication issues without rebuilding the application - Operate multiple Telegram automation systems independently
Services used in this project
Other Case Studies
Read the Blog
Technical articles on SaaS development, MVP strategy, mobile apps, and SEO — written while building real products.
Visit the blog →Like what you see?
I am available for freelance work. Tell me about your project and I will get back to you within 4 hours with an honest assessment.