slskd: a daemon for the Soulseek network with a browser on the front

Why a daemon instead of a desktop client

The repository describes slskd as a modern client-server application for the Soulseek file-sharing network, and that split explains the whole design. The official Soulseek client is an interactive desktop program tied to the machine it runs on. slskd moves the protocol handling into a long-lived process and puts a browser UI in front of it, so the same instance can be reached from a laptop, a phone or a server you administer elsewhere.

The README makes the security stance explicit: slskd is designed to be exposed to the internet, and everything is secured with a token you control. Reverse proxy support is documented separately, which matters because the project expects to sit behind whatever you already run, whether that is Caddy, nginx or something else.

The feature set goes past search. The README claims slskd can do almost everything the official client does: browse user shares, join chat rooms and privately chat with other users. Download management is the part that got the most UI attention, with speed and status grouped by user and folder, a progress bar you click to fetch your place in the queue, and selection tools for cancelling, retrying or clearing completed downloads. Search results can be sorted, filtered and dismissed, so a noisy result set does not become a wall of things you do not want.

Three ports and what each one is for

The Docker quick start is the clearest description of the process layout, because the port mapping is the architecture:

docker run -d \
  -p 5030:5030 \
  -p 5031:5031 \
  -p 50300:50300 \
  -e SLSKD_REMOTE_CONFIGURATION=true \
  -v <path/to/application/data>:/app \
  --name slskd \
  --user 1000:1000 \
  slskd/slskd:latest

Port 5030 is HTTP for the web UI. Port 5031 is HTTPS using a self-signed certificate, which means your browser will warn you on the first visit unless you trust or bypass it. Port 50300 is the listener for incoming connections from other Soulseek users, and it is the one that must be reachable if you want others to connect to you.

Two details in that command are easy to skim past. The `--user 1000:1000` sets ownership on the mounted volume, and the README gives an equally valid alternative using `PUID` and `PGID` in the Linuxserver style, which is friendlier if your deployment already standardises on that convention. The `SLSKD_REMOTE_CONFIGURATION` variable lets you edit application settings from the web UI, and the README says plainly that you might not want it enabled on an internet-facing installation. That is a sensible default to override rather than accept.

Compose for people who already run containers

A compose file is provided in two flavours for the same reason, user handling. This version uses the built-in user field:

services:
  slskd:
    image: slskd/slskd
    container_name: slskd
    user: "1000:1000"
    ports:
      - "5030:5030"
      - "5031:5031"
      - "50300:50300"
    environment:
      - SLSKD_REMOTE_CONFIGURATION=true
    volumes:
      - <path/to/application/data>:/app
    restart: always

The alternative swaps the `user` key for `PUID` and `PGID` entries in the environment block and changes nothing else. Either way the image is `slskd/slskd`, the data path is `/app` inside the container, and `restart: always` is set, which is what you want for something that receives incoming connections.

The Dockerfile explains a build that is more involved than a single-stage copy. Web content is built first in a `node:22-alpine` stage, because the interface is a JavaScript application, and the .NET binaries are then built in an `mcr.microsoft.com/dotnet/sdk:10.0-noble` stage using the web output as its wwwroot. The final image runs on `runtime-deps:10.0-noble` and installs `jq`, `wget`, `tini` and `gosu`, with a dedicated user created at UID and GID 1000 to match the documented compose settings. There is a health check that polls the HTTP health endpoint every 60 seconds.

Configuration: the YAML file created on first run

The binary path is the other supported route. Stable builds are published on the releases page, and the README notes that platform-specific binaries and the static web content are produced as artifacts from every build, so a canary is available if you would rather not wait for a tag. Binaries ship as zip files: extract to a directory and run.

The first run creates an application directory at `~/.local/share/slskd` on Linux and macOS, or `%localappdata%/slskd` on Windows. In the root of that directory the file `slskd.yml` is created, and that file is where you enter your Soulseek credentials and adjust settings. There is a configuration guide in `docs/` and an annotated example at `config/slskd.example.yml` in the repository, which is the file to read before editing anything.

Credentials for the web UI are separate from Soulseek credentials. The default username and password are both `slskd`, and the README tells you to change them if the application will be internet facing. Since the README also says the application is designed to be exposed, treat that sentence as the setup step rather than as optional advice. Logging in with the default credentials also completes the initial configuration.

Project signals worth checking before you commit

Activity is unambiguous. The most recent releases are 0.25.0, 0.25.1 and 0.26.0, with 0.26.0 published on 2026-07-19, and the last push was on 2026-09-20 with 192 open issues against it. The repository is not archived, and the README says new features are added all the time, which the release cadence supports.

The licence is AGPL 3.0, with a `LICENSE` file and a `NOTICE` file at the repository root. For a personal server that changes nothing. If you modify slskd and serve the modified version to other users, the AGPL's copyleft terms are the thing to think about, and that is a question for whoever handles licensing at your organisation rather than for a review of the source.

The tree is a normal .NET solution layout: `slskd.sln`, `src/`, `tests/`, `bin/`, `config/`, `docs/` and `etc/`, plus `SECURITY.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` and a `FORKING.md` that signals whether the project expects forks to go through a process. The `docs/` directory is where the operational answers live: configuration, Docker notes and the reverse proxy guide are all separate documents rather than sections of the README.

Editorial conclusion

slskd is the right choice if you want the Soulseek network reachable from a browser, from a server, or from several devices at once, because that is the entire premise of the client-server split. It is the wrong choice if you want the desktop experience of the official client without thinking about it. On first run, change the default `slskd` credentials before exposing anything, decide whether to leave `SLSKD_REMOTE_CONFIGURATION` enabled, and read `docs/config.md` before editing `slskd.yml` by hand. The AGPL 3.0 licence matters if you plan to modify it and serve the result.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. slskd/slskd on GitHub