[justadityaraj]

✍️ Description

New script for Lightpanda, a headless browser built from scratch (Zig + V8) for AI agents and automation. It speaks CDP, so Puppeteer and Playwright connect to it like they would to Chrome, and it ships a built-in MCP server.

What the script does:

• Installs the official .deb from GitHub releases with fetch_and_deploy_gh_release ... "binary". The package is just /usr/bin/lightpanda, no service, so the script adds two units.
• lightpanda.service: CDP server on 9222. Same flags as upstream's Docker CMD (serve --host 0.0.0.0 --port 9222 --log-level info) plus --advertise-host ${LOCAL_IP}. Without it /json/version hands out ws://127.0.0.1:9222, so connectOverCDP('http://<IP>:9222') from another machine dials itself. Lightpanda logs a warning about exactly this when bound to 0.0.0.0. If the container IP changes later, ws://<new IP>:9222 still connects (IP literals are always accepted), only the discovery URL goes stale.
• lightpanda-mcp.service: MCP over HTTP on 9223 (lightpanda mcp --host 0.0.0.0 --port 9223), so agents on the LAN can use it at http://<IP>:9223/mcp.
• Sets LIGHTPANDA_DISABLE_TELEMETRY=true on both. Upstream sends usage telemetry by default (README, "Telemetry").
• Update checks the GitHub release and redeploys the .deb. No data to keep, nothing is stored.

Where this came from: read the upstream README (install, serve, MCP, telemetry sections) and the Dockerfile. The runtime stage there is only the binary + tini on debian:stable-slim, tini is just for PID 1 signal handling, so systemd covers it. The .deb only depends on libc6 (>= 2.35), so no extra packages.

Neither server has auth (upstream has none), so the JSON notes say to keep it on a trusted network.

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

Upstream publishes an arm64 .deb, but I have no arm64 host, so var_arm64 is left commented and architectures is omitted from the JSON.

---

🖥️ 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.

PVE 8.4.21, Debian 13 template, default settings, unattended (mode=default).

• Fresh install: both services active, 9222 and 9223 listening, telemetry log says disabled=true.
• CDP: Puppeteer from another machine, both browserWSEndpoint: 'ws://<IP>:9222' and browserURL: 'http://<IP>:9222', loaded news.ycombinator.com and pulled all 30 story titles.
• MCP: initialize, tools/list (32 tools), goto + markdown on HN, then DELETE /mcp to close the session.
• Update: set ~/.lightpanda to 1.0.1, ran the CT script inside the container with PHS_SILENT=1. It went 1.0.1 -> 1.0.2 and both services came back.
• Idle footprint is about 80 MB RAM and 770 MB disk.

---

🛠️ 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)

• 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.5 in Claude Code, high reasoning effort. Used it to read the upstream repo and AGENTS.md and to draft all three files. I reviewed them against the checklist and ran the install and update on my own Proxmox host.

---

📋 Additional Information (optional)

Logo is from homarr-labs/dashboard-icons, selfhst doesn't have Lightpanda yet.

---

📦 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://github.com/lightpanda-io/browser (36.9k stars, created Feb 2023, AGPL-3.0, 1.0.2 released 2026-10-23)
• https://lightpanda.io/docs

[github-actions]

Try this script

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

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

[justadityaraj]

Ran the bot command above on a fresh PVE 8.4.21 shell with dev_mode=net. Install script came from the branch (200), container built clean, both services active, /json/version advertises the container IP and MCP initialize answers on 9223.