EdgeChat: A Cloudflare-Native Team Chat With a Telegram Bridge
A full-featured team chat system built on Cloudflare Workers, with public/private groups, DMs, realtime messaging, file uploads, and an admin dashboard.
At a glance
- What is it?
- EdgeChat is a GPL-3.0 chat system that runs on Cloudflare Workers, D1, KV, R2 and Durable Objects, with public and private groups, DMs, voice messages, an admin dashboard and a two-way Telegram bridge. The interesting question is not whether it works, but whether you want your team's messaging to live inside one Cloudflare account.
- Who is it for?
- EdgeChat fits a small team that already pays for Cloudflare and wants a chat instance inside its own account, with Telegram as the mobile notification path. It does not fit anyone who needs message history readable by an administrator, self-service signup, or reliable background push on Android, since the repository states the Capacitor client has no FCM, no Room offline database and no WorkManager outbox.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem EdgeChat Targets: Chat Without a Server to Patch
Most self-hosted team chat means running something. Rocket.Chat and Mattermost both need a persistent host, a database and a cache, and someone has to patch them. EdgeChat takes the other route: the whole backend is a Cloudflare Worker, so there is no operating system to update and no container to restart. The README frames the goal as running a usable in-site IM inside the Cloudflare ecosystem at low operational cost, and the comparison table it publishes puts self-hosted Rocket.Chat and Mattermost in the column that needs a permanent server.
The audience is narrow and specific. It is a team that already has a Cloudflare account, is comfortable with Wrangler and GitHub Actions, and wants its chat data to sit in its own account rather than a third party's. The README also states that administrators create users and that self-service registration is not open, which tells you the intended shape: a closed group, not a public community. If you need federated rooms, guest access, or an app directory, this is the wrong product category.
How the Pieces Fit: Workers, D1, KV, R2 and Durable Objects
The stack is fully enumerated in the README. Vue 3 with Vue Router and Vite on the front end. Cloudflare Workers with Hono as the HTTP layer. Durable Objects handling realtime over WebSocket, with hibernation enabled, which is the mechanism that lets a mostly idle chat room stop billing compute while keeping its connections open. D1 stores relational data. KV holds sessions. R2 holds uploaded files and avatars.
That split matters because each piece has a different failure and cost profile. Sessions in KV means a login check is a fast key lookup, but KV is eventually consistent, so a revoked session may not disappear everywhere at the same instant. Files in R2 means the Worker never proxies large uploads through its own request budget, but it also means file access control is your responsibility at the R2 layer as much as in the Worker. Messages in D1 means history pagination is a SQL query, and the README confirms paginated history is a feature.
The Durable Object is where the realtime logic lives. A chat room maps to a Durable Object instance, and WebSocket hibernation is what keeps that affordable. Without hibernation, an idle room with an open socket would keep a Durable Object resident. The README lists hibernation explicitly, so the design intent is clear, but it does not publish connection limits or throughput numbers, and you should not assume any.
The Telegram Bridge Is the Actual Differentiator
Plenty of projects offer groups and DMs. The feature that is hard to replicate cheaply is the two-way Telegram bridge. According to the README, an administrator binds any EdgeChat group to a Telegram group through a bot, and messages then flow both directions in real time. EdgeChat members see Telegram messages, Telegram members see EdgeChat messages, and neither side has to install the other app.
This solves a concrete problem. Telegram already has mature mobile push, and the README notes that the Android client has no FCM and does not promise background delivery when the app is stopped. The bridge is effectively the notification path: put your team in a bridged group and Telegram handles waking people up on their phones. Voice and audio messages also sync both ways, per the feature list, so the bridge is not text-only.
The cost is that bridging a group means Telegram now holds a copy of that conversation. That is a direct tension with the privacy section, which says new messages and new attachments use AES-256-GCM server-side encryption. Encryption at rest in your D1 and R2 does not extend to what the bot forwards to Telegram. If a room is bridged, treat its contents as leaving your perimeter. The README does not discuss this trade-off, and it should.
Deployment: GitHub Actions, Wrangler, and an Android Build
The repository ships `.github/workflows/deploy-worker.yml`. Pushing to `master` or `main`, or triggering `workflow_dispatch` manually, runs the deployment. The README points to two documentation pages for setup: `https://echat.azora.top/guide/getting-started.html` and `https://echat.azora.top/guide/actions-deploy.html`. Those pages are where the actual secret names and binding configuration live, and the README does not reproduce them, so you will need to read them before you can deploy.
The Android client is the `capacitor/` directory. It embeds the Vue web UI in the APK and uses a small amount of Kotlin for system file picking, notifications, microphone permission, notification-to-conversation navigation and external links. The package name is `com.aozorae.edgechat.web`. There is no fixed server baked in: on first login the user types their own EdgeChat HTTPS address. Building locally needs JDK 21 and Android SDK 36, then `npm run build:capacitor`. The debug APK lands at `capacitor/android/app/build/outputs/apk/debug/app-debug.apk`, and CI uploads it as the `edgechat-capacitor-debug` artifact. Releases are cut by pushing an `android-v*` tag or running the `Android Release` workflow, which uses four `ANDROID_KEYSTORE_*` secrets to produce a signed APK and AAB.
The README does not list required Worker secrets, D1 schema migration commands, or R2 bucket names. That is the gap you will hit first, and it is why the linked guide pages are not optional reading.
Where EdgeChat Breaks Down or Is Simply the Wrong Choice
The Android limitations are stated plainly and they are significant. The README says the client currently has no Room offline database, no WorkManager Outbox and no FCM, and that background message delivery is not promised when the app stops receiving. In practice that means a closed app may not notify you. The Telegram bridge is the workaround, not a fix, and it only covers groups you have bound.
Encryption has a boundary the README draws itself. AES-256-GCM applies to newly written messages and newly uploaded attachments, and historical data is not backfilled. So the encryption state of your database depends on when a row was written, not on a global setting. If you are evaluating EdgeChat for a compliance requirement, that mixed state is the first thing to test.
Administrators create accounts and there is no self-service registration, which is good for control and bad for onboarding anyone outside a known list. The admin dashboard deliberately does not expose group or DM message bodies, per the README. That is a defensible design choice, and it also means you cannot moderate content from the dashboard. If your organization requires administrative review of conversations, EdgeChat excludes itself.
Finally, the whole system sits on one vendor. D1, KV, R2 and Durable Objects are Cloudflare-specific. There is no portability story here, and the README does not claim one.
What You Would Use Instead, and How the Approach Differs
Mattermost is the honest comparison, and the README names it alongside Rocket.Chat in its own table. Mattermost is a Go server with a PostgreSQL database that you run yourself, on a VM or in containers, and it has a mature desktop and mobile client with push notification support through its own push proxy or a self-hosted one. The difference in approach is not features, it is where the operational burden sits. Mattermost asks you to keep a database healthy and a server patched. EdgeChat asks you to accept Cloudflare's platform limits and pricing in exchange for having no server at all.
That trade has a clear shape. With Mattermost you can inspect the database directly, move it between hosts, and run it on hardware you control. With EdgeChat your data lives in D1 and R2 inside one account, and your escape route is an export you would have to write. If your team has an operations person and a preference for conventional infrastructure, Mattermost is the safer default. If your team has nobody who wants to patch a server and already uses Cloudflare, EdgeChat's model is genuinely less work.
There is also a middle option the README implicitly acknowledges: run nothing and use a commercial SaaS IM. EdgeChat's own table lists that column as per-seat pricing with data held by a third party. The reason to pick EdgeChat over that is data ownership, and the reason to pick SaaS over EdgeChat is that you get push notifications and mobile clients that were built as products rather than as a Capacitor wrapper.
Licence, Maintenance and Upgrade Cost
EdgeChat is GPL-3.0-or-later. If you modify it and distribute it, or run a modified version as a network service, the licence obligations follow you. The README does not discuss this, and it is not a legal opinion, but the practical implication is that a fork you deploy for your team may carry source-availability duties. Confirm with your own counsel before building a private modified version.
The upgrade path is the part that costs real time. Because deployment is a GitHub Actions workflow triggered by pushes to `master` or `main`, staying current means tracking upstream and re-running the workflow. The README mentions one feature that helps: the admin dashboard compares the deployed build against the source repository in the browser, so you can see whether your instance is behind. That is a check, not an automated upgrade.
Two version lines exist. The Android client is at `android-v0.2.0-beta.1`, released 2026-09-05, following `android-v0.1.0-beta.1` from 2026-08-30. Both are beta. The web and Worker side has no tagged release in the supplied material, which means the stable surface is the `master` branch itself. Treat the Android client as pre-release and the Worker as a rolling deployment, and budget time for reading release notes before each pull.
Editorial conclusion
EdgeChat fits a small team that already pays for Cloudflare and wants a chat instance inside its own account, with Telegram as the mobile notification path. It does not fit anyone who needs message history readable by an administrator, self-service signup, or reliable background push on Android, since the repository states the Capacitor client has no FCM, no Room offline database and no WorkManager outbox. Before committing, verify three things against the live documentation at echat.azora.top: whether Durable Objects WebSocket hibernation stays inside the free tier at your message volume, whether the AES-256-GCM encryption applies to the messages you care about (the README says historical data is not backfilled), and whether your Telegram bot can be bound to the group you intend to bridge.
Community notes