I would propose:
Notify of available updates on every login.
Automatically update (critical) security updates.
Do not automatically update (major) versions of products liable to cause havoc.

Most server systems have quite infrequent logins, so above would be acceptable midway.

i like the idea of seeing what updates are needed on login.
Since this is a server I wouldn't automatically install any updates. A service might need to be restarted after the updates.

i like the idea of seeing what updates are needed on login.
Since this is a server I wouldn't automatically install any updates. A service might need to be restarted after the updates.

We sort of already have this, since we install Cockpit's package management tool by default, which will always show pending updates.

It's really not common to log directly into a server unless something is going wrong. A better solution for managing updates would be to use something like Red Hat Satellite, but I'm not sure if that has full support for Fedora Server. It's worth looking into.

Cockpit probably provides the best avenue to get a list of available updates in a way that a user can see without having to do more work to get it set up. The dnf5-plugin-automatic package is invisible behind the scenes and requires deliberate attention.

Even if you pull in dnf5-plugin-automatic as an installed package you must enable the dnf5-automatic.timer after it is installed. Even then, the configuration is blank on install, and the default behavior is to quietly download the updates in the background.

...which is all well and good until you run into someone with a metered connection or a bandwidth cap. Unfortunately, this scenario is way more common than anyone wants to believe. The last thing we want is to be causing surprise distress to our users.

To that end, given the potential pitfalls of automatic update downloading without alerting the user AND the fact that you have to deliberately enable the service timer anyways, I feel it's not worth the squeeze to include this package by default. Someone could write a really cool blog article about it to generate exposure and interest, but it currently is (and should remain) an opt-in experience.

I enabled it (via cockpit) on my server install, but I also am not on a metered connection. Automatic updates are something that should be considered on a case by case basis by the end user, and not something that is forced upon the user. I agree that this should be a deliberate opt-in setting rather than a default.

The blog article about it is a good idea to bring attention to it.

If the current behavior only refreshes the package list and shows you what could be installed, I'm in favor of keeping that, it could be helpful in the homelab (majority of our users) to see what needs to be updated in Cockpit.

If the current behavior downloads the updates in the background, but doesn't install them until you tell it to through Cockpit, I'm not in favor of this because I agree that on slow of metered connections that would be an issue. Weekly Fedora updates are often over 600mb, and I have had many Fedora updates that are over 2GB's.

I don't use the automatic updates, because a number of my servers are not on 24/7 to conserve power use, and in the past when I have used automatic updates on those machines, I believe I left them unbootable because they shutdown during an automatic update (at least that was the only explanation I could come up with). Since going back to manual updates, I haven't updated and gotten an unbootable server.

I believe other homelab users often limit the amount of time their servers are on to conserve power usage.

It does indeed download the updates by default. I think the collective feedback between this issue thread and the matrix discussion is that we should close this as OBE. The focus for dnf-automatic is in the post-install documentation, which we can take a look at and update as necessary. We already have another issue open (more than one probably) for a comprehensive doc review.