subway, the IRC client its own maintainer set aside

The first line of the README is a redirect

Nothing about subway is subtle once the README is read carefully, because the maintainer puts the verdict at the very top. The opening note states that Subway is not currently functional and not under active development, that the plan is to finish the project some point in the future, and that the maintainer strongly suggests taking a look at The Lounge.

That framing changes what an evaluation should be about. This is not a drop-in IRC client you can deploy today. It is an unfinished project with a working-looking shell around it, a set of stated goals, and a direct recommendation to use something else. The repository description itself carries the word ABANDONED. The useful question is therefore not whether subway is ready but what a team would inherit if it decided to take the project over.

A multi-user backend is the point, not a side feature

The architecture is the one part of the project that is described concretely. Subway is a web-based IRC client where frontend and backend talk over websockets, with a fallback to the best available transport where websockets are not available. The backend is multi-user, and it supports connection persistence plus optional logging when the browser disconnects.

The stated goals follow from that design. The first goal is to become the best web-based IRC client available, and the second is to provide an easy method of persistent IRC connections reachable from any browser. The README gives the origin story: the author wanted to watch a fellow programmer explain how to set up screen and irssi to a non-technical person. Persistence and multi-tenancy are the parts with an engineering payload, and they are also the parts that most of the package dependencies support.

The README describes a stack the manifest has replaced

Here is the first thing to notice if you plan to fork. The README says Subway is built with node.js, node-irc, Backbone.js, ReactJS and jQuery on the frontend. The current package.json tells a different story. The dependency list contains irc at version 0.5.2 rather than node-irc, react and react-dom at 18.3.1, and socket.io at 4.7.5 for the realtime channel. There is no Backbone and no jQuery in the dependency list, and the build tooling is a Vite pipeline with Tailwind 4 and PostCSS, not the older asset setup the README implies.

The project metadata also lists a current version of 0.4.0, an ES module package with a main entry of ./dist/server/index.js, and a bin entry named subway pointing at the same file. So the codebase has been rebuilt around a modern stack, while the prose documentation still describes the original plan. Anyone reading only the README will misjudge the current state of the code.

Prisma, bcrypt and a session layer shape the backend

The dependency list in package.json describes a conventional multi-user web backend rather than a thin IRC proxy. Prisma is present as both @prisma/client and the prisma dev dependency, and the repository has a top-level prisma directory, which is where the schema and migrations live. A SQLite file is the default database target.

User handling is handled by bcrypt, cookie-parser and express-rate-limit, with helmet in front of the Express server for HTTP header hardening. Session configuration is present as a COOKIE_SECRET and a SESSION_MAX_AGE, and zod is included, which suggests request payloads and configuration are validated at the boundary rather than trusted. Client state is handled by zustand, long lists by @tanstack/react-virtual, and logging by winston. None of these details are described in prose anywhere in the README, so the manifest is the only reliable picture of how the server is put together.

The install instructions are written in the conditional

The README is explicit about the state of its own instructions. The install section is prefaced with a note that it should be something like this, once implemented, and the steps themselves are a shell transcript rather than a tested recipe:

        $ git clone https://github.com/thedjpetersen/subway.git
        $ cd subway

The README then asks you to install the dependencies using npm:

    	$ npm install

and to launch the web server:

        $ ./subway.js

After that the browser is pointed at http://localhost:3000/, which matches the default PORT value in the example environment file. Two cautions belong with those steps. The launch command is stale relative to package.json, where the declared entry point is ./dist/server/index.js and a bin entry called subway points at the same path, so a freshly built tree is started with a different file than the README shows. The port also comes from configuration rather than being hard coded, and the example environment file shows what a working setup expects.

DATABASE_URL="file:./subway.db"
NODE_ENV=development
PORT=3000
COOKIE_SECRET=your-secret-key-here-minimum-32-characters
BCRYPT_ROUNDS=12

A server on the public internet is a different commitment

Subway is not a local tool. It is a server that holds IRC connections on behalf of multiple users, and the configuration surface reflects that. The example environment file asks for a cookie secret of at least 32 characters, and the comment next to it says it is required in production with a suggested openssl rand command for generating one. Password hashing rounds default to 12, with a note that higher values are slower and more secure. Session lifetime defaults to 24 hours, expressed as a millisecond value in the file.

Those are the settings of an authentication system that expects the server to face the internet. A deployment that exposes it needs a real database URL rather than the local file default, a generated secret, a considered bcrypt cost, and a reverse proxy or TLS terminator in front. The rate limiter and helmet are the two dependencies doing the blunt work of keeping that exposure survivable, and they are configured, not automatic.

The last push and the missing releases

The repository carries no GitHub releases, so there is no published changelog and no tagged upgrade path for a user to follow. The last push to the repository was on 2026-04-04. Under a normal cadence that would be recent enough to call the project live, but the README says plainly that the project is not under active development, and a pushed commit in April does not undo a maintainer statement of that kind. The version in package.json sits at 0.4.0, which is consistent with a codebase still moving toward its first usable shape.

What the repository does contain is a working directory for contributors. There is a test directory, a mocha configuration, an nyc coverage configuration, sinon and proxyquire in the dev dependencies, and separate TypeScript configurations for client and server. There are also CI documentation files, a Vite config, and a plugin_cache directory. The tooling is in place, which is the encouraging part, but the absence of releases means anyone picking this up inherits the work rather than a maintained product.

Editorial conclusion

subway makes sense only as a codebase to study, fork or finish, since the maintainer states it is not currently functional and recommends The Lounge for anyone who wants a working IRC client in a browser. Anyone adopting it should first check that the intended stack still exists in package.json, that the Prisma schema in the prisma directory matches the models the server expects, and that the absence of any published release is acceptable, since the last push was on 2026-04-04 and the repository has no GitHub releases at all.

Frequently asked questions

Official sources

1. Issues
2. README
3. thedjpetersen/subway on GitHub