Navidrome Music Server VS Caddy

My primary way to play music is from my self-hosted navidrome[1] server with my collection of albums I've mostly purchased from bandcamp. I can stream it to many different devices at home or on the go.

But sitting next to my bed is a Walkman (actually a $10 Jensen version) with a few of my favorite cassettes in the nightstand drawer. Granted, I listen to raw black metal, so the format fits the music well, but I really enjoy just popping in a cassette and hitting play. When I "metaltate", I listen to full albums and do not want to ever be interrupted or have skipping audio due to bluetooth or anything else. It is a really simple and great experience.

Would I ever take my walkman with me or want to carry around a bunch of tapes on a trip? Of course not! But it does have a time and place that is valuable.

When friends come over, we use either vinyl or my custom built RFID cards. There is more of a ceremony to digging through a physical stack of albums and being forced to listen to the album front to back.

[1] https://www.navidrome.org/

Basically, you run a server on your Mac that scans your music collection and "broadcasts" it to the network (LAN or WAN) via either the venerable UPnP/DLNA[1] family of technologies or the newish Subsonic API[2]. Of course, there are others, like DAAP or AURA, etc..

From there, you need to point a compatible player to said server to play your music on any supported device.

If you want to listen to your music on the go, pairing a Subsonic-compatible server on your Mac and a Subsonic-compatible app on your iPhone is probably the way to go. On the server side, I have only used the original Subsonic[3], which was good, but Navidrome[4] seems to be OK. But be aware that the whole "scene" is super messy and fragmented, with the usual abandoned forks of open source alternatives of everything.

Note that this means opening your local network, which comes with its own complexity.

This r/selfhosted thread[5] should give you an idea.

My use case is slightly different. I only care about streaming to my Denon CEOL mini system, which only supports UPnP/DLNA, so my current setup is:

- All my music is stored on a 2011 Mac Mini,

- I use Kazoo Server[6] (not perfect but reliable) to stream it to my audio system,

- which I control via the HEOS app provided by Denon.

Whatever stack you choose, make sure your files are tagged correctly and consistently.

[1] https://en.wikipedia.org/wiki/DLNA

[2] http://www.subsonic.org/pages/api.jsp

[3] http://www.subsonic.org/pages/index.jsp

[4] https://www.navidrome.org/

[5] https://old.reddit.com/r/selfhosted/comments/pz9dpb/lets_mak...

[6] https://docs.linn.co.uk/wiki/index.php/Kazoo_Server_setup_Ma...

[Scanner] Fix Windows scanner (#2633). Thanks @caiocotts

EDIT: This version has a bug when running on Windows that breaks your database! I deleted the Windows binary from the download page and will publish a fix very soon. For details see: https://github.com/navidrome/navidrome/issues/2630

Jellyfin is great for movies & shows. As an anecdote, it's not so good for music if you're a collector. I personally use Navidrome for that[0].

Anyway, Sonarr[1] makes use of .NET, too. Very reliable software, in my experience.

[0]: https://github.com/navidrome/navidrome

I am running ND via the docker container (deluan/navidrome:latest which is 0.49.3 (8b93962f) at the time of this writing) and interact with ND using the web interface.

No, look at the associated unit test: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4...

If that test fails we could serve PHP source code instead of having it be evaluated, a major security flaw.

However, it's very unlikely that .NET developers will directly expose their Kestrel-based web apps to the internet. Typically, we use other popular web servers like Nginx, Traefik, and Caddy to act as a reverse-proxy in front of Kestrel for various reasons:

I think that recompiling with upgraded Go will not solve the issue. It seems Caddy imports `golang.org/x/net/http2` and pins it to v0.22.0 which is vulnerable: https://github.com/caddyserver/caddy/issues/6219#issuecommen....

Caddy [1] is a single binary. It is not minimal, but the size difference is barely noticeable.

serve also comes to mind. If you have node installed, `npx serve .` does exactly that.

There are a few go projects that fit your description, none of them very popular, probably because they end up being a 20-line wrapper around http frameworks just like this one.

[1] https://caddyserver.com/

Each app’s front end is built with Qwik and uses Tailwind for styling. The server-side is powered by Qwik City (Qwik’s official meta-framework) and runs on Node.js hosted on a shared Linode VPS. The apps also use PM2 for process management and Caddy as a reverse proxy and SSL provisioner. The data is stored in a PostgreSQL database that also runs on a shared Linode VPS. The apps interact with the database using Drizzle, an Object-Relational Mapper (ORM) for JavaScript. The entire infrastructure for both apps is managed with Terraform using the Terraform Linode provider, which was new to me, but made provisioning and destroying infrastructure really fast and easy (once I learned how it all worked).

So I dug a little deeper and came across this gem: Caddy. Caddy is this fantastic, extensible, cross-platform, open-source web server that's written in Go. The best part? It comes with automatic HTTPS. It basically condenses all the work our scripts and manual maintenance were doing into just 4-5 lines of config. So, stick around and I'll walk you through how to set up an automatic SSL solution with Caddy, Docker and a Node.js server.

Let's use Caddy which can act as reverse-proxy with automatic HTTPS coverage.

Even if it may be simple, it doesn't handle edge cases such as https://github.com/caddyserver/caddy/issues/1632

I personally would make the trade off of taking on more complexity so that I can have extra compatibility.

One of the most heavily used Russian software projects on the internet https://www.nginx.com/blog/do-svidaniya-igor-thank-you-for-n... but it's only marginally more modern than Apache httpd.

In light of recently announced nginx memory-safety vulnerabilities I'd suggest migrating to Caddy https://caddyserver.com/