DCTS: a self-hosted chat server that treats decentralization as a deployment choice
DCTS is an ambitious project with the goal to offer absolute independence through software with a no-bullshit mindset completely for free and with a heavy focus on self-hosting, decentralization and ease of use.
At a glance
- What is it?
- DCTS (Direct Communication Through Sockets) is an AGPL-3.0 JavaScript chat platform with a desktop client, an Android app, voice and screensharing, and a plugin system. The interesting part is not the feature list but the distribution model: you run the server yourself, and the README is explicit that it is not trying to be another Discord clone.
- Who is it for?
- DCTS is for people who want to run their own chat server and are willing to own the operational consequences: Bun or Node on the host, a Docker or Pterodactyl deployment path, and an AGPL-3.0 obligation if they modify and redistribute it. It is not for anyone who wants a managed service with an uptime commitment, and it is not a drop-in replacement for a team that depends on Discord's bot ecosystem.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- 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 DCTS is aimed at, and who it is actually for
The README frames the project around independence rather than features. The stated goal is a communication platform that is independent, reliable, self-hosted and easy to use and setup, and the author explicitly writes that the goal is not to be yet another Discord alternative. That distinction matters when you evaluate it. A Discord alternative competes on features and network effects. DCTS competes on who controls the server.
The audience follows from that. This is for a group that already has a machine it can run services on and a reason to keep its conversations off someone else's infrastructure: a club, a small company, a community that has been burned by a platform shutdown or a pricing change. The README points to a public instance at chat.network-z.com, so you can look at the product before installing anything, but the public instance is not the point of the project. Self-hosting is.
The secondary audience is developers. The author describes a broad and reusable software landscape with custom-made libraries, and the repository is named dcts-shipping, which suggests this repo is the distribution or deployment side rather than the whole stack. If you want to build on the platform, the plugin and theme system is the documented extension point.
How the pieces fit: server, desktop client, Android app, and an embedded messenger
DCTS is not a single process you install and forget. The README lists a dedicated desktop client with enhanced client functionality, a mobile app for Android that is also on Google Play with the same client enhancements, and an integrated, decentralized, self-hostable messenger inside both clients. So there are at least three surfaces: the server, the desktop client, and the mobile app.
That embedded messenger is the part worth pausing on. The README calls it integrated, decentralized and self-hostable, which implies a second communication path that does not depend on the DCTS server you deployed. The material does not describe the protocol or how identities are established across that path, so treat the claim as a direction rather than a spec. If server-independent messaging is the reason you are considering DCTS, verify the mechanism in the documentation before you plan around it.
Real-time transport is in the name: Direct Communication Through Sockets. The project began, per the README, as a test about CSS and learning web sockets. The README does not document the wire protocol, the message persistence model, or how the server scales past one node. Those are the questions a self-hoster will hit first, and the supplied material does not answer them.
Encryption, voice, and what the feature list does not say
The feature list leads with encrypted server direct messages. Note the scope: the README says encrypted server DMs, not encrypted channels or encrypted everything. Anyone reading DCTS as an end-to-end encrypted messenger in the Signal sense should read that line carefully, because the topics list includes e2ee and signal while the feature description is narrower.
Voice chat is listed as working, with screensharing and camera support. That is a meaningful amount of surface area for a self-hosted deployment, and it is also where self-hosting gets expensive: voice and video traffic has different bandwidth and latency requirements than text, and the README says nothing about TURN, relay servers, or what happens when participants sit behind restrictive NATs.
The remaining items are a built-in plugin and theme system, custom-made libraries to reduce external dependencies, and a Pterodactyl egg for automated deploys alongside Docker. The Pterodactyl egg is a specific signal about the intended operator: Pterodactyl is a game server panel, and shipping an egg for it means the project expects people who want a panel-driven deploy rather than a Kubernetes manifest. The README does not describe a plugin API, a theme format, or a sandboxing model for plugins, so the extension system is currently a promise with a name.
Getting it running: the two documented paths and the runtime matrix
Installation is deliberately thin in the README. It states that a guide for setting up DCTS manually or with Docker can be found online at docs.dcts.community/Getting started, or in the repository under /docs/ in a file named Getting started.md. There are no inline install commands in the README itself, so anyone following this article should go to those two sources rather than improvise.
What the README does give is a tested-versions table, and it is more informative than most. For Bun, versions 1.3.14, 1.3.11 and 1.3.5 are marked as verified. For Node, the verified list runs v24.18.0, v24.11.1, v21.7.3, v20.19.2, v18.20.2 and v16.16.0, with v12.22.9 marked as not working. That is an unusually wide supported range, spanning Node 16 through 24, and it tells you the codebase has not hard-depended on a recent runtime feature. It also means the maintainer is testing across versions, which is a maintenance cost the project has chosen to carry.
For deployment, the README names Docker and a Pterodactyl egg for automated deploys. It does not name a Compose file, an environment variable list, or a database requirement. Those details live in the Getting started documentation, and until you read it you cannot estimate the resource footprint of a deployment.
Where DCTS is the wrong tool
The clearest limitation is operational. A self-hosted chat server is a service you now own. Text is cheap to host; voice chat with screensharing and camera is not. The README claims working voice and screensharing but does not describe the media path, relay requirements, or capacity planning. If your group relies on voice as the primary channel, the absence of that documentation is a real risk, not a documentation gap you can wave away.
Second, the encryption scope is narrower than the topic tags imply. Encrypted server DMs are not the same as encrypted group channels, and the README does not state what the server can see. If your threat model includes the server operator, and you are the server operator, that is a different conversation than if you are trusting a third party.
Third, ecosystem. Discord's value is largely in bots, integrations and the fact that everyone already has an account. DCTS offers a plugin and theme system, but the README does not document a plugin registry, a marketplace, or any third-party plugins. Migrating a community that depends on a dozen bots means rewriting that tooling or doing without it. The README's own framing, that the goal is not to be another Discord alternative, is an admission that this is not a like-for-like swap.
What you would compare it against, and how the approaches differ
The honest comparison for a team that wants self-hosted chat is Matrix, typically with Element as the client. The architectural difference is federation. Matrix is designed so that separate homeservers exchange messages, which means your users can talk to users on other servers without either side running the other's software. DCTS, based on the README, is a server you deploy and clients you point at it, with a separate self-hostable messenger embedded in the clients. The README does not describe server-to-server federation between DCTS instances, so the decentralization appears to operate at the level of who runs the server, not at the level of a shared network.
That difference has practical consequences. Federation buys interoperability and costs complexity: room state resolution, server ACLs, and a much heavier deployment. A single-server model is simpler to operate and simpler to reason about, and it fails more cleanly, but it also means your community is exactly as reachable as your one server is available.
A second comparison is a plain self-hosted Mattermost or Rocket.Chat instance. Those target organisations with channels, roles and compliance features, and they assume an admin. DCTS targets a smaller, more informal group and spends its complexity budget on clients and voice instead. If you need audit logs and retention policy, the DCTS README does not mention them.
Licence, maintenance and the cost of running your own copy
DCTS is AGPL-3.0. The practical consequence for a self-hoster who runs it unchanged is minimal: you are using the software, not distributing it. The obligation becomes relevant if you modify DCTS and let users interact with it over a network, because the AGPL's network clause is designed to require source disclosure in that case. This is a description of the licence's intent, not legal advice; if you plan to fork and host a modified version for others, get your own reading.
The AGPL also explains the project's stance on funding. The README states that DCTS accepts only donations and no investors, and explicitly rejects FOMO-style tactics and artificial perks. That is consistent with a licence that makes a proprietary hosted business awkward.
Maintenance cost is visible in the release history. Three releases are listed within four days in September 2026: v1.2.5.2, then v1.2.5.7 described as a fix for v1.2.5.2, then v1.2.7.3. A patch release that exists to fix the release three days earlier is a normal cadence for a young project, and it also means you should not treat any single version as a long-term stable target. The version numbering itself, four components deep, suggests frequent small increments rather than a slow release train.
The supported-runtime table adds a second maintenance dimension: the project verifies against six Node versions plus three Bun versions. That breadth is convenient for adopters and expensive for the maintainer. If that table shrinks in future releases, older Node deployments will be the first to lose coverage.
Editorial conclusion
DCTS is for people who want to run their own chat server and are willing to own the operational consequences: Bun or Node on the host, a Docker or Pterodactyl deployment path, and an AGPL-3.0 obligation if they modify and redistribute it. It is not for anyone who wants a managed service with an uptime commitment, and it is not a drop-in replacement for a team that depends on Discord's bot ecosystem. Before committing, read docs.dcts.community/Getting started and the Getting started.md file in the repository's /docs/ folder, then check the Tested Versions table against your runtime: Node v12.22.9 is marked as unsupported, and the newest verified Node line in the README is v24.18.0.
Community notes