[clartek]

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

Add MeshMonitor as an unprivileged Debian 13 LXC with a native Node.js application and an Apprise notification service. Defaults are 2 CPU cores, 4 GiB RAM, and 10 GiB disk; the extra RAM accommodates building the frontend and native modules.

Install and update through the community release/runtime helpers. SQLite, user scripts, notification configuration, and secrets live outside /opt/meshmonitor, under /data and /etc/meshmonitor; updates back these paths up before replacing the application. Generate a session secret and set CORS to the container address. Bind Apprise to loopback.

Fresh installation verified on Proxmox VE 9.2.21 (amd64). The installer completed successfully and the author confirmed access to MeshMonitor and a working connection to a TCP node. Submitted for maintainer review; real upgrade testing and notification testing remain outstanding. USB passthrough is outside the scope of this submission and has not been tested.

🔗 Related PR / Issue

No existing DevScripts issue or PR found for MeshMonitor.

✅ 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.

Codex (GPT-6; reasoning-effort setting is not exposed in this session) researched upstream and drafted the three files, then reviewed and corrected them against the repository guidance. Local checks used real community deployment/backup helpers with mocked package, build, and systemd commands. The PR author then ran the installer on a real Proxmox host and confirmed a working TCP node connection; the target-platform results are recorded below.

---

📋 Additional Information (optional)

Target-platform validation (reported by the PR author):

• Proxmox VE 9.2.21, kernel 7.0.14-24-pve, amd64.
• Fresh unprivileged Debian 13 LXC from debian-13-standard_13.1-2_amd64.tar.zst, using the default 2 cores / 4096 MiB RAM / 10 GB disk on ZFS storage.
• Fork/branch selection confirmed as clartek/DevScripts@feat/meshmonitor.
• Installed MeshMonitor 4.17.0, Node.js 24, npm 12.2.0, and uv 0.13.4.
• Both release-pinned submodules downloaded and deployed successfully; the frontend/backend build, Python dependency installation, configuration, service creation and cleanup all completed successfully.
• The author confirmed the application is accessible and connects to their TCP node.
• IPv4 internet checks passed. IPv6 internet was unavailable on this host; installation completed successfully over IPv4.

Not yet verified: a real version-to-version upgrade/data-preservation test, notifications, arm64, and Incus. USB passthrough has not been tested and is outside this submission's scope. The broad "Tested thoroughly" prerequisite remains unchecked to reflect these limits.

Local validation completed:

• bash -n on all 256 shell scripts.
• ShellCheck 0.11.0 on both new scripts, excluding the framework's dynamic-source and injected-variable diagnostics (SC1090, SC1091, SC2154).
• shfmt 3.14.1, JSON parsing/resource consistency, and whitespace checks.
• An isolated temporary lifecycle harness exercised installation, both service units, CORS/secret/file permissions, exact submodule revisions, clean application replacement with the real core archive helper, backup/restore with the real core helpers, preservation of database/custom scripts/secrets, no-update handling, and missing-install failure. Package/build/service commands were mocked; this is not a target-platform test.

Upstream findings (stable release v4.17.0):

• package.json requires Node >=22; the Dockerfile and LXC builder use Node 24, selected here.
• SQLite is the default; PostgreSQL/MySQL are optional, so no database server is installed.
• The LXC builder and Dockerfile build frontend before backend, skip Puppeteer's browser download, and use --legacy-peer-deps. The Dockerfile prunes development dependencies after building.
• The prebuilt application archive contains only dist, package manifests, README and LICENSE. It omits runtime protobuf files, TAK dictionaries and Apprise code, so this script builds from release source instead.
• GitHub source archives omit git submodules. Read the chosen release's tree through github_api_call, then use fetch_and_deploy_from_url for the exact pinned protobuf and TAKPacket-SDK commits. These are dependency commit lookups, not separate release/version checks.
• Use setup_uv and an external Python environment for Apprise, requests, Meshtastic and MeshCore CLI support. Its bin directory is on the app service's PATH.
• Upstream creates the admin / changeme account; the script does not hardcode an admin secret and tells the user to change that upstream default.
• arm64 remains explicitly untested (var_arm64 commented; architectures omitted). Upstream builds ARM Docker images, but the native dependencies have not been tested by this contribution. Follow the documented untested-state behavior rather than claiming verified support.
• selfhst currently has no MeshMonitor icon, so metadata uses upstream's logo.

Eligibility checked on 2026-10-20: 697 stars; repository created 2025-09-25; active commits and published v4.17.0 release assets.

Test on a disposable Proxmox LXC from the Proxmox host shell:

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/clartek/DevScripts/feat/meshmonitor \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/clartek/DevScripts/feat/meshmonitor/ct/meshmonitor.sh)"

The fresh-install command above was run successfully on the Proxmox host described above. Additional testers can use it to reproduce the installation. For a real upgrade test, install an older upstream release using var_appversion, then run update inside that test container and verify database/config/custom scripts survive. Maintainer review and further testing are welcome; upgrade and notification success are not claimed.

---

📦 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

🌐 Source

• https://meshmonitor.org/deployment/PROXMOX_LXC_GUIDE.html
• https://github.com/Yeraze/meshmonitor/blob/v4.17.0/lxc/build-lxc-template.sh
• https://github.com/Yeraze/meshmonitor/blob/v4.17.0/Dockerfile
• https://github.com/Yeraze/meshmonitor/blob/v4.17.0/docker-compose.yml
• https://github.com/Yeraze/meshmonitor/blob/v4.17.0/package.json
• https://github.com/Yeraze/meshmonitor/blob/v4.17.0/.env.example
• https://github.com/Yeraze/meshmonitor/blob/v4.17.0/.github/workflows/release.yml
• https://github.com/Yeraze/meshmonitor/blob/v4.17.0/lxc/systemd/meshmonitor.service
• https://github.com/Yeraze/meshmonitor/blob/v4.17.0/lxc/systemd/meshmonitor-apprise.service

[github-actions]

Try this script

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

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/clartek/DevScripts/feat/meshmonitor \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/clartek/DevScripts/feat/meshmonitor/ct/meshmonitor.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.

[asylumexp]

Suggested change

echo -e "${INFO}${YW}Log in as admin with password changeme, change the password, then add your node in the web UI.${CL}"

belongs in notes

[asylumexp]

Suggested change

	},
	{
	"text": "Add your Meshtastic or MeshCore node through the web UI. The container must be able to reach your node over the network.",
	"type": "info"
	},
	{
	"text": "When using a reverse proxy or a different access URL, update ALLOWED_ORIGINS in /etc/meshmonitor/meshmonitor.env and restart MeshMonitor.",
	"type": "info"
	}
	}