Tinode

Self-hosted instant messaging, honestly reviewed. A full-stack Go backend with native iOS, Android, and web clients — no Meta server in the middle.

TL;DR

• What it is: Open-source (GPL-3.0 server, Apache 2.0 clients) instant messaging full stack — backend in Go, with native apps for iOS and Android, a ReactJS web client, and gRPC bindings for custom clients in a dozen languages [README][1].
• Who it’s for: Developers and technically-inclined founders who want a self-hosted WhatsApp or Telegram alternative with no proprietary components and no per-seat SaaS bill. Explicitly not a Slack replacement — messaging-first, not team-collaboration-first [README].
• Cost savings: WhatsApp is “free” but you’re the product. Dedicated team messaging tools (Slack, Teams) start around $6–7/user/month. Tinode runs on any VPS that can handle Go plus MySQL or MongoDB — realistically $5–10/mo for a small team [README].
• Key strength: Genuine full-stack open source: server, iOS app, Android app, web client, command-line administration tool, and chatbot framework — all in one project, no proprietary dependencies [README][1].
• Key weakness: Self-described “beta quality” (stable, but that’s the developers’ own caveat). Sparse third-party reviews, opaque commercial pricing, and a GPL-3.0 server license that complicates embedding in commercial products [README][1].

---

What is Tinode

Tinode is a full-stack instant messaging platform. The server is written in pure Go under GPL-3.0. The clients — iOS (Swift), Android (Java), and web (ReactJS) — are licensed under Apache 2.0, a meaningful split that lets you ship products with Tinode client code without triggering the GPL’s copyleft requirements. Wire transport is JSON over WebSocket; protobuf with gRPC is also supported for performance-sensitive deployments. Storage runs on MySQL or MongoDB (RethinkDB is documented as a third option, though that database’s commercial future has been uncertain) [README].

The project positions itself as a replacement for XMPP, not a variant of it. From the README directly: “Tinode is not XMPP/Jabber. It is not compatible with XMPP. It’s meant as a replacement for XMPP. On the surface, it’s a lot like open source WhatsApp or Telegram.” [README] That framing is more useful than the typical “federated messaging server” pitch. If you want the XMPP world of bridges, Jabber clients, and compatibility with a thirty-year protocol stack, look at Prosody or ejabberd. If you want something structurally similar to WhatsApp running on your hardware, Tinode is the right category.

The stated goals are two. First: deliver on XMPP’s original promise of federated instant messaging with a mobile-first design. Second: create “a decentralized IM platform that is much harder to track and block by governments.” [README] The explicit non-goal is equally useful: “We are not building yet another Slack replacement.” [README] Tinode is messaging infrastructure, not a team productivity suite.

As of this review, the GitHub repository has 13,155 stars and 2,046 forks [1]. Native apps are published on the Apple App Store and Google Play. A live public demo runs at https://web.tinode.co/ and a sandbox with test accounts is at https://sandbox.tinode.co/ [README]. The project is operated by Tinode LLC, which offers commercial support and custom development.

---

Why people choose it

Third-party reviews of Tinode are thin. AlternativeTo shows no published reviews [1], and the project doesn’t appear on Trustpilot or G2. What exists is mostly positioning data: GitHub activity, app store listings, and placement in WhatsApp alternatives lists [2]. This is itself a signal — Tinode appeals to a technical audience that doesn’t write SaaS reviews, it attracts developers who read READMEs.

The case for choosing Tinode comes down to three things.

Full-stack ownership. Most self-hosted messaging projects either give you a server and expect you to use an existing client (Rocket.Chat, Mattermost), or drop you into a federated network and let you use any compatible client (Matrix). Tinode ships the whole stack: Go server, native Android app, native iOS app, ReactJS web app, a Python/gRPC command-line admin tool, and a chatbot framework. If you’re building a product and want embedded messaging — your own brand, your own mobile apps — you get client source code under Apache 2.0 even though the server is GPL [README].

Go backend efficiency. A Go service is categorically lighter than Rocket.Chat (Node.js, heavier memory footprint) or Matrix Synapse (Python, famously RAM-hungry). For small deployments, this makes the $5 VPS a realistic target rather than an aspirational one. For larger deployments, the efficiency profile means you’re not paying cloud compute bills to serve chat messages.

Data sovereignty. The README explicitly names government tracking as a threat model, not just corporate data collection [README]. For teams routing sensitive internal communication through US-jurisdiction servers — or for founders in markets where that’s a live concern — self-hosting a Go server on your own hardware in your chosen country is the cleanest answer. AlternativeTo places Tinode as an alternative to WhatsApp and other proprietary messaging platforms [1][2], which is the right comparison frame: the value isn’t features, it’s control.

---

Features

Based on the README and project profile:

Core messaging:

• One-on-one and group messaging [README]
• WebSocket transport (JSON) with protobuf/gRPC option [README]
• File attachments [profile]
• Bookmarks [profile]
• Themes and templates [profile]
• Plugin system [profile]

