# Telemt: an MTProxy for Telegram written in Rust and Tokio

> Telemt is a Rust server that implements the official Telegram MTProto proxy modes, adds TLS fronting and a middle-end pool, and ships a one-command installer plus Docker images. It fits operators who already run a proxy and want a configurable replacement, not people looking for a hosted service.

**telemt/telemt** — MTProxy for Telegram on Rust + Tokio

- Repository: https://github.com/telemt/telemt
- Stars: 5,709 · Forks: 269
- Language: Rust
- License: NOASSERTION
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/telemt-telemt

## What Telemt solves, and who it is actually for

Telegram clients reach the network through proxies that speak MTProto, and the official proxy implements several distinct modes. Telemt is a server, written in Rust on top of Tokio, that implements that proxy algorithm and adds what the README calls production-ready improvements. The audience is narrow and technical: someone who can rent a host, open a port, edit a TOML file and read logs. It is not a consumer app, and the repository gives no indication of a hosted or managed offering.

The modes matter because they change what an observer sees. Classic mode is the plain proxy. Secure mode uses a dd prefix. Fake TLS uses an ee prefix with SNI fronting, so the connection resembles TLS to a named host. The README also lists replay attack protection, optional traffic masking that forwards unrecognized connections to a real web server, configurable keepalives and timeouts, IPv6, a Fast Mode, graceful shutdown on Ctrl+C, and logging controlled through RUST_LOG. Those are operator-facing features, which tells you the intended user runs this on a server rather than a laptop.

## The mechanism: TLS fronting, the middle-end pool and what the README claims

Two design choices stand out. The first is TLS fronting. The README describes the implementation as almost behaviorally consistent with real TLS and points to a FAQ section for validation traces, under the heading recognizability for DPI and crawler. That is the project's own claim about its own work, and the evidence lives in docs/FAQ.en.md rather than in the README itself. Treat it as a pointer to read, not as an independent result.

The second is the middle-end pool. The README says it is fastest by design in standard scenarios compared to other implementations of connecting to the middle-end proxy, and immediately qualifies that with non dramatically, but usual. That sentence is worth reading twice. It is a modest claim about a pool of upstream connections, not a benchmark table, and no numbers appear in the README. The architecture document under docs/Architecture is where the connection handling is described.

The dependency list in Cargo.toml corroborates the shape of the thing: tokio and tokio-util for the runtime, aes, ctr, cbc, sha1, sha2, md-5 and hmac for the MTProto crypto, socket2 and nix for low-level networking, rustls through reqwest, and an ml-kem dependency. The presence of ml-kem is not explained in the README, so what role post-quantum key encapsulation plays here is something you would have to confirm in the source or the architecture docs.

## Installing Telemt and getting a first proxy running

The README offers a one-command install and update path. It pipes a script from the repository's main branch into sh, which means you are executing whatever that branch contains at the moment you run it. That is convenient and also the reason to read install.sh before running it.

```bash
curl -fsSL https://raw.githubusercontent.com/telemt/telemt/main/install.sh | sh
```

The README also documents building from source. Note the release profile uses lto = "fat", and the README warns that on systems with around 1 GB of RAM you can override it to "thin". The final command starts the server with a config file as its argument.

```bash
git clone https://github.com/telemt/telemt
cd telemt
cargo build --release
mv ./target/release/telemt /bin
chmod +x /bin/telemt
telemt config.toml
```

If you prefer containers, the repository ships a docker-compose.yml that pulls ghcr.io/telemt/telemt:latest, maps port 443, binds the API ports 9090 and 9091 to localhost only, mounts ./config into /etc/telemt, and runs with a read-only root filesystem, all capabilities dropped except NET_BIND_SERVICE, and a healthcheck that calls telemt healthcheck with --mode liveness.

```bash
docker compose up -d
```

The compose file's comments explain one detail that is easy to miss: the config is mounted as a directory rather than a single file so the API can update config.toml atomically by writing a temporary file and renaming it within the same filesystem. The working directory is a tmpfs mount at /run/telemt, described as a cache for proxy-secret at runtime. The Quick Start guide under docs/Quick_start is where the README sends you for the actual first-run configuration, since the repository's config.toml is the starting point rather than a finished configuration.

## Where Telemt is the wrong tool, and what the README does not cover

The install script fetches from the main branch. If you need reproducible deployments tied to a tagged release, that path is not it, and you should use the Dockerfile's TELEMT_VERSION argument or build from a specific tag instead. The Dockerfile itself accepts TELEMT_REPOSITORY and TELEMT_VERSION and verifies a sha256 checksum of the downloaded tarball, which is a stronger supply-chain story than the shell one-liner.

