[Feature]: Display current version number for all users and add one-click update for self-hosted deployments

[easonLiangWorldedtech]

Problem

Roomote has a release check system (releases.status API + ReleaseNoticeSideNavItem) that detects when a new version is available, but only admins can see it. Regular users have no way to know what version they're currently running — the side nav only shows "Update available" as an admin-only notification badge.

For self-hosted deployments, there's also no convenient way to trigger an update once a new version is detected. Users have to manually pull the latest image and restart containers.

Current workaround

• Admins can open the "Update available" dialog from side nav → see what the new version is
• Check RELEASE_VERSION env var or Docker labels if you know where to look
• Manually run docker compose pull && docker compose up -d for self-hosted

Proposed behavior

1. Display current version number for ALL users (read-only)

• Show current version number (e.g., "v0.30.1") in the user menu dropdown or a subtle footer/badge
• Format: Roomote v{version} — non-intrusive, always visible but not distracting
• Use existing releases.status API (runningVersion) to fetch this
• This should be visible to all users regardless of admin status — it's read-only info, no permissions needed

2. Update notification for admins only

• "Update available" + "What's new" notifications remain admin-only (existing behavior)
• Admins can see both the current version AND whether an update is pending

3. One-click update for self-hosted deployments

• When updateAvailable === true, show a "Update Now" button alongside the notification
• Clicking it triggers: pull latest image → graceful restart (or at least shows the exact commands needed)
• For Roomote Cloud, show "Update available — will be applied automatically" or provide an update confirmation

4. Version history viewer

• List all past versions with their release notes in a dedicated page/modal
• Allow users to see what changed between their current version and any previous version

Affected surfaces

• Web dashboard (user menu / side nav)
• API (releases.status needs to expose runningVersion to all users, not just admins)
• Self-hosting deployment

Self-hosting implications

• For one-click update: need a new tRPC endpoint that triggers docker compose pull && docker compose up -d (or equivalent for the deployment method)
• May need to expose deployment type (Docker, render, etc.) in settings to show correct commands
• No new env vars required

Alternatives considered

• Just showing version number without update button — simpler but less convenient
• Adding a /health endpoint that returns version — useful for monitoring but doesn't solve the UX gap

Documentation impact

• Update self-hosting docs with manual update steps (as fallback)
• Document the new UI elements and their behavior

[roomote-roomote]

I've reviewed the existing release and deployment paths. releases.status already returns runningVersion to every authenticated user; only the latest-version/update fields are restricted to self-hosted admins. The missing part for item 1 is therefore a persistent user-facing presentation (for example, the existing UserMenu), not an API permission change.

I'd like to clarify the deployment context before proposing a safe implementation for the update action:

• Which supported self-hosting path is this primarily targeting: the one-command /opt/roomote installer, an operator-managed Compose deployment, Coolify, or a PaaS deployment such as Railway, Render, or Fly? These paths do not share a host-level update mechanism.
• For the affected deployments, is the desired outcome an in-product display of the exact administrator command, or an action that actually starts the host upgrade? The maintained roomote upgrade path currently performs backup, image pull, migrations, health checks, and rollback handling; exposing raw docker compose execution from the web process would require a separate, tightly authorized host control plane.
• Can you share the deployment method and the pain point in the current manual update flow? That will help validate whether command guidance is sufficient or whether an authenticated host-side updater is required.

The proposed version-history viewer also needs a maintainer scope decision. I recommend initially showing the running release and the current admin-visible target release, reusing the existing cached GitHub release-notes path, rather than adding a full unbounded release-history API.

Please tag @roomote-roomote with the deployment details, and I'll provide a concrete implementation plan.

[easonLiangWorldedtech]

@roomote-roomote Thanks for the review. Here's my thinking:

Deployment context — tiered support:
Rather than asking me to pick one, I'd like Roomote to support multiple deployment methods natively, with a tiered approach:

• Tier 1 (MVP): Docker Compose + /opt/roomote installer — these are the two most common self-hosting paths and should have built-in update support
• Tier 2: Coolify, Railway, Render etc. — show version info + display the recommended update command for each
• Tier 3 (extensibility): Allow users to define custom update commands via settings/env vars

Update action — "official" auto-update options:
I'd like Roomote to provide built-in one-click update buttons for Tier 1 deployments. For example:

• Docker Compose: docker compose pull && docker compose up -d (with health check verification)
• /opt/roomote: roomote upgrade

These should be safe — at minimum, show what will happen before executing, and ideally verify the deployment succeeded after.

Extensibility for other methods:
For deployments not covered natively (Coolify, PaaS, custom setups), Roomote should:

• Detect or let users select their deployment method
• Show the appropriate update command with a "Copy" button
• Allow users to define a custom update command in settings if theirs isn't built-in

This way, Roomote covers the common cases out of the box but doesn't force everyone into one deployment model.

Pain point:
The current flow requires: check GitHub → SSH server → guess which command to run → wait → verify. Having Roomote know your deployment method and say "v0.X.Y is available — click here to update" (or at least show the exact command) would be a significant UX improvement for self-hosted users.

Version history:
Agree with showing running + latest only. No need for full unbounded history.

[roomote-roomote]

I saw the mention, but I need your GitHub account linked to Roomote before issue and PR comments can start work here. Link it from Settings -> Linked Accounts and then mention me again.

[mrubens]

@roomote-roomote please respond to @easonLiangWorldedtech

[roomote-roomote]

I'm on it. I started a task for this issue, and I'll keep updates here.

See task

[roomote-roomote]

@easonLiangWorldedtech Thanks for the detailed proposal. The current releases.status endpoint already returns the running version for all authenticated users; the UI simply does not surface it outside the release-notice flow today. Update availability and release metadata are intentionally limited to self-hosted admins.

Making the current version visible to all users is a sensible, low-risk UX improvement. The one-click update and full version-history proposals need a separate deployment/security design, since Roomote cannot safely assume it controls the host's Docker/Compose runtime. For now, the existing update dialog links self-hosted admins to the upgrade instructions.

Thanks again for outlining the affected surfaces and fallback behavior.