Context
Third-party clients (mobile/desktop dashboards, monitoring tools) currently can't tell users when an installed Unraid plugin has a newer .plg version available. The only programmatic install path today is installPlugin(input: InstallPluginInput!): PluginInstallOperation!, which requires the caller to already know the URL of a newer release.
Current schema
type Plugin {
name: String!
version: String!
hasApiModule: Boolean
hasCliModule: Boolean
}
No latestVersion, no updateAvailable, no equivalent of the Docker update-status surface.
Existing pattern that works well — Docker
The Docker side already solves this cleanly:
enum UpdateStatus { UP_TO_DATE UPDATE_AVAILABLE REBUILD_READY UNKNOWN }
type ExplicitStatusItem { name: String! updateStatus: UpdateStatus! }
type Docker { containerUpdateStatuses: [ExplicitStatusItem!]! }
type DockerMutations {
updateContainer(id: PrefixedID!): DockerContainer!
updateAllContainers: [DockerContainer!]!
}
Clients can render a "X updates available" badge and a one-tap update action without scraping registries.
Proposal — mirror for plugins
Either extend Plugin directly:
type Plugin {
# … existing fields
latestVersion: String
updateStatus: UpdateStatus
}
…or add a parallel query field analogous to containerUpdateStatuses:
type Query {
pluginUpdateStatuses: [ExplicitStatusItem!]!
}
Plus a mutation, reusing the existing PluginInstallOperation tracking:
type UnraidPluginsMutations {
updatePlugin(name: String!): PluginInstallOperation!
updateAllPlugins: [PluginInstallOperation!]!
}
Why this matters
Plugin updates today require users to visit Community Applications or each plugin's source URL manually. A schema-level surface unlocks "managed-from-anywhere" parity with the Docker experience the API already provides — and the implementation can reuse the existing .plg re-install path (Unraid's webgui already updates by re-running the .plg from the URL it has).
Context
Third-party clients (mobile/desktop dashboards, monitoring tools) currently can't tell users when an installed Unraid plugin has a newer
.plgversion available. The only programmatic install path today isinstallPlugin(input: InstallPluginInput!): PluginInstallOperation!, which requires the caller to already know the URL of a newer release.Current schema
No
latestVersion, noupdateAvailable, no equivalent of the Docker update-status surface.Existing pattern that works well — Docker
The Docker side already solves this cleanly:
Clients can render a "X updates available" badge and a one-tap update action without scraping registries.
Proposal — mirror for plugins
Either extend
Plugindirectly:…or add a parallel query field analogous to
containerUpdateStatuses:Plus a mutation, reusing the existing
PluginInstallOperationtracking:Why this matters
Plugin updates today require users to visit Community Applications or each plugin's source URL manually. A schema-level surface unlocks "managed-from-anywhere" parity with the Docker experience the API already provides — and the implementation can reuse the existing
.plgre-install path (Unraid's webgui already updates by re-running the.plgfrom the URL it has).