hifi puts a Tidal subscription behind an OpenSubsonic API, and says so plainly

A playback proxy, not a music library

hifi is described as Tidal music integration for Subsonic, Jellyfin and Plexamp, and the README is unusually clear about what it is and is not.

The Project Terms section states that the project is made purely for educational and personal use, intended only for listening and not for downloading, that HiFi requires a valid Tidal subscription and the team encourages users to maintain an active subscription, and that the project does not claim ownership of any music or audio content, with all rights remaining with their respective copyright holders. The last line of that section describes HiFi as a playback and control interface, for example on a Raspberry Pi, for personal, non-commercial use.

That is a coherent and unusually well drafted position for a project in this category, and it explains the architecture. hifi is not a music server that stores files you own. It is a proxy that holds your Tidal credentials and translates requests from a Subsonic style client into Tidal API calls, streaming the audio back.

The list of who the project is for says the same thing from the other direction. Tidal subscribers who do not like the official app and want more client options. Anyone who wants to try Tidal music before making a commitment. Anyone who wants to listen to high resolution lossless audio. Anyone who does not want to store terabytes of music. Anyone who wants access to over 110 million songs through their Subsonic, Jellyfin or Plexamp based client. And developers who want to build their own Jellyfin based client on top of HiFi.

The primary language of the repository is listed as Svelte, and the licence is GPL-2.0 with the text in the LICENSE file.

OpenSubsonic compatible, but only the endpoints playback needs

The API section points at the OpenSubsonic API documentation, and the section on building your own app explains the important caveat.

Hifi uses the OpenSubsonic API, but that does not mean it supports every endpoint OpenSubsonic provides. The README says hifi only supports the necessary endpoints required to play music, and it points you at the routes directory in the repository to see which ones those are. The recommended way to observe it working in practice is to connect the hifi server to Feishin.

That is a real constraint rather than a caveat in the small print. A client that expects, say, playlist management, lyrics, cover art browsing or podcast endpoints will find some of them missing, and the failure will look like a client bug rather than a server limitation.

The README also states a firm rule about Subsonic client compatibility. HiFi Subsonic compatibility will only work with the recommended Subsonic clients, and if HiFi does not work with a Subsonic client, it will not be implemented. That is a deliberate narrowing of the support surface, and it means the client list is the contract.

For Plex, the position is stated just as directly. The author says Plexamp will be supported, that it is not a new thing he just forgot to add, and that he forgot about Plex itself when moving to Jellyfin, so no other third party Plex apps will be supported. It will be exclusive to the official Plexamp app.

The Jellyfin client list is explicit, and support requests have a gate

Jellyfin support is marked as work in progress, with a note that it is developed in the author's free time and that the next major update is Jellyfin support and nothing else, so there is no actual ETA.

Despite that, the README lists a set of Jellyfin music clients that will continue to be compatible from the day one release and remain fully functional unless the app itself is broken. The list includes fintunes, finamp, streamyfin, feishin, symfonium, Jellyswarrm, Foxy-Desktop, jelly-app, Tauon, bloodin, iPlay, supersonic and Jellify-Music App.

The stated reason they all work is that they all use Jellyfin's API. The author goes further and says all other clients should work as well for the same reason, and that if they do not, they will eventually be made to work.

What is unusual is the process around support requests. If you want support for a specific Jellyfin music app, the README says to open an issue, and before doing so to check the HiFi proposal check guide, and that anything else that comes without a proposal check will be rejected. There is an image for the proposal check in the README.

That is a heavy process for a request like this, and the reason is visible in the terms. Every client you add is a client you are implicitly endorsing for the catalogue access the project provides. A written proposal is how the author decides which ones are worth carrying the compatibility burden, and the guide is the screen for that decision.

The Go service, the valkey dependency and a deliberately small dependency list

The repository layout shows a Go backend with a Svelte frontend. There is main.go, a routes/ directory, a middleware/ directory, a types/ directory, a config/ directory, a web/ directory and a worker/ directory, plus a Dockerfile, a package.json with a pnpm lock file, and a SECURITY.md and CONTRIBUTING.md.

The go.mod file carries a comment that explains the dependency philosophy, and it is worth quoting in spirit: avoid using external libraries where possible, except for the one below, because the author does not want to reinvent the wheel.

The direct dependencies are two. github.com/alexedwards/argon2id at version 1.0.0, which is a password hashing library, and github.com/go-co-op/gocron/v2 at version 2.18.0, which is the scheduler. There is also github.com/valkey-io/valkey-go at version 1.0.72, brought in on its own require line, which is the Redis compatible client for Valkey.

