Dokploy / Dokploy/dokploy

[Feature Request] Add Severity & Importance Indicators to the Update UI

Open
#5,485 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
TypeScript
Stars
37.4k
Forks
3k
Avg merge
1d 3h
Merged PRs (30d)
73

Description

What problem will this feature address?

The current “Update Available” UI does not clearly communicate the severity or importance of an available update.

Image

Not all updates have the same priority. An update may contain new features, bug fixes, performance improvements, breaking changes, infrastructure changes, compatibility fixes, or security fixes.

Currently, there is no clear visual distinction between these different levels of importance. As a result, users may not immediately understand whether an update can be safely postponed or requires more immediate attention.

A clear severity indicator would make the update experience more informative and help users prioritize updates without adding unnecessary complexity.

Describe the solution you'd like

Introduce a generic update severity/importance system using badges and contextual colors directly in the update UI.

For example:

  • 🟢 Normal — Update Available
  • 🟡 Important — Important Update
  • 🟠 High — High Priority Update
  • 🔴 Critical — Critical Update

The severity could be visually represented through the badge, indicator dot, border, icon, notification component, or another element consistent with Dokploy's existing design system.

Ideally, clicking or expanding an update could also display a short explanation of why the update has been assigned that severity.

The release metadata could expose a simple standardized value such as:

severity: normal
severity: important
severity: high
severity: critical

The UI could then automatically adapt the badge, color, icon, and messaging based on this value.

The system should remain generic rather than security-specific. Security fixes are an important use case, but severity could also reflect:

  • Critical bugs
  • Breaking changes
  • Important infrastructure changes
  • Major compatibility issues
  • Performance or stability improvements
  • Security vulnerabilities
  • Other changes requiring prompt attention

The exact severity levels, colors, and visual treatment can be adjusted to follow Dokploy's UI/UX guidelines.

Describe alternatives you've considered

One alternative is to keep the existing “Update Available” indicator without any severity classification.

Another option would be to use text-only labels such as “Important Update” or “Critical Update” without contextual colors or visual indicators.

However, a combination of severity + badge + contextual color would allow users to understand the priority of an update much faster while keeping the interface clean and consistent.

Additional context

The goal is not to make the update interface security-focused, but to provide users with a quick visual understanding of the importance and urgency of an update.

The severity system could eventually be used consistently across the update notification, update page, release information, and other relevant UI components.

Example:

🟢 Update Available
Normal update

🟡 Update Available
Important update

🟠 Update Available
High-priority update

🔴 Update Available
Critical update

This would make the update experience more informative while remaining simple and aligned with Dokploy's existing UI/UX.

Will you send a PR to implement it?

No

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the existing “Update Available” UI and the release metadata path; no file or test is named in the issue. Clarify the supported severity values, their source, and the UI states before implementing badges, colors, and explanations, then verify each severity renders consistently across the update surfaces.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, release
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.