# MTProxyL puts the engine choice, the swap file and the rollback in one menu

> A shell-driven manager for a Rust Telegram MTProto proxy built on telemt, whose install prompt offers a swap file before anything else and whose binary backend keeps the previous engine version on disk so a rollback needs no network.

**Liafanx/MTProxyL** — Telegram Proxy менеджер на базе Telemt

- Repository: https://github.com/Liafanx/MTProxyL
- Stars: 357 · Forks: 13
- Language: Shell
- License: MIT
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/liafanx-mtproxyl

## Manager mode owns the engine, Reanimator mode repairs one

MTProxyL is a manager for Telegram MTProto proxies built on telemt, a Rust engine. In practice it does two distinct jobs, and the difference matters before you install anything.

Manager mode takes ownership of the engine: it installs it, keeps it updated, regenerates its configuration, and exposes secrets, limits, monitoring, backups and migration through a menu and a matching CLI. Reanimator mode is the other job, repairing an existing telemt installation that is already on the machine. The navigation lists both, and the Reanimator section is described as a mode with its own detection step.

That second job explains a naming decision that looks cosmetic at first. When the binary backend installs the engine, the systemd service is called `mtproxyl-telemt`, not `telemt`, so that the engine MTProxyL manages is never confused with an original telemt installation that Reanimator mode is meant to fix. Two engines on one host would otherwise collide on the same service name, the same port and the same config path.

The repository is a shell project with a small amount of structure around it: install.sh, mtproxyl.sh, lib/, engine/, mtproxyl-panel/, mtproxyl-tgbot/, templates_html/, tests/ and a version file.

## Docker or binary is decided in the wizard and switchable later

In Manager mode the engine can be kept in two ways, and the choice is made in the install wizard right after you pick the mode. Almost everything else in the product is identical between them: the menu, settings, secrets, panel, Telegram bot, Zapret2 and the limiter, Selfmask, backups and migration. Only what launches the engine changes.

The differences are operational rather than functional. The Docker image is the default: a container named `mtproxyl` on host networking, managed by Docker, configured from /opt/mtproxyl/mtproxy/config.toml, read through `docker logs mtproxyl`, limited with `--cpus` and `--memory`, and taking several minutes on a clean machine.

The binary backend installs /opt/mtproxyl/engine/mtproxyl-telemt, runs as the service `mtproxyl-telemt.service`, configures from /opt/mtproxyl/mtproxy/telemt.toml, logs through `journalctl -u mtproxyl-telemt`, maps the same CPU and memory limits to CPUQuota and MemoryMax, and installs in seconds. Docker is not installed at all in that path.

Switching later is a menu item or two commands:

```bash
mtproxyl engine backend binary    # из контейнера в бинарник
mtproxyl engine backend docker    # обратно
```

The port, secrets and settings survive the switch. The config is regenerated under the new filename and the previous carrier is removed, and moving to the binary offers to delete the engine images while leaving Docker itself installed.

## No image in GHCR means wrapping the release binary, not compiling

The Docker image is pulled ready-made from GHCR. What happens when it is not there is the interesting part, because the fallback is not what you would guess.

MTProxyL does not start a Rust compilation. It wraps the official musl binary from the release, verifying the sha256 checksum, and produces a `scratch` image with no shell and no package manager, about 7 MB, in seconds. A source build exists but is described as the last resort, and even then it runs a single Cargo task without LTO and without debug symbols to keep memory use down.

The project is explicit about the limit of that approach: the lightweight profile does not guarantee a successful build on any server with 2 GB of RAM. Free memory, the cgroup limit, swap and whatever else is running all matter. On a small VPS the recommendation is the prebuilt image or the official binary, and swap is not created automatically. Images built in GHCR, by contrast, do use LTO.

The binary backend follows the same checksum discipline. Architecture and libc are detected automatically across `x86_64`, `x86_64-v3` and `aarch64`, with `gnu` or `musl`, and the sha256 is verified against the release. The latest version is installed by default, but any version in the list can be chosen.

## The install is one wget pipe and it wants root

Installation is a single line that downloads the script, runs it as root and reloads your shell profile:

```bash
wget -qO /tmp/mtproxyl-install.sh https://raw.githubusercontent.com/Liafanx/MTProxyL/main/install.sh && sudo bash /tmp/mtproxyl-install.sh && source ~/.bashrc
```

MTProxyL runs as root. If you connect as an ordinary user, the installer writes an alias `mtproxyl` to `sudo mtproxyl` into /etc/profile.d/ and into your ~/.bashrc, which is why the trailing `source ~/.bashrc` in that command matters: it applies the alias immediately instead of waiting for a new login. Under root no alias is defined, because the command already works directly.

A setup wizard runs at the end of the install, and `mtproxyl` on its own reopens the menu later. The wizard asks which transport you want, MTProto only, WEB only, or both, and then configures the one you picked. The proxy link is printed when the install finishes, and `mtproxyl secret link` prints it again on demand. One port serves every client, iOS, Android and desktop, with no per-client configuration.

## The swap prompt comes first because an OOM kill looks like a hang

On a server with 1 GB of memory and no swap, the installer offers to create a 1 GB swap file, and the offer defaults to yes. The reasoning is specific: without it, Docker, the engine and especially the panel build all run into a memory shortage, the kernel kills the process, and the install appears to have frozen.