So the architecture is a Go service with a job scheduler, a cache or queue in Valkey, and argon2id for credential handling. The go directive is 1.25.3.

The frontend side is small by comparison. The package.json lists two runtime dependencies, the Svelte marquee component and minidenticons, plus svelte-render-scan as a dev dependency. There is no frontend framework in the list, which suggests the web UI is built with Svelte's own tooling rather than a larger meta framework, and a pnpm lock file is used for the JavaScript side.

Building it, and the Dockerfile that ships one binary

The Dockerfile is short and shows the whole build.

FROM golang:1.25.3
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod tidy
COPY . .
RUN go build -o hifi-proxy .
CMD ["./hifi-proxy"]

The dependency files are copied and tidied first so that layer caches across source changes, then the rest of the tree is copied and the binary is built as hifi-proxy. That binary name is worth noting, since the project is called hifi and the artefact is not.

The quickstart in the README starts with the prerequisites: install the latest Go version, and install Git. Then you obtain the managed server values from a gist the README links to, and clone the repository.

 git clone https://github.com/sachinsenal0x64/hifi

followed by resolving the module dependencies with go mod tidy, and then exporting the environment variables the service needs, where the visible portion of the snippet shows a MANAGE_HOST assignment and the start of a TIDAL_HOST one.

The README says hifi runs on port 8080, or 5000, or 5005 by default, and shows what a successful start looks like in the logs, with an INFO line saying it is running in MANAGED mode and another reporting the API server host, port and url, for example 127.0.0.1 on 8080.

The MANAGED mode line matters, because there are two ways to run this. The Installation section for Managed HiFi points at the hosted service, with a note that if spam bots abusing the managed server are detected, users will be banned. The alternative is the self-hosted path, with a note that the managed server is designed for individual users while the self-hosted setup includes the WebUI, multi-member support and full database integration, and that multi-member and user customization on the managed server are planned for the future.

The roadmap is four unchecked boxes

The Roadmap section of the README is four unchecked items, and reading them tells you where the project is going.

Easy Installer, described as self-hosted HiFi. Jellyfin Integration. Plexamp Integration. And a recommender system.

All four are unchecked. Given that the Jellyfin support section is marked work in progress and the Plexamp section says support is coming, the roadmap is a list of intent rather than a delivery record.

The recommender system is the most interesting of the four, and the least defined. Nothing in the README describes what it would recommend from, what it would recommend, or how it would run. It sits in the same list as installer work, which suggests it is an idea at the same stage.

The easy installer entry is arguably the most consequential for adoption. A self-hosted Go service with a manual clone, a go mod tidy, environment variables and a managed-server credential gist is a fair amount of setup for a first-time user, and a single installer would remove most of that friction. The fact that it is still unchecked is the clearest signal about the current state of the project.

For context, the repository is not archived and the last push was on 2026-09-14, and there are no GitHub releases, so the project ships as a moving main branch plus a Docker image rather than as versioned artefacts.

What the README does not say, and what to check before you deploy

There are gaps in the documentation that a careful adopter should notice.

The quickstart snippet is cut off mid-line in the visible README, at the point where the environment variables are being set, so the full set of variables the service expects is not shown there. The names that are visible are MANAGE_HOST and TIDAL_HOST, and the managed server values gist is where the credentials are said to come from, but the complete configuration surface, including what the self-hosted mode needs instead, is not enumerated.

The API section points at the OpenSubsonic documentation rather than describing hifi's own endpoints, and the route list is something you have to read in the repository. The supported Subsonic clients are named only by a link to an anchor in the README, and the Jellyfin client list is long but not described in terms of which features work.

There is also a practical question the README does not answer, which is where the audio is served from and how a Tidal account is bound to a hifi instance. The terms section says the project requires a valid Tidal subscription, and the managed values gist is where the server side is configured, but the mechanism of how a user authenticates against their own Tidal account is not spelled out in the visible text.

None of these gaps make the project unusable. They make it one where you should read the repository rather than only the README, and where the terms and the supported client list matter as much as the code. A self-hosted media proxy that holds a paid streaming credential is not something to install on a whim and forget about.

Editorial conclusion

Adopt hifi if you already pay for Tidal, want to stream lossless audio through the self-hosted clients you prefer, and are willing to run a Go service that holds your Tidal credentials. Do not adopt it if you want a self-hosted library of your own files, since hifi is a playback and control interface rather than a media server, and do not expect third party clients beyond the supported list to be maintained for you. Before you deploy, read the project terms, check the recommended Subsonic clients list in the README, and confirm the ports and the managed versus self-hosted mode before you point a client at it.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. sachinsenal0x64/hifi on GitHub