Client coverage:

• iOS (Swift), published on the App Store [README]
• Android (Java), published on Google Play [README]
• Web (ReactJS), live at https://web.tinode.co/ [README]
• Scriptable command-line client [README]
• Chatbot framework [README]
• gRPC bindings for custom clients in C++, C#, Go, Java, Node, PHP, Python, Ruby, Objective-C [README]

Infrastructure:

• Docker support [profile]
• MySQL and MongoDB backends [profile]
• API documented at docs/API.md [README]
• Administration tool in Python + gRPC [README]

What’s not clearly documented in available sources:

• End-to-end encryption specifics — not prominently addressed in the README
• Video calling — listed as a capability on AlternativeTo [1][2], but implementation details aren’t covered in available documentation; verify against the API docs before relying on it
• Federation — stated as a project goal, but not documented as a working production feature [README]

The gRPC coverage is worth calling out. If your team is building an iOS app in Swift but wants messaging integrated into a Go backend, or you have a Python service that needs to send notifications programmatically, the gRPC layer means you’re not limited to the reference clients. That’s a real architectural advantage over projects that expose only a REST API or expect you to use their specific SDK.

---

Pricing: SaaS vs self-hosted math

Tinode self-hosted:

• Server: $0 (GPL-3.0)
• Clients: $0 (Apache 2.0)
• Infrastructure: $5–10/month on Hetzner, Contabo, or DigitalOcean for a small team

Tinode commercial:

• Public messaging service at web.tinode.co — free, appears usable beyond testing [README]
• Commercial inquiries: tinode.co/contact
• Paid support: tinode.co/support.html
• Specific pricing tiers: data not available — no public pricing page was found in the source materials

For comparison, what you’re replacing:

• Slack Pro: $7.25/user/month ($870/year for 10 users)
• Microsoft Teams Essentials: $4/user/month ($480/year for 10 users)
• WhatsApp Business API: variable, roughly $0.005–$0.08 per conversation depending on region

A team of 10 on Slack Pro pays $870/year. Tinode self-hosted on a $6 Hetzner VPS costs $72/year with no per-seat pricing and no message history limits — your database, your retention policy [README].

The self-hosted math is clear. The commercial support pricing from Tinode LLC is opaque, which matters if you need a service level agreement rather than DIY infrastructure. Budget for that uncertainty before committing.

---

Deployment reality check

The README points to INSTALL.md and docker/README.md. Docker is supported [profile]. The practical requirements:

What you need:

• A Linux VPS (2GB RAM is likely sufficient for Go + MySQL serving a small team)
• Docker (for the Docker Compose path)
• MySQL or MongoDB
• A domain name and reverse proxy (nginx or Caddy) for HTTPS
• An SMTP provider if you want email-based account registration

For a technical user: Go + MySQL via Docker Compose is routine. Expect 1–2 hours to a working instance, including DNS and HTTPS setup.

For a non-technical founder: This is not a one-click deploy. There is no managed cloud tier with a sign-up form. If you can’t configure a reverse proxy, you need someone technical to set this up — one-time cost, but a real one.

Known caveats:

• The developers describe the project as “beta-quality software: feature-complete and stable but probably with a few bugs or missing features.” [README] That’s the team being honest. Take it literally — this is not a polished commercial product.
• RethinkDB as a backend option carries risk since the company discontinued it (a community fork continues, but MySQL or MongoDB are the safer choices) [README].
• 38 open GitHub issues as of April 2026 [1] — a small count, but with thin public review data it’s hard to know how representative that is of production pain points.
• No SSO or LDAP integration is documented — user authentication appears to be self-contained.
• Video calling listed on AlternativeTo [1][2] but not detailed in the README; treat it as unverified until you test it.

---

Pros and cons

Pros

• Complete open-source stack. Server (GPL-3.0) plus all clients (Apache 2.0). No “open core” model, no enterprise features gated behind a commercial license [README][1].
• Go backend. Efficient, low memory footprint, compiles to a single binary. Cheaper to run than Node.js or Python messaging servers [README].
• Native iOS and Android apps. Published on App Store and Google Play — not a mobile-responsive web UI, but actual native applications in Swift and Java [README].
• gRPC bindings in 10+ languages. If you’re embedding messaging into a product you’re building, you can write a client in whatever language your stack uses [README].
• Chatbot framework included — scriptable automation without third-party services [README].
• Multiple database backends (MySQL, MongoDB) — you can use what you already operate [README].
• Privacy-oriented design — explicit goal of resistance to government-level surveillance [README].
• No per-seat pricing when self-hosted — add users without the bill scaling with headcount.
• Apache 2.0 clients — the license split means client code can be embedded in commercial products without triggering GPL [README].

Cons

