Convos turns IRC into a multiuser web chat, and version 9 moves the backend to Go

A gateway, not a client, and that decides what the project is

Convos is described as a multiuser chat application that runs in a web browser, and the supported chat protocol is currently IRC, though the project states that Convos can be extended to support other protocols. The protocol is the client side of the design. The server side is the part that matters for a decision.

A Convos server holds the connection to the IRC network and the state of the chat on behalf of every user who connects to it. That is why it can offer things a native IRC client cannot easily offer: one place to configure, one place to authenticate, one place to run plugins, and one place to add a web interface. The homepage is convos.chat, and the project is distributed under the Artistic 2.0 licence.

The repository shows both generations of the code at once, which is the most interesting fact about it. There are Perl directories (script/, doc/, templates/) for the Mojolicious backend that the README names, a Go module with convos.go, cmd/ and pkg/ at the root, a Svelte frontend in assets/ built with Vite, and a Taskfile.yml, a devenv.nix, a shell.nix and a snap/ directory. The 9.0 release candidate is the Go version.

For an adopter, this dual state is a fact to plan around rather than a curiosity.

What the Go rewrite brought with it

The go.mod file is the clearest description of the server's actual capabilities, because every dependency there corresponds to a feature. The IRC client library is github.com/ergochat/irc-go, and the HTTP router is github.com/go-chi/chi/v5. Real time updates to the browser go over github.com/gorilla/websocket, and sessions use github.com/gorilla/sessions.

The rest of the list is what a multiuser gateway needs to be usable in an organisation. github.com/coreos/go-oidc/v3 handles OpenID Connect, so a deployment can delegate login to an identity provider. github.com/go-ldap/ldap/v3 handles directory lookups. github.com/SherClockHolmes/webpush-go handles browser push notifications, which is the feature that makes a browser tab behave like a real chat client when the tab is closed. github.com/kelseyhightower/envconfig means configuration comes from environment variables, and gopkg.in/yaml.v3 handles YAML configuration.

The OpenAPI entries are worth a note. There is a tool directive for github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen, a runtime library, and github.com/getkin/kin-openapi for working with specifications, plus oasdiff in the indirect list. That means the HTTP API is described in OpenAPI and the server code is generated from it, so the contract is versioned as a specification rather than written by hand. The module requires Go 1.26.0, which is a recent toolchain requirement and a real constraint on who can build it.

The frontend is Svelte compiled by Vite and pnpm

The browser side is a Svelte application, described in the README as held together by the progressive JavaScript framework Svelte. The build tooling is Vite, and the package manager is pnpm, with a pnpm-lock.yaml and a pnpm-workspace.yaml at the root, plus a separate package-lock.json for the older npm based tooling.

The package.json shows the script surface a contributor uses. The dev script is ./script/convos dev, the production build is vite build, and there is a watch mode, vite build -w --mode development. Checks run through svelte-check, tests through vitest with a coverage variant, linting through eslint over assets/, and the API documentation is generated with jsdoc using the .jsdoc.json configuration.

Two details in that file deserve a second look. The browserslist field still lists ie >= 11 and edge >= 18, which is a leftover from an older support policy and a hint that the browser matrix has not been rethought recently. And the dependencies block contains only svelte-check, with everything else under devDependencies, which is a consequence of the Vite build inlining the frontend into the server binary rather than shipping a node_modules directory at runtime.

That last point is confirmed by the Dockerfile, which builds the frontend in a node stage, copies the built assets into the Go build stage so they are embedded in the binary, and then copies only the compiled convos executable into a scratch image. The result is a container with no shell and no runtime dependencies at all.

Two install paths, and the container image moved

The local install is two commands, and it installs into a ./convos directory in the current working directory.

curl https://convos.chat/install.sh | sh -
./convos/script/convos daemon

After that the README says to point a browser at http://localhost:3000 and start chatting. The daemon command is the foreground server, and the port 3000 is the default the container image also uses.

The Docker route pulls an image and mounts a data directory.

docker pull ghcr.io/convos-chat/convos:alpha
mkdir -p $HOME/convos/data
docker run -it -p 8080:3000 -v $HOME/convos/data:/data ghcr.io/convos-chat/convos:alpha

Note the tag is alpha, which is the honest label for the current image, and note the port mapping: the container listens on 3000 and the README maps it to 8080 on the host. The data directory is a volume at /data, and the Dockerfile sets CONVOS_HOME=/data and CONVOS_LISTEN=http://0.0.0.0:3000, exposes 3000, and runs as a non root user created with useradd and a fixed uid of 10001.

There is a migration note here that catches people out. The older Docker Hub images, Nordaaker/convos and convos/convos, are described as being around for a while, but the new official image is hosted on GitHub at ghcr.io/convos-chat/convos. If you follow an old tutorial you will pull the wrong image, and the configuration format between the Perl era and the Go era is not guaranteed to match, so an old config file is the other thing to check.

main is for developers, stable is for people who want to run it

The branch policy is spelled out in the README and it is short enough to matter. The main branch is for developers: it is mostly stable but might require extra tools and packages to run, and this branch might have outdated assets, meaning the JavaScript and CSS files, so it might not work properly. The stable branch is the branch you should use if you want to clone and run Convos, because the JavaScript assets and the Perl code are in sync there.

That description of the stable branch still talks about the Perl code, which tells you how the branch structure has not yet been reorganised around the Go rewrite. In practice, that means a self hoster has to decide between a branch whose frontend assets may be stale and a branch that may not reflect the new architecture.

The release process is documented for developers as well. The Changes file is updated with the recent changes and a correct timestamp, and the production assets are built and checked so that all the files carry the correct version information.

# Update with the recent changes and make sure the timestamp is proper
$EDITOR Changes

# Build the production assets and update and check that all the files
# have the correct version information
./script/convos build release

The only tagged release listed is v9.0-rc1 from 2026-07-14, so the current line is a release candidate rather than a general release. The project is not archived and the last push was on 2026-10-14.

Where the browser gateway stops being the right answer

The obvious case against Convos is the simplest one. If a single person on a single machine wants to read a channel, a gateway is a server to run, configure, secure, back up and update, standing in front of a client that would have been one command. Everything Convos adds, the multiuser support, the web interface, the plugin system, the shared configuration, the push notifications, exists for the case where many people share one deployment.

The second limitation is protocol coverage. The supported protocol is currently IRC, with the stated intent that Convos can be extended to others. That means the ecosystem of modern chat platforms is not covered, and the extension work is on the project rather than on a plugin you install.

The third is the state of the rewrite. With the 9.0 line at a release candidate, the alpha container tag, the branch documentation still describing the Perl code and the browser support list in package.json still naming Internet Explorer 11, the project is mid transition.

The pragmatic reading is that Convos is a good fit for an organisation that already wants a shared web chat and is prepared to run a self hosted service, and a poor fit for a hobbyist who wants a tab that connects to a channel. The Artistic 2.0 licence, with its terms in the LICENSE file, is permissive enough for either.

Editorial conclusion

Convos fits a team or community that wants a shared chat room on the web, with browser push notifications, single sign on and directory lookup, and does not want each member to install a native IRC client. It is the wrong tool if you only need to read a channel from one machine, because the server, its configuration and its user database are the unit of deployment. Verify first whether you want the 9.0 release candidate or the stable branch, and check which container image tag you are pulling.

Frequently asked questions

Official sources

1. convos-chat/convos on GitHub
2. License: Artistic-2.0
3. Project website
4. README
5. Releases