feat: add Rocket.Chat LXC script

[william-aqn]

✍️ Description

Adds ct/rocketchat.sh, install/rocketchat-install.sh and json/rocketchat.json.

Rocket.Chat installed bare-metal from the official prebuilt Meteor bundle on Debian 13, backed by a local MongoDB 8.0 single-node replica set. Defaults 2 CPU / 4096 MB / 20 GB. Config lives in /etc/rocketchat/rocketchat.env, outside the bundle directory an update replaces wholesale.

Supersedes #2250, which I opened while PRs were closed.

Where the install steps came from

Not from the docs: the docs and the shipped code disagree, so the thresholds come out of the bundle itself (programs/server/app/app.js) and from releases.rocket.chat/<version>/info.

• Runtime: Node 22. engines pins 22.22.3, but the server validates only the major line at startup, against bundle/.node_version.txt. Any 22.x boots.
• Database: MongoDB 8.0. /info reports compatibleMongoVersions: ["8.0"]; the code hard-exits below 7.0 and warns below 8.0.
• Install sequence: bundle/README - (cd programs/server && npm install), then node main.js with MONGO_URL, ROOT_URL, PORT.

Findings worth a reviewer's attention

The setup wizard cannot be completed on a fresh install, so the script skips it. Its last step waits on an emailed confirmation code; a fresh install has no MAIL_URL, so the mail never leaves the box and the UI sits on step 4 with an empty address and a disabled code field. The admin created in step 1 exists, but Show_Setup_Wizard stays in_progress, so logging in only returns to the dead end. Reproduced from scratch: after the organization step it jumps past the Register/Standalone choice, cloud.registerPreIntent returns {"offline":false,"success":true}, and the server logs an unhandled rejection from Meteor's email package at that instant. The script therefore seeds the admin through Rocket.Chat's own ADMIN_* variables and forces Show_Setup_Wizard to completed - both mechanisms the bundle already implements (insertAdminUserFromEnv, OVERWRITE_SETTING_*), and the former only fires while no admin exists, so they stay inert on later boots.

No GitHub release assets. RocketChat/Rocket.Chat releases carry an empty assets array; the tarball lives only on releases.rocket.chat. fetch_and_deploy_gh_release / check_for_gh_release do not apply, so this uses fetch_and_deploy_from_url with the version from /latest/info. The GitHub API is not merely unnecessary but wrong here: backport releases on older majors are published after newer ones (7.10.15 landed after 8.7.1), so /releases/latest can return a 7.x tag. Two further traps on that host - HEAD returns 404 while GET returns 307, so a curl -I probe reports a live release as missing; and an unknown version returns 500, not 404.

npm pinned to 10 via NPM_VERSION. Under npm 12 the bundle fails twice over: npm 12 refuses its remote tarball dependency (EALLOWREMOTE on source-map-support), and the bundle's own npm-rebuild.js calls npm rebuild --update-binary, which npm 12 rejects.

build-essential is required, not optional. @sematext/gc-stats has no prebuilt binary for Node 22 - node-pre-gyp 404s and it compiles.

MongoDB must be a replica set. 8.x dropped oplog tailing and needs change streams and multi-document transactions; MONGO_OPLOG_URL was removed in 8.0 and is deliberately absent. Debian 13 works despite MongoDB shipping no trixie server packages - core's manage_tool_repository maps trixie onto bookworm.

NSAPP is overridden, as ct/netboot-xyz.sh does, because variables() strips only spaces: the dot in Rocket.Chat would otherwise resolve to install/rocket.chat-install.sh.

One note for the project, not this script: a bare read breaks unattended installs. The install script is reached over lxc-attach with no tty, so read hits EOF and returns 1 and the error trap fails the install. The prompt here needs || true. The same bare read -r -p appears in install/forgejo-runner-install.sh, install/valkey-install.sh, and the CONTRIBUTING example that documents the pattern.

Testing

Proxmox VE 9.2.10, Debian 13 unprivileged LXC, rebuilt from scratch after every correction - most findings above came from a failed run, not from review. Clean install ~4 min; no wizard; POST /api/v1/login with the generated password returns status: success. Both prompt paths rebuilt: var_admin_email=ops@example.net reaches the seeded account in MongoDB, and the unset path defaults and still completes. Update path exercised with an update available and without. Re-verified today against current main and Rocket.Chat 8.8.1. shellcheck clean at warning level, bar SC1090 on the mandated boot line.

🔗 Related PR / Issue

Link: #2250

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

var_arm64 is set to yes, decided per AGENTS.md rather than left commented: the shipped bundle carries aarch64 natives alongside the x86-64 ones (node-v127-linux-arm64-glibc/gcstats.node), anything without a prebuild is compiled by node-gyp (hence build-essential), MongoDB 8.0 has 428 arm64 packages in the Ubuntu noble suite that core maps Debian arm64 onto, and NodeSource 22 serves arm64. That is reasoned from the artifact and its dependencies - I have no arm64 host, so the checkbox above stays honest.

---

🛠️ 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_from_url.

---

🤖 AI Assistance (X in brackets)

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

Claude Opus 5, high reasoning effort, used to research the upstream project, write both scripts, and drive the testing against a live Proxmox host, then reviewed and corrected against AGENTS.md and CONTRIBUTING.md.

This was not one-shot generated. Every version threshold, dependency and failure mode above was established by installing against real hardware, and the container was rebuilt from scratch after each correction. The npm pin, the build-essential requirement, the NSAPP override, the move to fetch_and_deploy_from_url, the wizard skip and the read / || true guard each came from an observed failure or a guideline check, not from a guess. Re-reviewed against the new binding AGENTS.md before opening this PR, which is what changed var_arm64 and the placeholder strings.

📋 Additional Information (optional)

var_testurl is intentionally unset - sync-testurl.yml fills it in once a testing issue is labelled.

🤖 Generated with Claude Code

[github-actions]

❌ Pull Request Closed – PR Template Not Used

The PR description is missing the 📦 Application Requirements section, which means this PR was not opened with the ProxmoxVED PR template.

This usually happens in one of two ways:

• The main repo's PR template was used instead of the ProxmoxVED one, or
• The template was cleared or overwritten with a custom description.

The ProxmoxVED template contains required sections (Type of Change, Code & Security Review, Application Requirements, Source) that the maintainers rely on to review submissions. A custom description — no matter how thorough — cannot replace it.

What to do

1. Open a new PR in this repository.
2. When the PR form loads, the ProxmoxVED template should appear automatically in the description. If it doesn't, copy it manually from .github/pull_request_template.md.
3. Fill out the checkboxes and relevant sections — you can keep your original write-up by pasting it into the Description section of the template.

---

⚠ Maintainer note

Please do not ping or repeatedly contact maintainers to reopen this PR. Open a fresh PR with the correct template instead.

[github-actions]

Try this script

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/william-aqn/ProxmoxVED/feat/rocketchat \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/william-aqn/ProxmoxVED/feat/rocketchat/ct/rocketchat.sh)"

COMMUNITY_SCRIPTS_URL is not optional. 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.