• “Beta quality” self-label. The developers say it in the README [README]. Feature-complete and stable, but with acknowledged rough edges. Not the same assurance as a commercial product with a support SLA.
• GPL-3.0 server license. Embedding the server in a SaaS product or commercial offering requires legal review. The viral nature of GPL-3.0 is a real constraint [README][1].
• No public commercial pricing. You have to contact sales to get numbers — friction for founders evaluating costs [README].
• Sparse third-party validation. No published reviews on AlternativeTo as of this writing [1]. GitHub stars (13,155) indicate interest, but there’s no user testimony to triangulate against.
• Not a managed service. There’s no hosted tier with a sign-up flow and a support dashboard. Everything is self-operated.
• Federation is a goal, not a feature. The README describes federated messaging as the project’s vision [README], but doesn’t document it as a working production capability.
• RethinkDB backend risk. If you choose that path, you’re depending on a community fork [README].
• No documented SSO/LDAP for team authentication.

---

Who should use this / who shouldn’t

Use Tinode if:

• You’re a developer building a product that needs embedded messaging — the Apache 2.0 client licenses and gRPC framework make this genuinely practical.
• You need a self-hosted WhatsApp-style messenger for a small team and have someone technical to deploy and maintain it.
• Your threat model includes data jurisdiction or government surveillance concerns that make commercial SaaS messaging unacceptable.
• You want native mobile apps (iOS + Android), not just a mobile-responsive web interface.
• You’re comfortable with “beta-stable” software and willing to engage with the project’s GitHub when you hit edges.

Skip it (use Matrix/Element instead) if:

• You need actual federation — messages crossing server boundaries — as a production feature today. Matrix has it; Tinode is still working toward it [README].
• You want bridges to Slack, Discord, IRC, and Telegram. Matrix has hundreds; Tinode has none.
• Your users are non-technical and need polished onboarding with managed hosting options.

Skip it (use Rocket.Chat or Mattermost instead) if:

• You’re replacing Slack for a team and need channels, threads, integrations with Jira and GitHub, and workflow automation. Tinode explicitly rejects this use case [README].
• You need SSO, LDAP, audit logs, or compliance features.
• You want a larger open-source community and a commercial vendor with a mature support model.

Skip it (use Signal instead) if:

• You need secure individual messaging and don’t need to operate the infrastructure yourself. Signal’s security model is excellent and the user experience is unmatched for personal messaging.

---

Alternatives worth considering

• Matrix/Element — the natural comparison for self-hosted open-source messaging. Federated, AGPL-3.0, heavier resources (Synapse is memory-hungry), but a large bridge catalog and a real enterprise managed cloud option.
• Rocket.Chat — what Tinode explicitly says it isn’t. Full team collaboration platform (Slack replacement), MIT community edition, significantly heavier stack (Node.js), more mature for business workflows.
• Mattermost — Slack-focused, MIT community edition, excellent Slack import tooling, stronger enterprise feature set than Tinode, more polished for internal team communication.
• Zulip — threaded conversations, Apache-2.0, strong for asynchronous distributed teams. Different interaction model than WhatsApp-style messaging, but worth considering for async-first teams.
• Signal — best-in-class security and UX for personal messaging, not self-hostable. Choose infrastructure control (Tinode) or choose the best user experience (Signal), not both.
• Prosody / ejabberd — if you specifically want XMPP. Tinode explicitly rejects compatibility with XMPP [README], so these serve a different philosophy.

---

Bottom line

Tinode is a genuine full-stack messaging project — not a server that expects you to locate your own clients, and not an XMPP reimplementation with a new name. The architecture is coherent: efficient Go backend, native iOS and Android apps, Apache 2.0 client licenses for commercial embedding, gRPC for custom integrations. For a developer building a product that needs messaging infrastructure, or for a technically capable team that wants a self-hosted WhatsApp alternative without routing data through Meta or Telegram’s servers, the foundations are there. The honest caveats are the “beta quality” self-label, the GPL-3.0 server license, and the absence of third-party validation that would tell you how it performs under real production load. The project has 13,155 GitHub stars and active iOS/Android apps in production stores — it’s not abandonware — but it’s also not the category leader with a user community writing Trustpilot reviews. Evaluate it on the basis of what you can read and test, not on word-of-mouth that doesn’t yet exist.

---

Sources

1. AlternativeTo — Tinode (13,254 stars, 2,046 forks, updated Apr 14, 2026). https://alternativeto.net/software/tinode/about/
2. AlternativeTo — Best WhatsApp Alternatives, Page 4 — Tinode listed as open-source alternative with GPL-3.0 license. https://alternativeto.net/software/whatsapp/?p=4

Primary sources:

• GitHub repository and README: https://github.com/tinode/chat (13,155 stars, GPL-3.0 server / Apache 2.0 clients)
• Live public demo: https://web.tinode.co/
• Sandbox environment: https://sandbox.tinode.co/
• Commercial inquiries: https://tinode.co/contact
• Paid support: https://tinode.co/support.html