"p1":"The <strong>Updates</strong> tab separates version detection from the action that installs an update. Registration and optional version tracking live on the <link>App tab</link>; executable update methods live here.",
"p2":"A saved application appears in Updates even when it contains only a web link. Version tracking is optional, and an updater can be configured independently.",
"callout":"Registering an application does not select an updater. If a matching Helper-Scripts updater is detected, choose and save <strong>Helper-Scripts</strong> or <strong>Custom command</strong>. Detection is not a compatibility guarantee. The choice belongs to each application, even when several apps share one LXC."
"lead":"The integrated Proxmox VE Helper-Scripts path follows the official <helper>update-apps mechanism</helper>. Other install types use the matching package, Docker or custom path.",
"notes":"After Helper-Scripts is explicitly selected, runs the official application script identified by the validated /usr/bin/update wrapper. A marker or catalogue match alone never enables execution."
"callout":"A custom command <strong>replaces</strong> Helper-Scripts for that application. Manual, bulk and scheduled runs all respect the saved choice. Existing custom commands and legacy explicitly saved bulk/enabled schedule selections are retained; newly registered applications are never opted in by an old schedule."
"lead":"After Docker is registered on the App tab, its engine and image inventory appear inside the same <strong>Docker</strong> section.",
"items":[
"Docker Engine version tracking is separate from the OS package counter and has its own update button.",
"Tagged local images are compared with their registry by immutable digest. <strong>Check now</strong> refreshes this inventory without pulling images or restarting containers.",
"Compose services are updated from their declared project. Images that belong to the same service group are handled together so the project is not recreated repeatedly.",
"A standalone container is recreated from its current configuration. The protected flow keeps rollback data and restores the previous container if recreation fails.",
"Every image can be selected separately in manual, bulk and scheduled updates, except declared Compose dependencies that must follow their parent service."
],
"callout":"Containers running inside Docker are not shown as independent LXC applications. Their published web ports can be saved as links under the Docker registration, while image updates remain in the Docker section."
"<strong>Configure</strong> opens the updater selector when no method is selected; <strong>Edit</strong> changes a saved choice. The information buttons explain each option, link to official documentation and show a custom-script example. Selecting an option does not execute it.",
"When version tracking is disabled but an updater exists, the neutral <strong>Run updater</strong> action is shown. ProxMenux does not claim that an update is pending.",
"Without an available Helper-Scripts updater, configure a custom command. Disabling a method does not silently select another one; existing plan/schedule selections remain saved and unavailable targets are reported.",
"Open <strong>Configure</strong> when the field is empty, or <strong>Edit</strong> when a method already exists.",
"For an integrated app or Docker Engine, the editor shows the command currently used. Saving different content turns it into the explicit override for that record.",
"Test the complete procedure in the LXC terminal first. It must be non-interactive, use the correct working directory and return a non-zero exit status on failure.",
"Do not include <code>pct exec</code>; ProxMenux already enters the container and runs the command as root."
"exampleLead":"Example of a complete in-container procedure:",
"example":"cd /opt/my-app && ./update.sh",
"callout":"A version command such as <code>myapp --version</code> only reads a version; it is not an updater. Commands run with administrative privileges, so stored content must be reviewed with the same care as a root shell command."
"lead":"Bulk update creates one reusable action for an exact set of targets in the LXC. It is placed after the individual app and Docker sections and before <strong>Options</strong>.",
"items":[
"OS packages are mandatory. At least one additional app, Docker Engine or Docker image unit must be selected.",
"Applications and Docker units are selected individually. A Compose parent shows the dependencies that will be updated with it.",
"Unavailable or removed targets are marked as stale and must be removed before the configuration can be saved.",
"The <strong>Apply updates</strong> button is purple when any selected target has a verified update, green when all selected targets are verified current, and neutral when the result is unknown.",
"Removing the bulk configuration does not remove individual update methods or scheduled-update settings."
"lead":"Scheduled updates use the same executable targets and safety options as manual actions.",
"items":[
"Choose a preset or cron expression, then select exact targets: OS packages, individual apps, Docker Engine, standalone Docker units or Compose service groups.",
"A release hold applies only to selected applications with version tracking. Apps without tracking run their updater whenever their schedule is due.",
"The last-run state distinguishes success, partial completion, failure, safety hold and a run with nothing pending. After the first scheduled run, <strong>Updates → Scheduled updates → View log</strong> opens the complete output captured from the updater and any child scripts it invoked.",
"After each run, ProxMenux checks the standard Debian reboot-required marker. When a restart is needed, the Updates tab and the completion notification say so; the warning is cleared when that LXC starts or restarts.",
"On the Proxmox host, scheduled-run logs are stored in <code>/usr/local/share/proxmenux/logs/lxc-updates/</code> using the name <code><VMID>-scheduled-<run-id>.log</code>. The latest ten logs are retained per LXC and older files are removed automatically.",
"This retained history applies to scheduled updates. A manual update displays its output live in the Monitor execution window and does not create a scheduled-run log in that directory.",
"The LXC cache is replaced with the verified post-update state, so badges and buttons do not retain the previous result.",
"If a stopped or restored LXC starts, the existing lifecycle event refreshes that LXC again. Docker inventory waits for the daemon to become ready instead of caching an empty startup result as final.",
"Enabled notifications are emitted from the finalized run, including partial failures and grouped Docker image results."
"resolution":"Open Configure, add the official non-interactive procedure and test it manually before scheduling it."
},
{
"problem":"A Proxmox VE Helper-Scripts identity is shown but no action exists",
"resolution":"The LXC has legacy identification data but no verified /usr/bin/update wrapper. Add a custom method only after confirming the correct procedure."
},
{
"problem":"Docker images are temporarily empty after startup or restore",
"resolution":"Wait for Docker to become ready or press Check now. The inventory retries startup and does not treat a transient empty result as final."
},
{
"problem":"A saved bulk target is no longer available",
"resolution":"Edit the bulk configuration, remove the stale target and select its current replacement if one exists."
},
{
"problem":"A custom command fails",
"resolution":"Run it in the LXC terminal and review its path, dependencies, non-interactive flags and exit code."
"problem":"A scheduled update says that a restart is required",
"resolution":"Open View log to review the completed run, then restart that LXC. ProxMenux clears the warning from the existing lifecycle event after the container starts again."
