Tailchat is a self-hosted, plugin-driven instant messaging workspace — TypeScript and React on the front end, microservices on the back, Apache-2.0 licensed — aimed at individuals and teams who want chat as an extensible application platform rather than another Slack, Discord or Rocket.Chat clone.

What it is

Tailchat is an open-source instant messaging application built around the concept of noIM — "Not only IM". It lives in the React and TypeScript ecosystem, with a front-end microkernel architecture matched to a backend microservice structure, and it treats third-party applications as first-class functions inside the chat workspace. A plugin system acts as the glue layer between the core IM and everything attached to it, so external tools appear inside Tailchat rather than beside it.

The concrete problem it solves is integration. Existing IM applications concentrate on chatting itself, and third-party integration tends to be bolted on. Tailchat abstracts its functions and designs the underlying mechanism for expansion from the start, so developers can pull their own applications into the workspace as though they were native features. That is the specific thing it replaces: the traditional integration model of Slack, Discord and Rocket.Chat, where connected apps stay visibly external. Group space customization — building a workspace by dragging and dropping panels — is part of the same idea, and plugins extend it further.

Key capabilities

• Privacy-first group membership: only invited members can join a group.
• Friend requests by nickname plus a random numeric string, which blocks strangers from finding and adding accounts directly.
• Two-level group space that separates different topics by panels.
• Highly customizable group spaces, assembled by dragging and dropping groupings, with plugins adding further capability.
• Plugin system (pluginify) that turns favorite external applications into natural parts of Tailchat.
• Front-end microkernel architecture on React and TypeScript, backed by a microservice backend ready for large-scale deployment.
• Bot and OpenAPI topics indicating programmatic access and automation entry points.
• Desktop and Android builds published through dedicated CI workflows, alongside a Vercel nightly deploy.

Who uses it and how

• Individuals who want a personal workspace where chat is the hub for their other tools, configured through plugins rather than built-in menus.
• Enterprises that need the same platform assembled differently, using plugin combinations to shape Tailchat for their own scenarios.
• Teams planning for growth, relying on the microservice backend structure to absorb increases in user count without a rewrite.
• Developers writing plugins to expose their own applications inside the workspace, treating Tailchat as the integration surface.
• Operators who want the newest commits, running the nightly build that recompiles on every commit, accepting that data reliability and stability are not guaranteed there.

Getting started

Deploy with the stable Docker image moonrailgun/tailchat (tagged latest semver and published via the docker-publish.yml workflow), or take the build from the GitHub release page. For evaluation without deploying, the nightly version runs online at https://nightly.paw.msgbyte.com/, and the official documentation sits at https://tailchat.msgbyte.com/.

How it compares

Facts name Slack, Discord and Rocket.Chat, and Tailchat positions itself explicitly as more than another one of them. Its stated difference lies in integration freedom: connected applications behave as if they were native functions rather than as external integrations, and the whole platform is self-hosted under Apache-2.0 in the operator's own workspace. Slack, Discord and Rocket.Chat are the reference points it measures that freedom against, not products it claims to match feature for feature.

When to use it — and when not to

Choose Tailchat when the workspace must be self-hosted, plugin-extensible and built for integration depth rather than for out-of-the-box completeness. A self-hoster operates the microservice backend and the Docker deployment, and takes on the accompanying operational work; the nightly build carries no guarantee of data reliability or stability, so production use belongs on the stable image or release. Teams that want zero-operations chat, or that need a formally supported enterprise contract, should look elsewhere. The repository is active, with a recent push, 3,624 stars, 397 forks and 128 open issues, but the public README is broad rather than detailed, so deployment specifics must come from the documentation site.