# DCTS: a self-hosted chat platform built on sockets, not on someone else's cloud

> DCTS (Direct Communication Through Sockets) is an AGPL-3.0 chat server in JavaScript with desktop and Android clients, voice chat and an integrated messenger. It is aimed at people who want to run their own communication stack rather than rent one.

**hackthedev/dcts-shipping** — 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.

- Repository: https://github.com/hackthedev/dcts-shipping
- Website: https://dcts.community
- Stars: 646 · Forks: 33
- Language: JavaScript
- License: AGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/hackthedev-dcts-shipping

## What DCTS solves, and who it is actually for

The README is blunt about the goal: DCTS exists so that communication does not depend on a company that can change its terms, shut down an API or start charging. The author describes it as starting as a CSS and web sockets experiment in 2023 and turning into a serious project, and the repository now spans a server, a desktop client, an Android app and a set of custom libraries. The stated intent is independence, reliability, self-hosting and ease of setup, all free.

That framing tells you who it is for. It is for a person or a small group who is prepared to own the server: a community that has already been burned by a platform migration, a company that wants internal chat on its own hardware, or a hobbyist who enjoys this kind of work. It is not aimed at a team that wants to sign up and start typing in five minutes. The README says the project is not trying to be another Discord alternative, which is a useful signal: the feature set overlaps with Discord, but the priorities are different, and the deployment burden lands on you.

## How the pieces fit: sockets, a database, and a separate voice service

The name is the architecture. DCTS stands for Direct Communication Through Sockets, and the dependency list confirms it: socket.io for the realtime transport, express for the HTTP layer, and mysql2 for persistence. Messages flow over a socket connection rather than through polling, which is what makes the client feel immediate. The entry point is index.mjs, and package.json declares "type": "module", so the server runs as ES modules.

Voice is not handled by the same code path. The repository has a livekit/ directory and the dependencies include livekit-server-sdk, so voice chat, screensharing and camera support are delegated to LiveKit rather than implemented from scratch. That is a reasonable split: realtime media is hard, and reusing a media server keeps the chat code focused. The practical consequence is that a working voice setup means running or connecting to a LiveKit instance as well as the DCTS server.

Around the core sit several modules. There is a plugin and theme system, an example-plugin/ directory showing the expected shape, and a set of first-party packages under the @hackthedev scope (dsync-web, dsync-shop, dsync-pay, express-starter) that the author maintains to avoid depending on outside code. The Docker/ directory and a pterodactyl egg cover automated deployment. The docs/ folder is a VitePress site, which is why the devDependencies include vitepress.

## Installing DCTS and getting a server running

The README does not inline the install commands. It points to two places: an online guide at docs.dcts.community under Getting started, and the same content in the repository at docs/ » Getting started.md. Read that file before anything else, because it is the only authoritative source for the environment variables and database settings.

What the repository does tell you is the runtime. package.json sets the main entry to index.mjs and defines a postinstall hook that runs bun postinstall.mjs, and the lockfiles are bun.lock and package-lock.json. The tested versions section lists Bun 1.3.14, 1.3.11 and 1.3.5 as working, and Node v24.18.0, v24.11.1, v21.7.3, v20.19.2, v18.20.2 and v16.16.0 as working, with v12.22.9 explicitly marked as not working. So the install step is one of:

```bash
bun install
```

or, if you are on Node:

```bash
npm install
```

Either way the postinstall script runs. If it fails, the install is not complete, so watch that output rather than scrolling past it. After dependencies are in place the server starts from the entry point:

```bash
bun index.mjs
```

The README does not document the port, the database name or the required environment variables, so those have to come from docs/Getting started.md. Once the process is up, the first real use is to open the instance in a browser, create an account, and confirm that a second browser session sees a message arrive without a page reload. That single check exercises the socket layer, the database write and the session handling at once, which is more informative than clicking around the settings pages.

## The deployment burden is the real cost

Self-hosting is the selling point and also the main limitation. A DCTS instance is not one process. You need a MySQL server for storage, the Node or Bun process for chat, and a LiveKit deployment if you want the voice features the README highlights. Each of those has its own upgrade path and its own failure modes, and none of them are hidden behind a managed control plane.

The documentation is the weak point. The README links to a guide rather than containing one, and the repository's own docs folder is a VitePress site you have to build or read on GitHub. There is no rollback procedure described in the README, no backup guidance, and no migration notes for the database between the recent releases. The release history shows three versions within four days in September 2026 (v1.2.5.2, v1.2.5.7 described as a fix for v1.2.5.2, then v1.2.7.3), which is normal for an active project but also means you should read release notes before upgrading rather than pulling blindly.

