Skip to content

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

Description

@ivantitov-zd

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:

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions