Allow selecting a target version for Dokploy updates, with optional release cooldown

What problem will this feature address?

When a new Dokploy version is available, the UI currently encourages updating to the latest available version. For production self-hosted instances, updating immediately to the newest release can be risky, especially when several versions have been released since the currently installed one.

Some users prefer to run Dokploy with a controlled delay behind the latest release, for example waiting a few days or one minor/patch version before upgrading. This gives time for regressions, breaking changes, migration problems, or upgrade-related issues to be discovered before production instances move forward.

At the moment, the UI update flow does not provide enough control for this workflow. If multiple newer versions are available, users should be able to choose a specific target version instead of being pushed directly to the latest one.

Describe the solution you'd like

I would like the Dokploy update UI to support selecting the target version before starting an update.

For example, when Dokploy detects that updates are available, the update dialog could show:

• Current installed version
• Latest available version
• A list/dropdown of available versions newer than the current one
• Release date for each version
• A link to the changelog/release notes for the selected version
• Clear indication if the selected version is not the latest

This would allow users to upgrade incrementally, for example:

• from v0.27.0 to v0.27.2
• or from v0.27.0 to v0.28.1
• without immediately jumping to v0.30.x if that is the latest available version

An even better version of this feature would be an optional update cooldown setting, such as:

• "Only offer releases older than 3 days"
• "Only offer releases older than 7 days"
• "Do not suggest the latest release until it has passed a configured cooldown period"

This could be configured globally in settings, while still allowing advanced users to manually override it and update to the latest version if they explicitly choose to.

Describe alternatives you've considered

The current workaround is to avoid using the UI update flow and update manually on the server to a specific version. However, this bypasses the normal Dokploy interface and is easier to get wrong.

Another workaround is to wait manually before clicking the update button, but this still does not help when multiple versions have been released and the UI only offers the latest version.

Rollback support is useful, but it is not a replacement for controlled upgrades. In production, it is usually safer to choose a known target version before upgrading than to upgrade to the latest version first and rely on rollback only after something breaks.

Additional context

This is related to, but different from, previous requests around rollback and update behavior:

• #3169 requested the ability to roll back Dokploy to a previous version.
• #282 discussed reverting Dokploy versions and opt-in based automatic updates.
• #3667 reported problems with the UI update flow not updating correctly.

This request is specifically about controlled forward upgrades: choosing which newer version to install, and optionally delaying update suggestions through a configurable cooldown period.

The goal is to make self-hosted production upgrades safer and more predictable without requiring users to leave the Dokploy UI.

Will you send a PR to implement it?

No

The issue names no files, tests, or entry points; start by locating the Dokploy update UI and its version-selection flow. Define how available versions, release dates, changelog links, target selection, and the optional cooldown setting should work, then verify that a selected non-latest version and the configured delay are respected.