The Lounge: a self-hosted web IRC client that keeps you connected

A fork of Shout with a Vue frontend and a real server

The Lounge describes itself as a modern web IRC client designed for self-hosting, and the repository description adds responsive and cross-platform to that. The site is thelounge.chat, with documentation at the same domain under /docs and a public demo at demo.thelounge.chat.

The lineage matters. The README states that The Lounge is the official and community-managed fork of Shout, by Mattias Erming. Shout was the long-standing self-hosted option in the Node ecosystem, and the fork exists because the original project needed new maintainers. Understanding that explains the two-part shape of the code: a Node server that holds the IRC connections, and a browser client that talks to that server.

The repository tree makes that split concrete. There is a server directory, a client directory, and a shared directory for code used by both, plus a defaults directory for configuration, a test directory, and a scripts directory. The frontend is Vue, and the repository topics include vuejs, irc, irc-client, ircv3, nodejs, and web. GitHub reports the language as TypeScript, and the configuration at the root matches that: tsconfig.json and tsconfig.base.json, vite.config.mts for the client build, and vitest.config.mts for tests.

The IRCv3 topic is the one that matters technically. IRCv3 is the extension protocol that adds capabilities to a protocol designed in the1980s, including message tags, account tracking, and SASL authentication. Supporting it means The Lounge can use your services account login rather than NickServ, which is the difference between a pleasant login flow and a fight with a bot.

Distribution is MIT licensed with a LICENSE file at the root, and the project is at 6,336 stars with 784 forks and 314 open issues. The last push was 2026-09-21, so this is an active codebase rather than a maintained-but-idle one. The 314 open issues are worth noting as a signal: it is a popular project with a real user base, not a small tool with a tidy tracker.

The five features that justify a server at all

The README lists its selling points in a block that reads like marketing until you notice that each one is a consequence of running the IRC connection somewhere that is not your laptop.

Always connected is the core of it. The Lounge remains connected to IRC servers while you are offline. When you come back, the messages that arrived in the meantime are there. On a desktop client, those messages are simply lost, and on a mobile client you are connected only while the app is open. This is the feature that changes how you use IRC, because it means you can leave the client open on a phone, close the laptop, and still catch up.

Synchronized experience is the second one and follows from the first. You always resume where you left off no matter what device you use, because the state lives on the server rather than in a browser session. Switch from phone to laptop mid-conversation and you are in the same channel at the same scroll position.

The remaining three are quality-of-life additions the README describes as modern features brought to IRC: push notifications so a mention reaches you when the tab is backgrounded, link previews so a URL expands into something readable, and new message markers so you can see at a glance which lines arrived while you were reading.

Cross platform is listed too, and it is less interesting than it sounds, because it is a consequence of being a web application. It does not matter what OS you use, it works wherever Node.js runs. That is a genuine advantage for a server operator, since the same instance serves a phone browser, a desktop browser, and a tablet without separate builds.

Together these explain the project's positioning better than the word modern does. The Lounge is not trying to be a better IRC client in the sense of better protocol handling. It is trying to be the one where you do not lose messages.

Node 22 is the floor, and yarn is the expected path

The installation section of the README contains a sentence that is looser than the actual requirement, so it is worth correcting.

The README says The Lounge requires the latest Node.js LTS version or more recent, and it recommends the Yarn package manager. The package.json is more precise: the engines field requires node 22.0.0 or newer. Those two statements are not in conflict, since the current LTS is at or above 22, but the manifest is what your install will actually be checked against, and it is the number to plan around. If your host is on Node 18 or 20, upgrading is a prerequisite rather than an optimization.

There is also a note about npm. If you want to install with npm, `--unsafe-perm` is required for a correct install. That flag exists because The Lounge runs install scripts that npm's modern default permission model blocks. The README recommends Yarn instead, and the repository ships a .yarnrc alongside yarn.lock, so Yarn is clearly the tested path.

For stable releases, the README does not give inline instructions. It refers you to the install and upgrade documentation on the project website, which is the right call for a service that people run unattended, and it is also where you will find the Docker option. There is a separate Docker repository linked from the header at github.com/thelounge/thelounge-docker, and given that the service is meant to stay up continuously, running it as a container is the approach most operators end up with.