Operationally, the README documents graceful shutdown on Ctrl+C but says nothing about rollback, config migration between versions, or what happens to active connections during an upgrade. Version numbers move quickly: 3.5.5 on 2026-08-27, 3.5.6 on 2026-09-06, 3.5.7 on 2026-09-08. Anyone pinning a version should expect to re-read docs/Config_params when they move, because the README does not promise config stability across releases.

There is also a scope mismatch worth naming. Telemt is a proxy server, not a way to obtain proxy access. If what you want is to connect a Telegram client through someone else's proxy, this project gives you nothing to install. And the README's note about drafting an MTProxy WEB Implementation using WebView and a datachannel describes work in progress, not a shipped feature.

## Telemt compared with the official MTProxy and with Shadowsocks

The obvious alternative is the official MTProxy that Telegram itself publishes. The difference is scope and language. The official proxy is the reference; Telemt reimplements the same protocol modes in Rust and layers on a middle-end pool, traffic masking to a real web server, configurable keepalives and timeouts, IPv6, and structured logging through tracing with RUST_LOG. If you want the smallest possible surface and no extra features, the official implementation is the more conservative choice. If you want a TOML-driven configuration and the additional modes exposed as options, Telemt is the one that offers them.

A second comparison point is Shadowsocks, and it is not a like-for-like one. Cargo.toml pulls in the shadowsocks crate with the aead-cipher and aead-cipher-2022 features, so the protocol appears somewhere in the dependency graph, but the README never presents Telemt as a general-purpose SOCKS or Shadowsocks server. The repository topics list socks5 and tls, which suggests related surface area, yet the README's feature list is entirely about MTProto proxy modes. If your requirement is a general encrypted tunnel for arbitrary TCP traffic, an MTProxy is the wrong category of tool regardless of which implementation you pick.

## Licence, maintenance and what upgrading costs you

The repository's licence field reports NOASSERTION, which means the platform could not classify it automatically. The repository contains both LICENSE and LICENSING.md, so the terms are stated in the project's own files and those are what you have to read. Nothing here is legal advice; the practical point is that you cannot assume a standard permissive licence from the metadata, and if you plan to redistribute Telemt or ship it inside a product, the answer is in those two files.

Maintenance is visible rather than declared. The repository is not archived, and the last push was on 2026-09-13, with releases 3.5.5, 3.5.6 and 3.5.7 landing within a two-week window in August and September 2026. That is a fast cadence, and it cuts both ways. You get fixes quickly, and you also get a moving target. The README mentions a Russian translation, a Quick Start guide in two languages, an OpenBSD quick start, an architecture document and a config parameter reference, so the documentation surface exists. What it does not contain is a stated support window or a compatibility promise for config.toml between minor versions.

## Conclusion

Adopt Telemt if you already operate an MTProxy and want the full set of official modes plus configurable keepalives and masking behind a single TOML file. Do not adopt it if you need a hosted service, a web dashboard, or a documented rollback path, because the README describes none of those. Before committing, read docs/Config_params to confirm every key you intend to set exists, and check LICENSE and LICENSING.md to see which terms apply to your distribution.

## FAQ

### What is Telemt?

Telemt is an MTProxy server for Telegram written in Rust and built on Tokio. According to the README it implements the official Telegram proxy algorithm in classic, secure (dd prefix) and fake TLS (ee prefix with SNI fronting) modes, and adds features such as replay attack protection, traffic masking and configurable timeouts.

### How do I install Telemt?

The README gives a one-command install that pipes install.sh from the main branch into sh, and it also documents cloning the repository and running cargo build --release before starting the binary with a config file. The repository additionally provides a docker-compose.yml that pulls ghcr.io/telemt/telemt:latest.

### How does Telemt compare with the official MTProxy?

Telemt reimplements the same protocol modes as the official Telegram proxy and adds a middle-end pool, traffic masking to a real web server, IPv6 support and logging through RUST_LOG. The README describes its middle-end pool as fastest by design in standard scenarios but qualifies that as non dramatically, so no measured comparison is published there.

## Sources

- [Issues](https://github.com/telemt/telemt/issues)
- [README](https://github.com/telemt/telemt/blob/main/README.md)
- [Releases](https://github.com/telemt/telemt/releases)
- [telemt/telemt on GitHub](https://github.com/telemt/telemt)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/telemt-telemt