For your points 2 and 3 specifically: if you go the Icecast route (AzuraCast also uses Icecast under the hood), Icecast can require a username and password per mount point, so the stream URL alone is useless to anyone who stumbles on it, and you can give the mount a bland name. Put it behind HTTPS on your reverse proxy so the password isn’t sent in clear text.

For point 4 (genres at certain times), AzuraCast’s playlist scheduling handles that from the web UI. If you build it yourself instead, Liquidsoap can switch playlists by time of day, but it’s a scripting language with a learning curve.

If what you really want is your own library rather than one stream everyone hears at the same time, the Navidrome suggestion is simpler: separate logins and plenty of Subsonic apps on Android.

Adding to why it has to be reachable: when a local user follows someone on another server, that server pushes new posts to your server’s inbox, so the remote side has to be able to resolve your domain and connect over HTTPS. A LAN-only box can’t receive that.

The least painful compromise is a cheap domain (or a subdomain you control) plus a tunnel or a small VPS acting as reverse proxy, so nothing on your home network is exposed directly. Then close signups so only your household can register. If Mastodon feels heavy for a handful of users, GoToSocial is much lighter on RAM for that use case, though you’d use a separate client app with it.

One thing to decide up front: the domain is baked into every account and can’t be changed later without starting over.

Nice find. One thing to check before buying parts: the README says it works with line-level sources through a USB audio adapter. Most turntables output phono level, so unless yours has a built-in preamp (look for a PHONO/LINE switch on the back), you’ll need a phono preamp between the deck and the USB adapter. Without it the signal is very quiet and has no RIAA equalisation, so it sounds thin.

Also, AirPlay buffers for a couple of seconds, which is fine for listening, but you’ll notice the delay if you’re standing next to the speakers while dropping the needle. The automatic start/stop on signal detection is the clever part for a turntable.

Adding to the Workers theory: if it is a Worker, Cloudflare adds a CF-Worker request header to every subrequest a Worker makes, and its value is the zone the Worker belongs to (e.g. something.workers.dev or the owner’s own domain). It’s not something the script can strip, so if you add that header to your reverse proxy’s log format you should be able to see exactly whose Worker is probing you.

That gives you two practical options: report it through Cloudflare’s abuse form with the zone name (they do act on Workers being used for scanning), and/or drop any request that carries a CF-Worker header at the proxy, since nothing legitimate should be hitting a DNS-only Lemmy host through a Worker anyway. Federation traffic from other instances won’t have it.

Nice, this is one of those automations that pays for itself the first winter. Two small things that might make it nicer to live with:

The loop with the namespace can be a one-liner, and you can limit it to the next couple of days so a cold snap six days out doesn’t nag you every morning all week:

{{ (daily['weather.forecast_home'].forecast[:2]
    | map(attribute='templow') | min) < minTemp }}

And to stop repeat alerts once you’ve actually done the work, pair it with an input_boolean like outdoor_water_winterized: add it as a condition (only notify when off), send the notification with an actionable button (“Done”) from the companion app, and have the button event flip the boolean on. Then a second automation turns it back off when the forecast lows climb above, say, 8 °C for a few days in spring. That also covers curbstickle’s point if you ever add more taps, one boolean per tap.