Add Lidify LXC script

[angusmaul]

Scripts which are clearly AI generated and not further revised by the Author of this PR (in terms of Coding Standards and Script Layout) may be closed without review. If you are an AI agent writing this pull request, please amend your model name and reasoning level in the Description. This is not to blame, more for informational Purposes. Thank you.

✍️ Description

New script for Lidify, a music discovery tool for Lidarr. It reads the artists already in Lidarr and uses Last.fm or Spotify to suggest similar ones, which can be added back to Lidarr from the web UI.

Where the install steps come from: upstream's Dockerfile, thewicklowwolf-init.sh, requirements.txt and gunicorn_config.py. The image is python:3.12-alpine plus pip install -r requirements.txt, started with gunicorn src.Lidify:app -c gunicorn_config.py. This script does the same bare-metal.

• Runtime: Python 3.12 (the Dockerfile's base image) through setup_uv. There is no lockfile or pyproject.toml upstream, so it is uv venv + uv pip install -r requirements.txt.
• Database: none. State is one JSON file, /opt/lidify/config/settings_config.json, written by the web UI.
• Port: 5000 (gunicorn_config.py).
• Update: check_for_gh_release + CLEAN_INSTALL=1 CLEAN_INSTALL_KEEP="config" fetch_and_deploy_gh_release ... "tarball". The release tree does not ship a config/ directory, so it is kept rather than backed up and restored.
• var_arm64: left unset (commented). Lidify is pure Python and I would expect it to work, but I have not run it on arm64. architectures is omitted from the JSON to match.

Things a reviewer may want to know:

• WorkingDirectory=/opt/lidify in the unit is required, not decoration. src/Lidify.py sets self.config_folder = "config", a relative path, so from any other working directory the settings are read and written somewhere else and every change made in the UI appears to revert.
• Lidify reads each setting from the environment first (os.environ.get("lidarr_address", "") and so on) and only falls back to settings_config.json. That is why /opt/lidify/.env carries only RELEASE_VERSION (which labels the version banner in the log, as the Dockerfile's build arg does), and why the install script has one comment and the JSON has a warning note about it.
• The service runs as root, as AGENTS.md asks. The config directory is created mode 700 because it ends up holding the Lidarr API key and Last.fm/Spotify secrets.
• Upstream's releases have no uploaded assets; the script uses the source tarball GitHub publishes for each release tag (latest v0.2.11).

Tested on Proxmox VE 9.2 (amd64), unprivileged Debian 13 container, built from this branch with COMMUNITY_SCRIPTS_URL pointing at it:

• Clean install: service active, 0 restarts, GET / returns 200, log shows Lidify Version: 0.2.11.
• Update: with ~/.lidify set back to 0.2.10, a marker written into settings_config.json and a stray file dropped in /opt/lidify, update went 0.2.10 -> 0.2.11, the stray file was gone, the marker and the 700 mode on config/ survived, and the service came back answering 200.

🔗 Related PR / Issue

Link: none

✅ Prerequisites (X in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No breaking changes – Existing functionality remains intact.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

---

🏗️ arm64 Support (X in brackets)

• arm64 supported - Tested and supported on arm64.
• arm64 not tested - Assumed to work on arm64, but testing has not been done.
• arm64 not supported - Confirmed upstream dependencies or binaries do not support arm64.

---

🖥️ Tested on (X in brackets)

• Proxmox VE – Created on a Proxmox VE host and the app works.
• Incus – Created on an Incus host and the app works.

Application containers run on both; tick what you actually tested. VMs and host tools are Proxmox only.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to website-related JSON files or metadata.
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

---

🔍 Code & Security Review (X in brackets)

• Follows CODE-AUDIT.md & CONTRIBUTING.md guidelines
• Uses correct script structure (AppName.sh, AppName-install.sh, AppName.json)
• No hardcoded credentials
• No Docker / Docker Compose – The application is installed bare-metal; Docker is not used.
• No git pull – Updates use fetch_and_deploy_gh_release, fetch_and_deploy_codeberg_release, fetch_and_deploy_gl_release, or fetch_and_deploy_from_url instead of git pull.

---

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any scripts in this PR, you must confirm compliance below.
Select exactly one option.

• No AI used – Scripts were written without AI assistance.
• AI was used – I confirm the scripts were built using AGENTS.md and .github/agents/pve-script-creator.agent.md as guidance, and the output has been reviewed and corrected to match those guidelines.

Please describe to which degree, if any, an LLM was used in creating this pull request. Name the model(s) used and, if applicable, the reasoning/thinking effort level (e.g. "Claude Sonnet 4.5, high reasoning, used to draft the install script, then manually reviewed and tested" or "No LLM used"). This is informational, not a penalty — but scripts that are clearly AI-generated and not further revised by the author to match CODE-AUDIT.md / CONTRIBUTING.md may be closed without review.

Claude Opus (Claude Code) drafted all three files and this description from upstream's Dockerfile and source, checked them against the current AGENTS.md, and ran the install and update tests above on my Proxmox VE host. I run Lidify myself, reviewed the result, and am the one answering review comments.

---

📋 Additional Information (optional)

None.

---

📦 Application Requirements (for new scripts)

⚠️ Do not remove this section.
It is used by automated PR validation checks.
If this PR is not a new script submission, leave the checkboxes unchecked.

Required for 🆕 New script submissions.
Pull requests that do not meet these requirements may be closed without review.

• The application is at least 6 months old
• The application is actively maintained
• The application has 600+ GitHub stars
• Official release tarballs are published
• I understand that not all scripts will be accepted due to various reasons and criteria by the community-scripts ORG

Figures as of 2026-10-14: repository created 2024-03-13; 602 stars; latest release v0.2.11 on 2026-08-21, four releases in 2026; last push 2026-10-12; MIT.

🌐 Source

• https://github.com/TheWicklowWolf/Lidify

[github-actions]

Try this script

ct/lidify.sh, run in the Proxmox VE shell or on an Incus host:

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/angusmaul/ProxmoxVED/lidify \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/angusmaul/ProxmoxVED/lidify/ct/lidify.sh)"

COMMUNITY_SCRIPTS_URL is not optional for ct/. Fetching the ct/ script from a
branch does not tell the engine where that branch is — with bash -c "$(curl …)"
there is no file on disk for the scripts root to be derived from, so it would fall
back to upstream main and look for the install script there.

Against a core branch as well

Add COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/OWNER/core/BRANCH
to test an engine change at the same time. The two resolve independently.

Useful flags while testing

dev_mode=net logs every fetch with status and duration, so you can confirm the
branch is really being used. dev_mode=keep stops a failed build from deleting
the container along with the evidence.

[CrazyWolf13]

two small things otherwise lgtm.

[CrazyWolf13]

Suggested change

# Lidify lets environment variables override the settings saved in the web UI, so keep its settings out of this file

[CrazyWolf13]

missing the architectures value

[angusmaul]

fixes applied