A complete tour of Qeli: a self-hosted, post-quantum VPN in Rust

Qeli is an open-source VPN you run on your own server. No third-party service, no account with someone else, no telemetry - the server is yours, the keys are yours, and the software itself sends nothing to me or anyone else. The core and server are written in Rust. This is a full tour: what it is, how it is built, how to stand one up, and where it honestly stands today.

The model: your server, your keys

Commercial VPNs route your traffic through infrastructure you do not control. Qeli is the opposite: you deploy the server on a box you own or rent, and your devices connect only to it. There is no middleman who could log, sell, or hand over your traffic. If you already rent a VPS, you can have your own private VPN on it.

It is a full VPN, not a proxy: the client brings up a TUN interface and routes the whole device through an encrypted channel to your server - not just one app or one browser tab.

Architecture

One Rust binary is three things:

the server - terminates client tunnels, routes traffic, enforces per-user limits;
the CLI - qeli server, qeli add-client, qeli list-clients, qeli set-bandwidth, qeli kick, and more;
an admin web panel - manage users, bandwidth and identity from a browser, served over its own built-in TLS.

Clients are native on every major platform:

Linux - Rust
Windows - C# / .NET
macOS - C# / Avalonia
Android - Kotlin
iOS and a Keenetic router build are in progress.

Cryptography

This is where Qeli does something most self-host VPNs do not yet:

Post-quantum by default. The inner handshake is a hybrid X25519 + ML-KEM-768 (FIPS 203) key exchange. A classical and a post-quantum secret are both mixed into the KDF, so a recorded session stays safe unless both are broken - protection against "harvest now, decrypt later". I wrote a separate deep dive on the handshake.
Data plane: ChaCha20-Poly1305.
Key derivation: HKDF-SHA256. Password-derived secrets: Argon2id.

The post-quantum core lives in Rust and is shared with the C# and Kotlin clients over FFI/JNI, so every platform speaks the same wire format.

Transports

Qeli has its own L4 protocol with several interchangeable transports - plain, fake-tls, obfs, reality, reality-tls, quic - so you can pick what suits your server and network. The flagship, reality-tls, terminates a genuine TLS 1.3 session: the tunnel runs inside a real, modern HTTPS channel.

Operations

Management is built in, not bolted on:

per-user accounts and accounting
per-user bandwidth limits
a kill switch on the clients
per-user device tracking
human-readable qeli:// config links (and QR) to onboard a client in seconds

Standing one up

On a Debian/Ubuntu server:

sudo apt install ./qeli_0.7.1_amd64.deb
sudo cp /etc/qeli/server.conf.example /etc/qeli/server.conf   # edit it
sudo systemctl enable --now qeli

Then add a client and hand it the generated qeli:// link (or QR):

qeli add-client alice

Point the desktop or mobile client at that link and you are connected. Prebuilt binaries for Linux, Windows, macOS and Android are on the releases page.

How it compares

WireGuard is excellent and I still use it - but it is a single fixed transport, has no post-quantum story yet, and ships no user management. OpenVPN is flexible but heavy and dated. Qeli trades some of WireGuard's minimalism for batteries-included self-hosting: several transports, a web panel, per-user controls, and post-quantum from day one.

Honest status

Qeli is 0.7.1 - beta. The 1.0 line will be the first I would call stable, after more testing and user feedback. There are nearly 200 unit tests and I have triaged two external code audits, but it has not had a professional cryptographic audit, so do not put anything life-critical on it yet. The handshake and transport code is exactly where I would most value outside scrutiny.

推荐订阅源

DEV Community