The hush repository contains no code, and that is its whole design
End-to-end encrypted messaging, voice, and video. Entry point that orchestrates every public component.
At a glance
- What is it?
- A messaging platform built on Messaging Layer Security where the top level of the entry-point repository holds a licence, a security policy, documentation and two scripts, with six component repositories elsewhere, self-hosting that does not build the web client, and an anonymous in-app reporter with its own private handoff.
- Who is it for?
- Judge Hush on the parts you can verify rather than the pitch, and the verifiable parts are specific. Every client loads the same crypto library, OpenMLS compiled to WebAssembly, and the server is a blind relay written in Go that stores and forwards ciphertext without keys, so the end-to-end claim rests on a protocol implementation you can read rather than on transport encryption.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 121 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The entry repository holds a licence, a policy, docs and two scripts
The top level of this repository is a directory of GitHub metadata, a gitignore, a licence, the readme, a security policy, a documentation directory and a scripts directory. There is no application code, no build configuration and no dependency manifest. The primary language is recorded as JavaScript, which is the two shell scripts. This is a deliberate arrangement and the readme says so in the first section: this repository is the public entry point, user-facing bug reports and feature requests are filed here, self-hosting entry points and architecture documentation live here and link out, and community discussion happens in the discussions area. The component repositories are described as implementation nodes that exist for code review and source ownership rather than for end-user triage. If you are unsure where a problem belongs, you open the issue here and a maintainer routes it. The cost is that a reader arriving at the repository has to accept that nothing here can be run.
The end-to-end claim rests on a WebAssembly MLS library, not on transport encryption
The security argument is made in one sentence and it is the right one. Hush is built around the Messaging Layer Security protocol, specified as RFC 9420, every message, voice frame and video frame is encrypted end-to-end on the client, and the servers move bytes without reading them. The architecture section makes the mechanism concrete: crypto runs on the client and not the server, every client loads the same library, which is OpenMLS compiled to WebAssembly and written in Rust, and it holds the MLS group state shared by every client. The server is a blind relay in Go that stores and forwards ciphertext without the keys. The stated properties that follow are MLS group keys, forward secrecy and post-compromise security, and the readme contrasts this with the encrypted-in-transit, plaintext-on-the-server pattern it says most chat applications ship. Voice and video follow the same path, with a LiveKit-based selective forwarding unit whose end-to-end keys are derived from the same MLS group state.
Self-hosting provisions the server and then uses someone else's web client
The production self-host path lives in a separate server repository, and what it does and does not do is stated unusually clearly. It provisions the backend and media plane, which means the API, PostgreSQL, Redis, LiveKit, a reverse proxy and storage where applicable. It does not clone every Hush repository and it does not build the web client. By default, a self-hosted instance is used from the official web client at the project's own address, which means the operator controls the server and the keys but not the front end. That is a defensible trade for a first deployment and a problem for anyone with a policy about which code may run on their users' devices. The fix is documented in one line: if you also self-host the web client, update the allowed origin setting in the generated environment file to your own web-client origin. The requirements are a Linux server, a container engine, Compose, DNS for two hostnames, and a specific set of open ports.
Setup takes two hostnames and an email for certificate renewal
The provisioning script is a handful of arguments and each one is documented:
git clone https://github.com/hushhq/hush-server.git
cd hush-server
./scripts/setup.sh \
--domain chat.example.com \
--rtc-domain rtc.example.com \
--email [email protected]The public hostname is for the API and the admin dashboard, a second hostname is for the real-time signalling used by voice and video, and the email address is what the certificate authority uses for TLS registration and renewal. Two hostnames rather than one is the part worth noting, because the media path needs its own name and a single-hostname deployment will put signalling behind the same certificate and firewall rules as the API. There is also an IP-only path for development and local network testing that takes a single address argument instead, which is a useful way to try the stack before committing to DNS. After setup you point a client at the instance URL, register or sign in, and open the admin path on your own hostname to bootstrap the dashboard with a secret the script printed.
The developer bootstrap clones six sibling repositories and starts a compose stack
There is a second script in this entry repository, and it serves a different purpose from the provisioning one. Run from a clone of the entry repository, a bootstrap script clones six component repositories as sibling directories, covering the web client, the server, the crypto library, the desktop shell, the mobile client and the directory service, and then starts the development compose stack from the server repository's compose file. The readme labels it for local development and not the production self-hosting path, which is worth stating plainly because the two scripts have similar names in different repositories and do different things. The bootstrap script is what makes a cross-repository change reviewable, and the desktop client is described in the architecture diagram as an Electron shell over the web bundle, so a change to the web client is also a change to the desktop client and one is not caught by testing the other.
Public issues are explicitly not the security disclosure path
Bug reports and feature requests are routed here through issue templates, and the component repositories are for code-level work, meaning regressions reproducible against a specific commit, internal refactors and build or CI breakage. User-level problems get redirected to the main repository. The security line is the one to internalise: public GitHub issues are not for security disclosure, and the triage document holds the disclosure path as well as how the in-app anonymous bug reporter hands off to a private tracker. So the product ships a disclosure channel that does not depend on a reporter having an account, and a public tracker that is explicitly the wrong place. That combination is the difference between a project that expects vulnerability reports and one that hopes nobody finds anything, and it is the detail most worth crediting in a repository that otherwise contains no code.
Two documents define the contract, and one of them names the layers that must not change
The cross-repository product contract lives in a core invariants document, and the instruction attached to it is unusually strong: before changing auth, the vault, device linking, MLS, messaging, voice, identity labels, the desktop runtime, deploy or release flows, agents and maintainers must identify the impacted invariants and run the targeted checks listed there. A second document holds the implementation boundaries for state ownership, the query library's adoption, runtime schemas, cross-device tests and telemetry. Neither document is in this repository's code, and both are the actual product here, because in a six-repository system the failure mode is not a bug in one component but a change in one that quietly invalidates a promise another made. The identity labels and the desktop runtime appear in the invariants list alongside the crypto, which tells you the surface area the project considers load-bearing.
Editorial conclusion
Judge Hush on the parts you can verify rather than the pitch, and the verifiable parts are specific. Every client loads the same crypto library, OpenMLS compiled to WebAssembly, and the server is a blind relay written in Go that stores and forwards ciphertext without keys, so the end-to-end claim rests on a protocol implementation you can read rather than on transport encryption. Read the cross-repository invariants document before touching auth, the vault, device linking or the MLS group state, because that is where a change in one component silently breaks another. Two things to plan around before you self-host. The setup path does not build the web client, so a default instance is used from the official web client, and if you self-host that client too you have to edit the generated environment file's origin setting yourself. And public issues are explicitly not the security path, with an anonymous in-app reporter that hands off to a private tracker, so a vulnerability report should not start on the issue tracker. The last commit on the default branch main is dated 2 June 2026 and there are no releases.
Frequently asked questions
What is in the hush repository?
No application code. The entry repository holds GitHub metadata, a gitignore, a licence, the readme, a security policy, a documentation directory and a scripts directory with two shell scripts. Implementation lives in six component repositories for the web client, server, crypto library, desktop shell, mobile client and directory service.
How does Hush do end-to-end encryption?
Around Messaging Layer Security, RFC 9420. Every client loads the same library, OpenMLS compiled to WebAssembly, which holds the MLS group state, and encrypts locally. The server is a blind relay written in Go that stores and forwards ciphertext without the keys, and voice and video use a LiveKit selective forwarding unit with keys derived from the same group state.
What does self-hosting Hush require?
A Linux server, a container engine, Docker Compose, DNS for the app and real-time hostnames, and ports 80, 443, 7880 to 7881 over TCP and 50020 to 50100 over UDP open. The setup script takes a public hostname, a real-time hostname and an email for certificate registration, and there is an IP-only mode for development.
Does self-hosting Hush build the web client?
No. The provisioning path does not clone every Hush repository and does not build the web client, so by default a self-hosted instance is used from the official web client. If you self-host the web client as well, you have to update the allowed origin setting in the generated environment file yourself.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/hushhq-hush)