Tailchat: a self-hosted noIM workspace built around a plugin system

The problem Tailchat takes on, and who it is aimed at

Most chat software treats the message list as the product. Tailchat starts from the opposite claim. Its README says existing IM applications "only focus on chatting itself", and that IM is naturally a multi-person collaboration method that should carry more. The project's term for this is noIM, meaning Not only IM: a customized application platform for individuals or teams, centered on chat, with third-party applications as added functions and a plugin system as the glue layer. That is a positioning statement, not a feature list, and it tells you who the project is for. It is for teams that already accept they will run their own infrastructure and want a chat surface they can extend without forking the whole product. It is not for someone who wants a chat account. The README's feature list backs the positioning with concrete choices: only invited members can join a group, friends are added by nickname plus a random string of numbers, and group space is two-level, with topics divided by panels that you arrange by dragging and dropping. Those are privacy and layout decisions, and they are the parts of the product that exist before any plugin does.

How the plugin system and the two-level group model fit together

The architecture claim in the README is specific: a front-end microkernel plus a back-end microservice structure, built on React and TypeScript, ready for clustering deployment. The repository layout matches that claim. There is a client directory, a server directory, a packages directory, a page directory and a website directory at the top level, and the root package.json is private with a pnpm workspace, which is what you would expect from a monorepo that publishes several packages rather than one application. The extension point is the plugin system. The build script in the root package.json runs a plugin install step that names a fixed set of plugins, including com.msgbyte.tasks, com.msgbyte.linkmeta, com.msgbyte.github, com.msgbyte.simplenotify, com.msgbyte.topic, com.msgbyte.welcome and com.msgbyte.iam, then copies the resulting public/plugins directory into the server build output alongside registry-be.json. So plugins are not a runtime afterthought bolted onto a finished server. They are compiled into the image and served from a registry the server knows about. The README is honest about the cost of that arrangement. It states that while the core functionality is in a stable stage, the exposed interface for third-party developers is still being improved, is generally backward compatible, and retains the possibility of a break change. Treat plugin APIs as a moving target, and pin the version you build against.

Deploying Tailchat with Docker Compose

The repository ships a docker-compose.yml, a docker-compose.env file and a Dockerfile, so the intended path is a Compose stack rather than a single container. The README also links two one-click deployment routes, Sealos and ClawCloud Run, for people who do not want to run the stack themselves. The Compose file defines three Tailchat service groups that share one image. The first is service-core, which runs the core services and listens on port 3000. The second is service-openapi, which runs the open platform services and sets OPENAPI_PORT to 3003 with OPENAPI_UNDER_PROXY set to "true". The third is service-all-plugins, which points SERVICEDIR at the plugins directory. All three depend on the same mongo, redis and minio containers. A first run looks like this:

Where Tailchat is the wrong tool

The Compose stack is the first limitation, and it is not a small one. A working deployment needs Tailchat plus MongoDB, Redis and MinIO. That is four stateful concerns before anyone sends a message. The README's own feature list promises a back-end microservice structure ready for large-scale deployment, which is a fair description of the design, but the design is also why a single small team gets a stack rather than a binary. The second limitation is the plugin interface. The README says the third-party developer interface is still being improved and retains the possibility of a break change. If your plan is to build a long-lived internal integration against that interface, you are building on something the project itself declines to freeze. The third is versioning. The repository publishes a nightly build that compiles every commit, and the README warns directly that the reliability and stability of the data are not guaranteed there, pointing users to the stable Docker images or the GitHub release page instead. A team that wants the newest plugin behaviour and a stable data store cannot have both from the same channel. Finally, the README does not document rollback or a migration path between releases, so a version upgrade is a step you take without a documented way back.

How Tailchat differs from VoceChat and the Slack-style model

VoceChat is the closest thing to a peer in the search data around this project, and the two take different routes to the same goal. VoceChat's public positioning is a lightweight self-hosted chat server, and its pitch rests on being small and easy to put on a single machine. Tailchat's README argues the opposite direction: it abstracts functions deliberately, spends effort on an underlying mechanism, and ships a plugin system plus a back-end microservice structure that the README says is ready for clustering. So the difference is not features, it is where complexity lives. VoceChat pushes complexity out of the deployment and keeps the server small. Tailchat pushes complexity into a plugin and service layer so that third-party applications can behave like native functions, and accepts the operational weight that comes with it. The README also draws a line against the Slack and Discord integration model, claiming Tailchat's integration is more free, "as if it is a native function", rather than an app that lives beside the chat. That is a design claim you can evaluate by reading the plugin list in the build script, not by reading the marketing line.

Licence, releases and the cost of keeping up

Tailchat is licensed under Apache-2.0, and the LICENSE file sits at the repository root. Apache-2.0 is a permissive licence that includes an explicit patent grant, which matters if you intend to modify the server or ship a plugin inside a commercial product. It does not give you the project's trademarks, and it does not oblige the maintainers to keep any interface stable, which is consistent with the README's warning about break changes. This is not legal advice; read the LICENSE file and your own counsel's view before you build a product on it. On maintenance, the repository is not archived, and the most recent push recorded is 2026-09-23, the same day as the newest release, so the codebase is moving. The release cadence in the listing is uneven rather than monthly: v1.11.12 on 2026-07-20, then v1.11.13 and v1.11.14 on 2026-09-22. That gap is the practical upgrade cost. Because the plugin interface can break and because the build script pins a specific plugin set, an upgrade is not a container tag swap. You rebuild, you reinstall the plugin list from the root package.json build:server script, and you verify that the plugins you depend on still load. Budget for that on every minor bump, not just on major ones.

Editorial conclusion

Adopt Tailchat if you want a self-hosted chat base you can reshape with plugins and you are willing to run MongoDB, Redis and MinIO yourself. Do not adopt it if you need a frozen third-party API for long-lived integrations: the README states the interface for third-party developers is still being improved and retains the possibility of a break change. Before committing, read docker-compose.env and confirm which of the core, openapi and plugin service groups you actually need, then check that the plugin set installed by the build script matches the plugins your team plans to use.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. msgbyte/tailchat on GitHub
3. Project website
4. README
5. Releases