# Cinny: a Matrix client built for a quiet, modern interface

> Cinny is an AGPL-3.0 React client for Matrix that trades feature sprawl for a calmer layout. It self-hosts as static files or a Docker image, but its own SDK migration has frozen outside pull requests.

**cinnyapp/cinny** — Yet another matrix client

- Repository: https://github.com/cinnyapp/cinny
- Website: https://cinny.in
- Stars: 3,914 · Forks: 583
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/cinnyapp-cinny

## What Cinny is for, and who ends up using it

Cinny describes itself as "a Matrix client focusing primarily on simple, elegant and secure interface", with the stated goal of an instant messaging application that is easy on people and has a modern touch. That sentence is the whole product thesis. Matrix already has clients that expose rooms, spaces, threads, widgets, bridges and moderation controls side by side. Cinny takes the opposite position: the interface is the feature.

The audience follows from that. Someone who runs a small Matrix homeserver for a team, a club or a family and wants a link they can hand out without a tutorial. Someone who self-hosts services already and treats a chat client as one more static site behind nginx. Someone who finds the density of a full-featured client tiring on a laptop screen.

It is a poor fit for the opposite profile. If you administer a large homeserver and need per-room permission editing, custom widgets or deep moderation tooling in the client, Cinny's restraint works against you. The README does not present it as an admin console, and nothing in the repository layout suggests one.

## The architecture: a Vite bundle, a config.json, and a webserver doing the routing

Cinny is a TypeScript React application built with Vite. The package.json scripts are the ordinary trio: `vite` for the dev server, `vite build` for the production bundle, `vite preview` to serve that bundle locally. Styling uses vanilla-extract, data fetching uses TanStack Query, and virtualisation for long lists comes from TanStack Virtual. There is no server component in this repository. The build output is a `dist/` directory of static assets.

That shapes the deployment model. The runtime configuration lives in `config.json`, which the README says defines the default homeservers and the explore pages. Because the app is a single-page application, the webserver must rewrite unknown paths back to the index. The README points at three example configurations: netlify.toml, contrib/nginx/cinny.domain.tld.conf and contrib/caddy/caddyfile.

If you cannot or will not configure those rewrites, config.json line 35 enables hash routing. The trade-off is visible in the URL: the browser shows `/#/` between the domain and the channel, so `app.cinny.in/#/home/` instead of `app.cinny.in/home/`. Ugly URLs in exchange for a webserver you do not have to touch. That is a reasonable escape hatch and the README presents it as one.

Deploying under a subdirectory is a second, harder constraint. The README states you must rebuild the app yourself after updating the `base` path in build.config.ts. To serve at `https://cinny.in/app`, you set `base: '/app'`. There is no runtime flag for this; it is baked into the bundle at build time.

## Self-hosting Cinny: tarball or Docker, then a first login

The README gives two routes. Download the tarball from GitHub releases and serve the files from `dist/` with your preferred webserver, or pull the Docker image from DockerHub or the GitHub Container Registry. The repository also contains a Dockerfile, and it is a two-stage build: a Node builder runs `npm ci` and `npm run build`, then the result is copied into an nginx image and symlinked to `/usr/share/nginx/html`.

To build that image yourself from a clone of the repository:

```bash
docker build -t cinny .
docker run --rm -p 8080:80 cinny
```

The container serves the compiled app on port 80, mapped here to 8080 on the host. Open `http://localhost:8080` and you should see the Cinny login screen. The homeservers offered on that screen come from config.json, so if your own homeserver is not listed, add it there before building or edit the served copy.

For a local development build instead, the package.json scripts are the entry point:

```bash
npm ci
npm start
```

The dev server is Vite's, and the README notes that the `dev` branch is continuously deployed at dev.cinny.in, with the warning that it could have things broken. Treat the branch as a moving target and pin a release tag for anything you expose to users.

If you serve the tarball manually, the redirect configuration is the step people get wrong. The README supplies working examples rather than a specification, so start from contrib/nginx/cinny.domain.tld.conf and change the server name and certificate paths.

## The SDK migration has paused outside contributions

The most consequential fact in the README is not about the interface. It is a boxed notice stating that the project is in the process of replacing matrix-js-sdk with its own SDK, and that as a result no pull requests will be accepted until further notice. The notice links to issue 257 for context.

For anyone evaluating Cinny as infrastructure, that changes the calculus. You can still fork it, patch it and run your fork. What you cannot currently do is send a fix upstream and expect it to land. If your organisation requires that its patches go into the canonical repository, or if you depend on a specific bug being fixed by a maintainer, this is a real blocker rather than a stylistic concern.

