For anyone testing the beta, the two lower-level changes are probably the ones most worth poking at before the 15 October release, since they’re the ones most likely to break things silently rather than visibly:

• Rust coreutils is now complete, including cp, mv and rm. If you have backup scripts, deploy scripts or anything that parses the output of these tools or relies on less common GNU flags, run them on the beta now and report differences upstream to uutils. Behaviour differences in edge cases (symlinks, sparse files, odd permissions, error messages) are exactly what a beta is for.
• dbus-broker replacing dbus-daemon: mostly invisible, but if you have custom D-Bus policy files or services that do unusual things on the session bus, it’s worth checking the journal for warnings after login.

The OOM change (core desktop processes getting lower OOM scores) sounds like a genuine quality-of-life fix for anyone who’s had the whole session killed while a browser ate all the RAM.

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.

I do, but with a few tweaks that cut most of the junk the other comments mention:

• Point Contact: at a dedicated alias, not your main inbox, and filter it hard. If the noise gets bad you can drop the alias without touching anything else.
• Add a Policy: line linking to a short page that says plainly there is no bug bounty and no payment for reports. Most beg-bounty mails are mass-sent with a payment ask, so this gives you something to point them at and lets you bin them without guilt.
• Don’t forget Expires:, it’s actually required by RFC 9116 and a lot of hand-written files leave it out. Set a calendar reminder to bump it.
• Serve it at /.well-known/security.txt; the root path is only a legacy fallback.

Whether it’s worth it for a homelab is debatable, but if you host anything other people rely on (a Matrix/Lemmy instance, a shared Nextcloud), having one real contact path beats someone finding a hole and having nowhere to send it.