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

Alexandr Litvinov — Thu, 18 Jun 2026 22:29:05 +0000

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.

Adding a post-quantum hybrid handshake to a Rust VPN

Alexandr Litvinov — Thu, 18 Jun 2026 22:13:48 +0000

I maintain Qeli, a self-hosted VPN whose core and server are written in Rust. For the 0.7.x line I added a hybrid post-quantum key exchange to the inner handshake, and wired the same primitive into the non-Rust clients. Here is how it is built and what bit me.

Why hybrid, not pure PQ

The threat is "harvest now, decrypt later": traffic captured today, decrypted once a large quantum computer exists. Classical X25519 does not survive that; pure ML-KEM is young, and I do not want one new primitive to be the only thing between you and plaintext. So the handshake runs both and mixes the results - you are safe unless both X25519 and ML-KEM-768 fall.

The shape of the handshake

Classical: X25519 ephemeral ECDH.
Post-quantum: ML-KEM-768 (FIPS 203), via the RustCrypto stack - one side encapsulates to the other's ephemeral KEM public key.
The two shared secrets are concatenated and run through HKDF-SHA256 to derive the session keys. The data plane is ChaCha20-Poly1305; password-derived secrets use Argon2id.

Mixing both secrets in the KDF (instead of picking one) is what makes it hybrid: an attacker has to break both to recover the key.

One PQ core across Rust, C# and Kotlin

Qeli has native clients on Windows/macOS (C#) and Android (Kotlin). Rather than reimplement ML-KEM three times, the Rust implementation is the single source of truth, and the other clients call into a small native core over FFI (C#) and JNI (Android). Same wire format everywhere, and the PQ code gets reviewed once.

Things that bit me

Wire compatibility. Turning on PQ changed the handshake bytes. I kept it wire-compatible within 0.7.x, but it is a breaking change versus older clients - versioning the handshake from day one would have saved pain.
Message sizes. ML-KEM-768 public keys and ciphertexts are ~1.1 KB, far larger than X25519's 32 bytes. Worth accounting for in your framing and MTU assumptions.
Keep the classical path. It is tempting to drop X25519 once PQ works, but hybrid is the whole point - the KDF step has to bind both.

Try it

Code is open (AGPL-3.0 core, MPL-2.0 clients): https://github.com/litvinovtd/qeli - and there is a project site at https://qeli.ru. Feedback on the handshake and transport code is very welcome.

DEV Community: Alexandr Litvinov