# Tinode chat: a self-hosted Go messaging server with iOS, Android and web clients

> Tinode is a full-stack instant messaging platform with a Go backend and native clients. It installs from source or Docker, speaks JSON over websocket or protobuf over gRPC, and is licensed GPL-3.0 on the server side.

**tinode/chat** — Instant messaging platform. Backend in Go. Clients: Swift iOS, Java Android, JS webapp, scriptable command line; chatbots

- Repository: https://github.com/tinode/chat
- Stars: 13,522 · Forks: 2,081
- Language: Go
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/tinode-chat

## What Tinode chat solves, and for whom

Tinode is an instant messaging server plus a set of first-party clients. The README frames the motivation historically: XMPP promised federated instant messaging, and the project argues that promise was never delivered, leaving messengers as incompatible walled gardens. Tinode is explicitly not XMPP and not compatible with it. The README describes it as "meant as a replacement for XMPP" and, on the surface, "a lot like open source WhatsApp or Telegram".

The README also states an explicit non-goal: this is not another Slack replacement. That single sentence does more filtering than any feature list. If your requirement is channels, threads and workspace administration for a company, the project is telling you it is aimed elsewhere.

The intended audience is developers who want to run their own messaging backend and build or embed clients against it. The repository ships an Android client in Java, an iOS client in Swift, a ReactJS web app, a scriptable command line client in tn-cli, and gRPC client support for C++, C#, Go, Java, Node, PHP, Python, Ruby and Objective-C. A second stated goal is a decentralized platform that is harder to track and block. That is a political framing, not a technical guarantee, and the README does not claim the current release achieves it.

## How the Tinode server moves messages

The wire transport is the part worth understanding before you commit. According to the README, messages travel as JSON over websocket, with long polling available as an alternative, or as protobuf over gRPC. That gives you two distinct integration paths: a browser or mobile client that holds a websocket, and a server-side or native client that speaks gRPC.

The backend is pure Go. The module path in go.mod is github.com/tinode/chat and the file declares go 1.26.0, so the toolchain floor is explicit rather than implied. The dependency list shows the shape of the deployment: drivers for MySQL, PostgreSQL and MongoDB, plus a RethinkDB driver, so the storage layer is a choice you make rather than one baked in. Object storage support comes through the AWS SDK v2 S3 packages and Firebase is present for push. Prometheus client libraries are in the direct dependency list, and the repository has a monitoring directory alongside an exporter, so metrics are part of the design rather than an afterthought.

Two smaller details point at production intent. github.com/tinode/snowflake is a direct dependency, which is the ID generation scheme, and github.com/nyaruka/phonenumbers is there for phone number handling, matching the README's mention that users can be discovered by email or phone. The repository layout separates concerns cleanly: server for the backend, tinode-db for storage, pbx for the protocol buffers, chatbot for bot support, rest-auth for external authentication, keygen for keys, and loadtest for load testing.

## Installing Tinode and logging into the sandbox

The README does not inline installation commands. It points to INSTALL.md for general instructions and docker/README.md for Docker-specific ones, and the repository has build-all.sh, docker-build.sh and docker-release.sh at the top level. Because the exact flags are not spelled out in the README, the honest starting point is the documentation the project names.

What the README does give in full is the sandbox, which is the fastest way to see whether the protocol and the clients behave the way you expect before you build anything. The demo service runs at sandbox.tinode.co, with pre-made accounts alice, bob, carol, dave and frank. The password pattern is the login followed by 123.

```bash
# sandbox credentials from the README
# login: alice
# password: alice123
# other users: bob, carol, dave, frank (same password pattern)
# discovery: prefix with email: or tel:
# emails: alice@example.com
# phones: +17025550001 through +17025550009
```

When you register a new account the server asks for an email address and sends a verification code. The README states that for demo purposes you may use 123456 as a universal validation code, and that the code sent by email is also valid. That behaviour is controlled by a configuration line in tinode.conf.

```json
"debug_response": "123456"
```

Removing that line from tinode.conf disables the universal code. That is the first configuration change most people make, and it is the right one to make before anything reaches a real network. One operational detail matters for anyone testing against the sandbox: the README says the server is reset, with all data wiped, every night at 3:15am Pacific time. An error reading "User not found or offline" usually means the reset happened while you were connected. The README's remedy is to reload and log in again on web, log out and log in again on Android, and delete and reinstall the app if the database changed. There is also a basic chatbot account named Tino that replies with a random quote to any message.

## Where Tinode chat is the wrong tool

The README labels the project beta-quality software: feature-complete and stable, but probably with a few bugs or missing features. That is the maintainers' own description, and it should set your expectations for a production rollout. Beta in this sense means the protocol and features are settled, not that every edge case is closed.