That failure mode is the reason the prompt is up front rather than buried. A silent installer that is actually being OOM-killed looks like a slow one, and the usual response, waiting, makes it worse. The swap file is manageable afterwards with `mtproxyl swap status|on|off`.

The same logic shows up in the Docker path, where CPU and memory limits are set in the container, and again in the compile path, where a single Cargo task without LTO keeps peak memory lower. The project's own position is that a small VPS should use the ready image or the official binary rather than compiling anything locally, and that swap is never created for you outside that first prompt.

## Zapret2 or NFT Smart is the first decision after root

The first thing the script offers on a fresh install, before the transport choice, is the Zapret2 MTProto fix, defaulting to yes. That is a server-side bypass built on TCP manipulations. Declining it leads to the second option, NFT Smart By-MEKO, which the project describes as the recommended mode and which separates iOS from Android handling.

Everything after that sits behind the same CLI. The navigation lists commands for proxy settings, secrets and users, general settings, the engine, expert mode, the NFT SYN limiter, the Zapret2 fix, the WEB proxy, Selfmask, the web panel, the Telegram bot, a PQ check, GeoIP, security, monitoring, backups and updates, migration to another server, system tasks, quick tune, and the Reanimator mode. Client speed limiting, IP address blocking and FakeTLS domain selection are documented as features in their own right.

The tree shows where those pieces live. engine/ holds the engine integration, mtproxyl-panel/ and mtproxyl-tgbot/ are separate components with their own release line, templates_html/ holds the panel templates, tests/ holds the test suite, and zapret2.md documents that integration outside the main README. The panel is versioned apart from the manager, with its own tag, which is a reminder that installing this does not give you a single artifact.

## The binary backend can roll back with the network unplugged

Updates and rollbacks are exposed the same way for both engines, by tag and by name:

```bash
mtproxyl engine update <tag>
mtproxyl engine rollback
```

What differs is where the previous version comes from. The binary backend keeps it alongside the current one as `mtproxyl-telemt.prev`, so a rollback needs no network at all. The Docker backend has no equivalent local copy, so rolling back there means fetching the previous image.

Licensing is MIT and the repository is not archived, with the last push landing on 2026-09-30, the same day as release v1.6.30 and the separately versioned panel tag. That cadence is quick enough that a server left unattended for a month is likely to be several versions behind.

Two documentation caveats. The README is in Russian, and the copy available here stops mid-sentence in the section on installing your own telemt build, which begins by asking for an https link to a binary or to a `.tar.gz` archive so you can run a patched engine that no release carries yet. Nothing after that point, including the migration, uninstall and requirements sections named in the navigation, is visible here, so those details have to come from the repository itself.

## Conclusion

Adopt MTProxyL if you want a self-hosted Telegram proxy with one menu covering the engine, the limits, the secrets and the backups, and if you can give it a server where you are willing to run it as root. Do not adopt it on a 2 GB VPS expecting a local source build to succeed, since the project says the opposite and points you at the prebuilt image or the official binary instead. Decide Docker or binary before your first install, and check that the Zapret2 or NFT Smart profile you pick is the one your clients need.

## FAQ

### How do I install MTProxyL on a server?

Run `wget -qO /tmp/mtproxyl-install.sh https://raw.githubusercontent.com/Liafanx/MTProxyL/main/install.sh && sudo bash /tmp/mtproxyl-install.sh && source ~/.bashrc`. A setup wizard starts at the end, and `mtproxyl` reopens the menu later. The tool runs as root, and for a normal user the installer adds a `mtproxyl` alias that already calls sudo.

### Does MTProxyL require Docker?

No. The Docker image is the default backend, but the binary backend installs /opt/mtproxyl/engine/mtproxyl-telemt as the service mtproxyl-telemt.service and needs no Docker at all. Switch between them with `mtproxyl engine backend binary` or `mtproxyl engine backend docker`, keeping the port, secrets and settings.

### What happens on a VPS with 1 GB of RAM?

The installer offers to create a 1 GB swap file and defaults to accepting. Without it, Docker, the engine and especially the panel build can be killed by the kernel, which looks like a hung install. Manage it afterwards with `mtproxyl swap status|on|off`; swap is never created automatically after that first prompt.

### How do I get the Telegram proxy link after installing?

The link is printed when the installation finishes, and `mtproxyl secret link` prints it again. One port serves every client, iOS, Android and desktop, with no extra per-client configuration.

### Can I roll back a MTProxyL engine update?

Yes, with `mtproxyl engine rollback`, after `mtproxyl engine update <tag>`. With the binary backend the previous version is kept next to the current one as mtproxyl-telemt.prev, so the rollback does not need the network; the Docker backend has to pull the earlier image again.

## Sources

- [Issues](https://github.com/Liafanx/MTProxyL/issues)
- [Liafanx/MTProxyL on GitHub](https://github.com/Liafanx/MTProxyL)
- [License: MIT](https://github.com/Liafanx/MTProxyL/blob/main/LICENSE)
- [README](https://github.com/Liafanx/MTProxyL/blob/main/README.md)
- [Releases](https://github.com/Liafanx/MTProxyL/releases)

---

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