It also means the dependency surface is in motion. The package.json still lists matrix-js-sdk among its dependencies at version 4.12.7, so the replacement is not finished as of that release. Anyone planning a long-lived deployment should expect the client's Matrix layer to change shape across releases, and should read the release notes for each version rather than assuming compatibility.

The release cadence itself looks steady: v4.12.3 on 2026-06-22, v4.12.6 on 2026-08-01 and v4.12.7 on 2026-09-15. The last push to the repository was on 2026-09-21. The code is moving even while the contribution door is closed.

## Cinny compared with Element: fewer surfaces, less to configure

The obvious comparison is Element, the Matrix client most people meet first. The difference is not protocol support; both speak Matrix. It is what each client puts on screen and how much of the homeserver's configuration surface it exposes.

Element is the reference implementation in practice, and it carries the weight of that role. Spaces, threads, widgets, calls, cross-signing and device verification all have visible UI, and the settings tree reflects years of accumulated options. Cinny's README claims the opposite priority: simple, elegant, secure, easy on people. In practice that means fewer panels and a layout closer to a mainstream messenger.

What you give up is the long tail. If your workflow depends on a widget embedded in a room, or on inspecting device verification state in detail, check that Cinny covers it before you migrate a community. The README does not enumerate which Matrix features are implemented, and this review cannot confirm the list. That absence is itself worth noting: for a client whose selling point is a curated subset, a feature matrix would be the most useful document it could publish.

On the desktop there is a separate project, cinny-desktop, which the README points to for the desktop app. That is a different repository with its own release process, so desktop users are not tracking the same version numbers as the web app.

## Licence and the cost of staying current

Cinny is licensed under AGPL-3.0-only. The README carries the copyright line "Copyright © 2024 to present Ajay Bura" and points to the GNU licence text. The practical consequence of the AGPL for a self-hoster is the network clause: if you modify the client and let users interact with it over a network, the licence's terms attach to that modified version. Running the unmodified build behind your own domain is the ordinary case and the one most deployments will be in. This is a description of the licence, not legal advice; if you plan to modify and redistribute, read the licence text or ask counsel.

Upgrade cost is low by design. There is no database and no server-side state in this repository, so an upgrade is a new `dist/` directory or a new image tag. The friction sits in two places. First, config.json is yours, so a new release may add keys you want and your edited copy has to be reconciled. Second, the SDK replacement means the client's internals will shift across the 4.x line, which matters more if you maintain a fork than if you deploy the upstream build.

If you deploy on a subdirectory, remember that build.config.ts is also yours, and a rebuild is required for every upgrade. Set that expectation before you pick the URL.

## Conclusion

Adopt Cinny if you want a Matrix client your users can read at a glance, and you are willing to serve static files or run the nginx Docker image yourself. Do not adopt it if you need to land patches upstream right now, since the README states pull requests are not being accepted while matrix-js-sdk is replaced by the project's own SDK. Before deploying, verify the redirect rules for your webserver against contrib/nginx/cinny.domain.tld.conf, contrib/caddy/caddyfile or netlify.toml, and decide whether you need hash routing from config.json.

## FAQ

### What exactly is Cinny?

Cinny is a Matrix client, described in its README as focusing primarily on a simple, elegant and secure interface, with the goal of an instant messaging application that is easy on people and has a modern touch. It is written in TypeScript and licensed AGPL-3.0-only.

### Can I download Cinny?

Yes. The README says the web app is available at app.cinny.in and updates on each new release, and that you can download the desktop app from the cinny-desktop repository. For self-hosting, it points to the tarball on GitHub releases, the DockerHub image and the GitHub Container Registry.

### What does the Cinny name mean?

The repository does not explain the origin of the name. The README only uses it as the project title and in the copyright line, so there is nothing to confirm a meaning or an abbreviation.

### How does Cinny compare with Element?

Both are Matrix clients, so the difference is presentation rather than protocol. Cinny's README states its main goal is an interface that is simple, elegant and easy on people, while the README does not publish a feature list to compare against, so check the specific Matrix features you rely on before switching a community over.

### Is Cinny a Discord alternative?

Cinny is a client for Matrix, not a chat service of its own, so using it means having a Matrix account on some homeserver. It can occupy the same place in a workflow as Discord, but the README does not describe any Discord bridging or import, and none appears in the repository layout.

## Sources

- [cinnyapp/cinny on GitHub](https://github.com/cinnyapp/cinny)
- [License: AGPL-3.0](https://github.com/cinnyapp/cinny/blob/dev/LICENSE)
- [Project website](https://cinny.in)
- [README](https://github.com/cinnyapp/cinny/blob/dev/README.md)
- [Releases](https://github.com/cinnyapp/cinny/releases)

---

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