Haven is a self-hosted Discord alternative built on a single Node server

One person runs the server, everyone else joins with a code

Haven is described as a private Discord alternative that runs on your own machine, with no cloud, no company account, no telemetry and no paid tier, and it is free forever. The operational model is stated in one line. One person runs the server, everyone else joins with a code, and messages, files and voice never touch anybody else's infrastructure. The comparison table in the README makes the differences explicit. Hosting is your machine rather than their cloud. An account is no email and no verification. Your messages never leave your server rather than being stored by Discord Inc. Cost is free with no paid tier. Telemetry is none. And the source is open under AGPL-3.0 rather than closed. The accounts are the interesting part of that table, because the usual friction of self hosting is the invitation process, and a join code removes it. Guest accounts, invite links and per-channel join codes with automatic rotation are all in the feature list.

Getting it running takes one command or one script

The getting started section claims about a minute, and there are three paths. The Docker route is a single command with a named volume for the data:

docker run -d -p 3000:3000 -v haven_data:/data ghcr.io/ancsemi/haven:latest

On Windows without Docker you download the zip, unzip it and double-click Start Haven.bat, which installs Node.js for you if you do not have it. On Linux and macOS without Docker you run chmod +x start.sh && ./start.sh. Then you open https://localhost:3000, register with the username admin, make a channel and share the code, and the certificate warning on first load is expected, so you click Advanced and then Proceed. There is also a docker-compose.yml in the repository, which is the more realistic deployment, with the image, a container name, a main HTTPS port and an HTTP to HTTPS redirect port, both configurable, and a comment explaining that the voice relay needs a UDP and TCP port pair when you switch it on.

Voice is peer to peer by default, which is a design choice

The voice design is worth understanding before you invite people, because it changes your infrastructure requirements. Voice chat is peer to peer by default, so audio does not pass through the server, with an optional voice relay there for big servers. The per-user features are the usual set, with volume, mute, deafen, noise suppression and talking indicators. Screen sharing supports several people at once in a tiled grid, and the documentation says watch parties work. There is also a listen together feature with synced playback from Spotify, YouTube and SoundCloud, or a music player right in the voice channel. The compose file hints at the cost of the relay, since the commented port mapping for the voice relay says it needs UDP and TCP and to be uncommented when you switch the relay on, using the same port the setup page shows. The .env example adds TURN_URL and TURN_SECRET for a TURN relay for voice over the internet, and the documentation covers voice and TURN in GUIDE.md. Peer to peer by default means your server stays cheap, and it also means your users' connections carry the traffic.

Direct messages are end to end encrypted, and the key stays in the browser

The privacy claim that matters most is specific. Direct messages are end to end encrypted, and the private keys never leave the browser, so not even the person hosting can read them. That is a different and stronger guarantee than the rest of the application, where the server holds the data by design. The list of operational security features around it is substantial. Bcrypt passwords, JWT auth, HTTPS, MFA, rate-limited logins, and a disk reserve so a full drive never wedges the server. Single sign-on through OpenID Connect is supported, so Authentik, Keycloak, Authelia and Auth0 all work as your login. The .env example shows the secrets you are expected to change, starting with a JWT_SECRET whose comment says to change it to a long random string, auto-generated on first boot if left at the default, and an ADMIN_USERNAME where the first account registered with that name gets admin powers. There is a SECURITY.md file in the repository, and the contributing section suggests that the version number from the /api/version endpoint helps when reporting a bug.

Discord import and the Ferry bridge are the migration path

For a group moving off Discord, the two most interesting features are the import and the bridge. You can import your whole server history from inside Haven, with every channel, thread, forum post, reaction, pin and attachment, by pasting a token, picking a server and going. Ferry is a two-way Discord bridge, where messages pass both ways between a Haven channel and a Discord channel, under each person's real name, so friends who are not ready to leave Discord can still talk to the ones who did. The design goal is that nobody has to install anything to be included, and the README is explicit that the desktop, mobile and browser clients talk to the same server and see the same thing. The client story is a mix of native and web. There is a Haven Desktop app for Windows and Linux with per-app audio sharing, device switching mid-call, native notifications and a tray, which can also run the server itself. There are native Android and iOS apps, the iOS one in TestFlight, and a browser path that needs nothing installed at all.

The AI disclosure is the most important thing to read

The README has a section on AI usage, and it is unusually blunt. Haven is built with AI. The author says plainly that they are not a professional programmer, that they came up with Haven, decide what goes in, and test it and run it with their own community, and that most of the code, the server logic included, was written by AI coding tools, mainly Claude Code, working from their direction, and that most code review is AI-assisted too. For a self-hosted service that stores your community's messages, that is a substantive fact about how the software comes into existence and how it is maintained, and it is a better position to be in than one where nobody says it. It also explains some of the rest of the project, including the very rapid release cadence, with v4.26.2, v4.26.1 and v4.26.0 published within a day of each other in October 2026, and the fact that the project is a single maintainer's community product rather than a company. The dependency list is otherwise conventional and readable. Express for HTTP, socket.io and ws for the realtime layer, better-sqlite3 for storage, helmet for headers, express-rate-limit, jsonwebtoken, bcryptjs, otpauth for two factor, multer for uploads, web-push for notifications, localtunnel for the tunnel, and node engines of 22 or newer and below 27.

Editorial conclusion

Adopt Haven when your group wants a chat server on your own hardware with no account, no telemetry and no paid tier, and when you are prepared to run the server, its updates and its backups yourself. Do not adopt it expecting a mature platform with a support team, and read the AI usage disclosure before you depend on it for anything sensitive. Verify first that your Node.js version falls in the supported range of 22 to 26, that you can terminate HTTPS on the server or use the built in tunnel support, and that the voice relay or TURN settings you choose match the number of people you expect to have in a call.

Frequently asked questions

Official sources

1. ancsemi/Haven on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases