[Feature Request] Add Severity & Importance Indicators to the Update UI
Nobody has claimed this yet.
- 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.
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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