Cicada: a self-hosted multi-user music service that ships as one binary

The problem Cicada addresses: shared listening without a third-party account

Most self-hosted music servers were built around one person's library. Add a second listener and you either share one login or run two instances. Cicada is aimed at the second case. The README describes it as a multi-user music service, with multiple user accounts and optional 2FA, and it lists sharing musicbills between users as a feature. That combination points at a household, a shared flat, or a small group of friends who each want their own queue but draw from the same collection. The privacy claim in the feature list is blunt: no privacy collection, manage data by yourself. There is no account tier, no telemetry endpoint described, and no hosted component required. If your reason for self-hosting is that you do not want a streaming service holding your listening history, the architecture matches that intent. If your reason is that you want a federated social music network, nothing in the material suggests Cicada is that.

What the single-binary build actually bundles

The feature list states that deployment is a single binary with embedded PWA assets and bundled ffmpeg and ffprobe. That is the most consequential design decision in the project, and it has two sides. On the plus side, there is no Node runtime to install, no package manager step, and no separate media toolchain to keep in sync with the server. The web client is compiled into the same executable, so you do not deploy a frontend and a backend as two services. On the minus side, a bundled ffmpeg means the version you get is the version the release shipped with. If a codec or container fix lands upstream, you wait for a Cicada release rather than updating a system package. For a music library that is mostly MP3, FLAC and AAC, that is unlikely to matter. For a library with unusual formats, it is the first thing I would check. The repository is TypeScript, so the binary is presumably a compiled artifact rather than interpreted source, but the README does not describe the build pipeline, and I have not verified what the archive contains beyond the executable named in the start command.

Starting the server: the command and the flags that matter

The README gives one deployment path: download the archive for your platform from GitHub Releases, extract it, and start the server.

./cicada start --data /path/to/cicada_data --port 8000

On Windows the same command runs as cicada.exe, with a Windows-style data path:

.\cicada.exe start --data C:\path\to\cicada_data --port 8000

Three things are worth noting. First, the subcommand is start, not a bare invocation, which suggests the binary may carry other subcommands that the README does not document. Second, --data is a required-looking path argument, and it is where the library and presumably the database live, so it should be a directory you back up and not a temporary location. Third, on first startup Cicada creates a default user and prints the username and password to the log. That log line is the only credential you get before you can reach the web interface at http://localhost:8000. Treat the first startup log as sensitive. If you are running under a process supervisor that ships stdout to a central collector, you have just published a working password. The README also points to a separate Docker deployment document for container users; it is not reproduced in the README itself, so if you plan to run Cicada in Docker, that document, not the README, is your primary source.

Where the documentation runs out

The README is a landing page, not an operator's manual. It does not describe the data model, the storage layout under --data, the supported audio formats, the import process for an existing library, or how the lyricist and composer fields are populated. It mentions a custom playqueue and shared musicbills without explaining what a musicbill is or how sharing is scoped, whether per-user, per-group, or instance-wide. There is no API reference, no configuration file format, and no documented way to reset a password or recover an account other than whatever the running server exposes. The online demo at cicada.mebtte.com with the shared cicada credentials shows the interface, which is useful for a look before you install, but a demo login tells you nothing about migration, backup, or upgrade behaviour. None of this is unusual for a project whose README doubles as a release page, but it changes how you should adopt Cicada: as a running service you learn by using, not as a documented platform you can plan against.

A genuine limitation: no documented upgrade or migration path

The release history shows three versions within about a week in early September 2026: 3.9.1, 3.9.2, then 3.10.0. A cadence like that is normal for active development, and it is also the cadence at which you will be asked to restart your server. The README says nothing about what happens to the data directory across versions. There is no stated migration step, no schema version note, and no rollback instruction. A bundled ffmpeg makes this sharper: because the media toolchain is inside the binary, an upgrade replaces it, and if a new release changes how existing files are probed or transcoded, the effect lands on your library rather than on a package you can pin. The practical consequence is that you should snapshot the --data directory before every upgrade, and you should not run Cicada on a release channel you have not tested. If you need a server that upgrades on a predictable schedule with documented migrations, this is the wrong tool, and the README gives no indication that such a schedule exists.

How Cicada differs from Navidrome and similar servers

Navidrome is the obvious comparison point for a self-hosted music service, and the difference is in packaging and in the shape of the product. Navidrome is a Go server that speaks the Subsonic API, which means a large ecosystem of existing mobile and desktop clients can connect to it, and its own web interface is one client among several. Cicada's README describes no such compatibility layer. Instead it ships its own PWA embedded in the binary, so the client and the server are one artifact and one project. That is a real trade-off in both directions. You get a consistent interface with no third-party client to configure, and you get no way to point an existing Subsonic client at it. If your phone already has a music app you like, Cicada asks you to use its PWA instead. The multi-user and 2FA features also sit differently: in an API-first server, accounts and permissions are exposed through the API and can be managed by other tools, while Cicada's account model appears tied to its own interface. Neither approach is wrong, but they attract different operators.

Licence and the cost of keeping it running

Cicada is licensed under GPL-3.0, and the README links to a license file rather than restating terms. If you run it for yourself or your household, the licence is unlikely to affect you. If you modify Cicada and distribute the modified binary, or offer it as a network service to others, the copyleft terms apply to the derivative work, and that is a question for a lawyer rather than for this article. On maintenance cost, the material supports a few concrete observations. Upgrades are binary swaps, so the labour is in testing and backup, not in dependency management. There is no separate ffmpeg to patch, which removes one recurring chore but also removes your ability to pin that component. The project is active, with releases in the days before the last push, so you should expect to track versions rather than install once and forget. The real recurring cost is the absence of documentation: every operational question, from backup layout to password recovery, has to be answered by inspecting a running instance or reading source.

Who should adopt Cicada, and what to check first

Adopt Cicada if you want a small group of people to share one music library with separate accounts, if you are comfortable running a service whose behaviour you learn by using it, and if you would rather deploy one binary than assemble a server, a database and a media toolchain. Do not adopt it if you need a documented API for third-party clients, if you need a tested migration path between versions, or if your library depends on audio formats you cannot confirm the bundled ffmpeg handles. The first thing to verify is the start command itself on your target platform, because the README gives archive instructions and delegates Docker to a separate document. The second is the data directory: confirm what Cicada writes under --data before you trust it with a library you cannot re-rip. The third is the default credential printed on first startup, which should be replaced before the port is reachable from anywhere but localhost. The demo at cicada.mebtte.com is the cheapest way to judge the interface, and the release archive is the cheapest way to judge the deployment. Both are worth doing before you move a library.

Editorial conclusion

Cicada suits a household or a small group that wants shared playqueues and per-user accounts without handing listening data to a streaming provider, and it is a poor fit for anyone who needs a documented REST API or a public community server, since none is described in the repository material. Before committing, verify three things on your own hardware: that the release archive for your platform starts with ./cicada start --data /path/to/cicada_data --port 8000, that the default credentials printed on first startup are changed immediately, and that your deployment path matches the separate Docker document rather than the README, which only covers the archive.

Official sources

1. Issues
2. License: GPL-3.0
3. mebtte/cicada on GitHub
4. README
5. Releases