Telethon and Pyrogram hosting, for bots first
Both libraries talk to Telegram over MTProto rather than the Bot API, and both can sign in as a bot or as a person. What this platform is built for is the bot: a token from BotFather, your own api_id and api_hash, and the session kept on disk so a restart does not log in again.
A Telethon bot that deploys as is
import os
from telethon import TelegramClient, events
client = TelegramClient(
"/data/bot",
int(os.environ["TG_API_ID"]),
os.environ["TG_API_HASH"],
)
@client.on(events.NewMessage(pattern="/start"))
async def start(event):
await event.respond("Hello from FadeHost")
client.start(bot_token=os.environ["BOT_TOKEN"])
client.run_until_disconnected()The first argument is the session name, and pointing it at /data is the part people miss: /data survives redeploys, the rest of the filesystem is rebuilt from the repository, so a session written elsewhere is gone on the next deploy and the client authenticates from scratch.
The same thing in Pyrogram
import os
from pyrogram import Client, filters
app = Client(
"bot",
api_id=int(os.environ["TG_API_ID"]),
api_hash=os.environ["TG_API_HASH"],
bot_token=os.environ["BOT_TOKEN"],
workdir="/data",
)
@app.on_message(filters.command("start"))
async def start(client, message):
await message.reply("Hello from FadeHost")
app.run()workdir="/data" does for Pyrogram what the session path does for Telethon. api_id and api_hash come from my.telegram.org and belong in environment variables with the token.
Why these libraries at all
MTProto gives a bot things the Bot API does not: reading older history in a chat it is in, larger file transfers, and some administrative calls. That is the honest reason to pick Telethon or Pyrogram. If none of it applies, aiogram or python-telegram-bot on the Bot API is simpler to deploy and easier to debug, and both have pages of their own.
User sessions: what the terms actually say
These are the libraries people use to sign in as a person, so here is the line. A Telegram user session for your own account is allowed. Using one to add people to groups or channels in bulk, scrape members, or message people who did not ask is not, and neither is automating somebody else's account with their login. That is in our terms, and Telegram enforces it on the account, which is yours. If the job is a bot, give it a bot token: it is what the platform is set up for, and it cannot be banned for being a person.
Frequently asked questions
Can I host a userbot or a self-bot?
A user session for your own account is allowed, and it is your account that carries the risk. Self-bots that act for other people, bulk group adding, member scraping and messaging people who did not ask are not allowed under our terms. A bot token is the supported path and the one these pages are about.
Where do api_id and api_hash come from?
From my.telegram.org, on your own Telegram account. They identify the application, not the bot, and they go in environment variables alongside the BotFather token.
Why does my bot log in again on every deploy?
The session file is outside /data. Point the session path or workdir at /data, which is the only directory kept across deploys, and the client resumes instead of authenticating.
Is the Bot API or MTProto better here?
Both run identically well. MTProto is worth it for history, large files and some admin calls; otherwise the Bot API libraries are less to reason about.
Where does the token go?
In the environment variables of the app, as BOT_TOKEN or whatever name your code reads, never in the repository. The panel masks the values and injects them when the bot starts.
What does the free tier include?
One bot with 256 MB of RAM, always on, placed where there is room for it (a paid plan picks the region), with the live console, environment variables and redeploys on push. A second bot or more memory is the Starter plan at $2 a month.