There is also a licensing consideration. The project is AGPL-3.0. If you modify DCTS and let users interact with it over a network, the licence's network clause is the part to read, because it can require you to offer the modified source. That is a real constraint for anyone planning to build a hosted product on top of the code. This is not legal advice; if you are commercially deploying a modified version, get proper advice.

## When DCTS is the wrong tool

If nobody on your side is comfortable with a terminal, a database and a service that occasionally needs restarting, DCTS will become an outage you cannot diagnose. The same applies if you need guarantees: there is no stated uptime commitment, no support contract, and the project is funded by donations rather than investors, which the README states explicitly. That funding model is honest, but it means the project's pace depends on the maintainer.

It is also the wrong choice if your organisation requires federation with an existing network. DCTS is its own platform with its own clients, not a bridge into another protocol. And if your requirement is a chat tool for a few people who just need something that works today, the setup cost here is out of proportion to the benefit. A hosted service will be cheaper in time even if it is worse in principle.

## How DCTS differs from Matrix and from running Mattermost

Matrix is the closest comparison in intent. It is an open protocol with many independent server implementations that can federate, so a user on one homeserver can talk to a user on another. DCTS is not that. It is a single application with its own server, its own desktop client and its own Android app, and the README describes it as a platform rather than a protocol others implement. The practical difference is that a DCTS instance is a self-contained deployment, which is simpler to reason about but gives you no federation and no interoperability with other software.

Mattermost is the other common choice, and the difference is in shape. Mattermost is positioned as a team collaboration workspace with channels, and it is typically deployed by an IT department. DCTS comes with its own client applications, an integrated messenger, a plugin and theme system, and a pterodactyl egg for automated deploys. If you want channel-based team chat with an established admin story, Mattermost is the more conventional fit. If you want a communication platform where you also control the client, DCTS is the one that ships the client.

## Maintenance, upgrades and what the licence means in practice

The repository is not archived and the last push was on 2026-09-09, so the codebase is being worked on. The release cadence in September 2026 was fast, with v1.2.5.7 arriving two days after v1.2.5.2 specifically to fix it. Fast patch cycles are good for bugs and awkward for operators, because it means you cannot assume a version is settled just because it was published.

A sensible upgrade habit for this project is to pin the version you deploy, read the release notes for the version you are moving to, and take a database dump before you pull. The README does not describe a migration tool, so the MySQL data is your responsibility. The Docker/ directory and the pterodactyl egg reduce the work of rebuilding the application layer, but they do not manage your database for you.

On the licence: AGPL-3.0 means you can run, study and modify the software, and that if you distribute it or offer it to users over a network, the source of your modifications has to be available under the same terms. For a private internal instance this rarely matters. For a public hosted service built on modified DCTS, it very much does. Check the LICENSE file in the repository root and, for anything commercial, talk to a lawyer rather than relying on a summary.

## Conclusion

Adopt DCTS if you want a chat server you control end to end and you are willing to run MySQL, the Node or Bun process and a LiveKit instance yourself. Do not adopt it if you need a hosted service with an SLA, or if your team has no one who can read a server log. Before committing, check the Getting started guide in the docs folder against your Node version, confirm the database schema is created cleanly on a fresh machine, and verify that the mobile client can reach your instance over the network you actually use.

## FAQ

### What is DCTS?

DCTS stands for Direct Communication Through Sockets. It is a self-hosted communication platform written in JavaScript, with a desktop client, an Android app, voice chat with screensharing and camera support, and an integrated messenger. The project is licensed AGPL-3.0 and aims at independence and self-hosting rather than being a hosted service.

### Which versions of Bun and Node does DCTS support?

The README lists Bun 1.3.14, 1.3.11 and 1.3.5 as tested, and Node v24.18.0, v24.11.1, v21.7.3, v20.19.2, v18.20.2 and v16.16.0 as tested. Node v12.22.9 is marked as not working.

### Where are the DCTS installation instructions?

The README points to the online guide at docs.dcts.community under Getting started, and to the same content inside the repository at docs/ » Getting started.md. The README itself does not inline the setup steps.

### Does DCTS include voice chat?

Yes. The README lists working voice chat with screensharing and camera support. The repository contains a livekit/ directory and the dependencies include livekit-server-sdk, so voice runs through LiveKit rather than through the chat server itself.

## Sources

- [hackthedev/dcts-shipping on GitHub](https://github.com/hackthedev/dcts-shipping)
- [License: AGPL-3.0](https://github.com/hackthedev/dcts-shipping/blob/main/LICENSE)
- [Project website](https://dcts.community)
- [README](https://github.com/hackthedev/dcts-shipping/blob/main/README.md)
- [Releases](https://github.com/hackthedev/dcts-shipping/releases)

---

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