The demo instance at demo.thelounge.chat is worth a look before you install anything, connected to the Libera.Chat channel #thelounge. Seeing the client with a real channel's worth of history is more informative than any screenshot.

Running from source, and the executable that is not created

The source route is five commands, and then one caveat that will cost you an hour if you miss it.

git clone https://github.com/thelounge/thelounge.git
cd thelounge
yarn install
NODE_ENV=production yarn build
yarn start

The caveat comes next: when installed like this, the `thelounge` executable is not created, and you use `node index <command>` to run commands. This is because the package is marked preferGlobal and declares its binary as `index.js`, but a source checkout bypasses the global install step that would place that binary on your PATH. So administrative commands that documentation elsewhere may show as `thelounge add` or `thelounge import` need the `node index` form when you are running from a clone.

The README then attaches two warnings to this path with some emphasis. While it is the most recent codebase, this is not production-ready, run it at your own risk, and it is also not recommended to run this as root. That last one deserves agreement rather than a shrug. A long-running process holding outbound IRC connections and writing per-user data has no business with full system privileges, and the source route is exactly where people are tempted to skip creating a service account.

The release channel is where a production install should come from. The package.json version is 4.6.0-pre.1, and recent tags include v4.5.2 on 2026-07-12, a v4.5.2-rc.1 release candidate before it, and v4.6.0-pre.1 on 2026-07-22. The presence of both an rc and a pre tag in the same window tells you the project publishes prereleases deliberately, so a plain version tag is the safe pin and anything ending in a prerelease suffix is for testing.

The README documents webpack where the project now uses Vite

The development section is where the documentation and the build configuration disagree, and it matters enough to call out rather than quietly repeat.

The README's contributor checklist says to run `yarn build:client` if you change or add anything in `client/js` or `client/components`, and then states that the built files will be output to `public/` by webpack. It also says to run `yarn build:server` for changes under `server/`, with the built files output to `dist/` by tsc.

The server half is accurate. The package.json defines build:server as `tsc -p server/tsconfig.json`, which is TypeScript compiling to dist, exactly as described.

The client half is not. The package.json defines build:client as `vite build`, and there is a vite.config.mts at the repository root plus a watch script that is `vite build --watch`. There is no webpack configuration anywhere in the tree, no webpack.config file, and the dev script starts Vite with hot module reloading through the server's ts-node path. So the output directory claim in the README is still right and the bundler name is stale, left over from the period when The Lounge did use webpack before moving to Vite.

Both statements are true in the sense that matters. Running `yarn build:client` and finding output in public/ is what actually happens. Believing the README's claim that webpack produces it is what will confuse you when you go looking for a webpack config or try to reason about loader and plugin behavior.

The actionable reading is simple: if you are contributing client code, run `yarn build:client` and expect Vite, with output in public/. Treat the README's webpack mention as documentation debt rather than a description of the toolchain. The package.json and vite.config.mts are the authoritative pair.

The rest of the contributor workflow is current and matches the scripts. Run `yarn test` to execute linters and the test suite, and run `yarn format:prettier` if linting fails. That test script aggregates the individual lint tasks plus vitest, and the lint family covers eslint, prettier, and stylelint for client CSS, with the eslint config itself checked by a separate task. To avoid committing anything that fails linting, execute `yarn githooks-install`, which points the repository's core.hooksPath at scripts/git-hooks. Renovation is configured at the root through renovate.json, which is how a dependency-heavy Node project stays current without manual audits.

Editorial conclusion

The Lounge exists because of a decision other clients make for you. Every message you receive while your laptop is closed is normally gone, and your channel list lives in the memory of a desktop application on one machine. Running The Lounge on a small server inverts that: the server stays connected, scrollback accumulates on disk, and any browser becomes a client. The pieces you need to know before deploying are unglamorous. Node 22 is the floor, not merely the latest LTS, so check your runtime. The Docker repository is the path of least resistance for a persistent install, and the source route deliberately does not create a `thelounge` executable, which trips up people following npm-era habits. And the README's own warning about running master as root is not boilerplate, because a process that holds long-lived IRC connections and writes user data should not be root. Install a tagged release for anything you depend on, put it behind a reverse proxy with TLS, and read the install documentation on the project website before improvising.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thelounge/thelounge on GitHub