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
typePlugin {
name: String!version: String!hasApiModule: BooleanhasCliModule: 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:
enumUpdateStatus { UP_TO_DATE UPDATE_AVAILABLE REBUILD_READY UNKNOWN }
typeExplicitStatusItem { name: String!updateStatus: UpdateStatus! }
typeDocker { containerUpdateStatuses: [ExplicitStatusItem!]! }
typeDockerMutations {
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:
typePlugin {
# … existing fieldslatestVersion: StringupdateStatus: UpdateStatus
}…or add a parallel query field analogous to containerUpdateStatuses:
typeQuery {
pluginUpdateStatuses: [ExplicitStatusItem!]!
}Plus a mutation, reusing the existing PluginInstallOperation tracking:
typeUnraidPluginsMutations {
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).