redisthon
Telethon session storage in Redis or Dragonfly, for Telegram bots and userbots
that run in containers or move between hosts, where a local .session file is
inconvenient.
Install
Install from GitHub until the first PyPI release:
pip install git+https://github.com/AI-Stratov/redisthon
Usage
import asyncio
from telethon import TelegramClient
from redisthon import RedisSession
API_ID = 12345 # from https://my.telegram.org
API_HASH = '0123456789abcdef0123456789abcdef'
async def main() -> None:
session = RedisSession('my_account', host='localhost', port=6379)
async with TelegramClient(session, API_ID, API_HASH) as client:
me = await client.get_me()
print(me.username)
asyncio.run(main())
The first run asks for a phone number and login code. Later runs, on this or any other host that can reach the same Redis, reuse the stored session.
Other RedisSession options: db, username, password, key_prefix
(default redisthon:session), ttl_seconds (default 30 days, 0 disables
expiry), save_entities (default True), is_dragonfly, and pool settings
(max_connections, connection_timeout, socket_keepalive).
To share one connection pool between sessions, create a RedisClient and pass
it as redis_client=. Sessions do not close a client they were given.
Features
- Auth key, data center and takeout ID are stored on every
save()and loaded when the session is created. - Entity cache: users and chats Telethon sees are stored, and
get_input_entity()resolves them by ID, username, phone or name. - Update states (pts, qts, seq, date) are stored per entity.
- Sent-file cache for photos and documents.
- Every key gets
ttl_seconds. Eachsave()refreshes the TTL of all four keys, so an active session keeps its caches. delete(), whichclient.log_out()calls, removes all keys of the session.list_sessions()returns the names of all sessions under the key prefix.clone()returns an empty in-memory session, likeSQLiteSession.clone(). Telethon uses it for CDN connections, which therefore never touch Redis.- Dragonfly:
is_dragonfly=Trueonly skipsSELECT db. The integration tests run against both Redis and Dragonfly. get_health_info()(ping, server info, key names) andget_statistics()(cached entity, update state and file counts).- Type hints ship with the package (
py.typed) and passmypy --strict.
Keys for a session named name with the default prefix:
redisthon:session:name:data msgpack: auth key, DC, takeout ID
redisthon:session:name:entities hash: entity ID -> base64(msgpack)
redisthon:session:name:update_states hash: entity ID -> base64(msgpack)
redisthon:session:name:sent_files hash: <md5 hex>_<size>_<photo|document> -> base64(msgpack)
Limitations
- The Redis client is synchronous, because Telethon's session interface is. Every session call blocks the event loop for one Redis round trip.
- With the default TTL, a session that nobody starts for 30 days expires and the
account has to log in again. Set
ttl_seconds=0to keep it. - Lookups by username, phone or name scan the whole entity hash.
- Redis errors while reading or writing entities, update states and sent files
are logged and treated as a cache miss. Errors in
save()and in loading the session raiseSessionError. - Do not run two clients on one session at the same time. Telegram rejects the duplicated auth key.
- There is no
ssloption.
Compatibility
Tested in CI:
| Component | Versions |
|---|---|
| Python | 3.11, 3.12, 3.13, 3.14 |
| Telethon | 1.34.0 (lowest allowed), 1.45.0 (locked) |
| redis-py | 5.0.0 (lowest allowed), 8.1.0 (locked) |
| Redis | 6.2, 7.4, 8.10 |
| Dragonfly | 2.0 |
Development
Uses uv.
uv sync
uv run ruff check . && uv run ruff format --check .
uv run mypy redisthon
uv run pytest --cov=redisthon # unit tests, no server needed, 100% coverage required
Integration tests need Redis on REDIS_HOST:REDIS_PORT (default
localhost:6379). Dragonfly tests run when DRAGONFLY_PORT is set.
docker run -d -p 6379:6379 redis:8.10
docker run -d -p 6380:6379 --ulimit memlock=-1 docker.dragonflydb.io/dragonflydb/dragonfly:v2.0.2
DRAGONFLY_PORT=6380 uv run pytest tests/integration
License
MIT, see LICENSE.
Metadata
Release files for redisthon 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| redisthon-0.1.0.tar.gz | 82.9 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| redisthon-0.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 96.4 kB
Release files / redisthon-0.1.0.tar.gz
| Download URL | redisthon-0.1.0.tar.gz |
|---|---|
| Size | 82.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
9666eca060e6270cf5a378a8ef2f0181c85ae59db8a755e56d857f8531c2a378
|
|
BLAKE2b-256 checksum How to use checksums |
fdb2b964e6817c8fd977c27e1ffe660c1be262918fa22a7aaffff19f5f98394d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 12, 2026.
Transparency logRelease files / redisthon-0.1.0-py3-none-any.whl
| Download URL | redisthon-0.1.0-py3-none-any.whl |
|---|---|
| Size | 13.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
37167bb0b230170b2cb587182f92e075670b81ff74435f36ae86cdc109cdeab5
|
|
BLAKE2b-256 checksum How to use checksums |
d20e6765e573c4840ec8296447e680ed6c5f14dffec2a05994ed0405847c3480
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 12, 2026.
Transparency logSecurity for redisthon 0.1.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for redisthon-0.1.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 12, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.