The non-goal is the sharper limitation. If you want a team collaboration product with channels, workflows and an admin console, Tinode is not that, and the README says so directly rather than leaving you to discover it. If you need to interoperate with an existing XMPP deployment, Tinode will not do it. The README is unambiguous that the project is not XMPP and not compatible with it, so a migration means replacing the server and the clients rather than bridging them.

The sandbox carries its own constraints that hint at deployment realities. It is configured with ACME TLS and a hard-coded requirement for SNI, and the README notes that if you cannot connect, the most likely cause is a TLS client without SNI support. That is a client compatibility boundary you inherit if you copy the configuration.

Finally, the README does not document rollback, backup or restore procedures. For a system whose sandbox wipes itself nightly, the absence of any recovery documentation in the README is a gap worth naming rather than glossing over. Check INSTALL.md and the tinode-db directory before you assume a migration path exists.

## Tinode compared with Rocket.Chat and XMPP

The related searches surface Rocket chat as a term people pair with Tinode, and the comparison is instructive because the two projects answer different questions. Rocket.Chat is a team communication product: the unit of organisation is the workspace, and the value is in channels, integrations and administration. Tinode's README rules that category out as an explicit non-goal. Tinode's unit is the conversation between users, with bots available through the chatbot directory and a scriptable client in tn-cli. If your requirement is a company chat product, the two are not substitutes.

Against XMPP the difference is architectural rather than feature-level. XMPP is a federation protocol with a long history of server implementations that are supposed to exchange messages with each other. Tinode is a single platform with its own protocol, its own clients and its own storage layer. The README argues XMPP failed to deliver federation in practice and positions Tinode as the replacement. Whatever you think of that argument, the practical consequence is that adopting Tinode means adopting the whole stack: server, clients and protocol. There is no bridging story in the README.

A third path is worth stating plainly. If you only need messaging inside one application, a hosted API or a library may cost less than running a Go server, a database and push infrastructure. Tinode's value shows up when you want the server, the clients and the protocol to be yours.

## Maintenance, licensing and upgrade cost

The last push to the default branch was on 2026-09-13, which is recent. Releases are also regular: v0.25.1 on 2025-12-26, v0.25.2 on 2026-03-03 and v0.25.3 on 2026-07-04. The release notes are terse. v0.25.3 lists bug fixes and dependency updates, v0.25.2 lists optimizations and tuning, and v0.25.1 lists bug fixes. There is no migration guide in those notes, so an upgrade between releases is a dependency-and-code review rather than a documented procedure.

Dependency churn is the real maintenance cost here. go.mod pins a large direct set: three database drivers plus RethinkDB, the AWS SDK v2 S3 packages, Firebase, gRPC and protobuf, Prometheus clients, and golang.org/x/crypto. Each of those moves on its own schedule, and the release notes suggest dependency updates are a routine part of each release. Budget for that, not just for the server code.

Licensing splits in a way that matters for adoption. The README states the backend is GPL-3.0, and the repository LICENSE file is at the top level. The clients are licensed under Apache 2.0. That means the server carries copyleft obligations while the client code does not, which is a meaningful distinction if you plan to modify the server and distribute the result. This is a description of the stated terms, not legal advice. If your distribution model depends on the answer, get it from someone qualified to give it.

## Conclusion

Adopt Tinode if you need a messaging backend you host yourself and can build clients against, and if the GPL-3.0 server licence fits how you ship. Do not adopt it if you need XMPP federation, an off-the-shelf Slack replacement, or a project with a published rollback procedure, because the README documents none. Verify the database backend you intend to run against server/tinode.conf, confirm the client repositories are still being pushed to, and check the INSTALL.md steps against your Go toolchain before committing.

## FAQ

### What is the best private chat website?

The README points to a public Tinode service at web.tinode.co and a sandbox at sandbox.tinode.co. The public service requires you to register with a valid email, while the sandbox offers pre-made accounts such as alice with the password alice123. The README does not rank Tinode against other chat sites.

### What are the three types of chat?

The README does not classify chat into three types. It describes Tinode as a messaging platform with bots available through the chatbot directory and a scriptable client in tn-cli, and it explicitly rules out being another Slack replacement.

### What is the most used messaging app in the world?

The README does not report usage figures for any messaging app. It describes Tinode as, on the surface, a lot like open source WhatsApp or Telegram, and states that the project is not XMPP and not compatible with it.

### Are there any instant messengers left?

The README argues that instant messengers are still a bunch of incompatible walled gardens, comparing the situation to AOL of the late 1990s. Tinode's stated goal is a modern open platform for federated instant messaging, and the README notes that it is not XMPP-compatible.

## Sources

- [Issues](https://github.com/tinode/chat/issues)
- [License: GPL-3.0](https://github.com/tinode/chat/blob/master/LICENSE)
- [README](https://github.com/tinode/chat/blob/master/README.md)
- [Releases](https://github.com/tinode/chat/releases)
- [tinode/chat on GitHub](https://github.com/tinode/chat)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tinode-chat