[chazkii]

Agent: pi (deepseek/deepseek-flash)

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 Bark Server, the self-hosted backend for the Bark iOS app. It accepts push requests over a simple HTTP API and relays them to Apple's APNs, so scripts and home-automation flows can send notifications to your own iPhone. Device keys are stored in an embedded key-value database (bbolt), so no external database is required.

Where the install steps come from: upstream README.md, main.go (flags/env), route_misc.go (health endpoints), deploy/bark-server.service and deploy/docker-compose.yaml. The release publishes a bare, statically linked Go binary per architecture, so the script deploys it with fetch_and_deploy_gh_release ... singlefile.

• Runtime: none beyond the binary itself — it is a static Go executable, no runtime, no database package.
• Port: 8080 (service default 0.0.0.0:8080, BARK_SERVER_ADDRESS).
• Data: /opt/bark-server_data, kept outside /opt/bark-server, so CLEAN_INSTALL updates need no backup/restore. bark.db (device keys) lives there.
• Auth: none by default. The JSON note warns about this and points at BARK_SERVER_BASIC_AUTH_USER / BARK_SERVER_BASIC_AUTH_PASSWORD.
• Environment: the container needs outbound access to Apple's push service (api.push.apple.com:443).
• Verify: curl http://<IP>:8080/ping returns {"code":200,"message":"pong"}.

🔗 Related PR / Issue

Link: #

✅ 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 left unset and architectures is omitted, so an arm64 host is asked before anything happens rather than being blocked. Upstream does publish a bark-server_linux_armv8 asset, which is why the asset pattern resolves the arm token to armv8 instead of the default arm64; I had no arm64 host to verify it on.

---

🖥️ 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 behavior.
• 📝 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.

DeepSeek Flash (Pi coding agent), high reasoning. It read the upstream Finb/bark-server sources named above and AGENTS.md / .github/agents/pve-script-creator.agent.md, then drafted the three files. The install and update were run end-to-end on Proxmox VE 9.2.11 (kernel 7.0.6-2-pve), Debian 13 unprivileged LXC, and the scripts were reviewed by the author before opening this PR.

---

📋 Additional Information (optional)

Test run (from a local checkout of this branch, non-interactive):

mode=default var_ctid=120 var_net=192.168.1.240/24 var_gateway=192.168.1.1 \
  var_os=debian var_version=13 var_disk=2 bash ct/bark-server.sh

• Fresh install: container created, bark-server.service active and enabled, /opt/bark-server/bark-server (v2.3.9) executable, /opt/bark-server_data/bark.db created. GET /ping → {"code":200,"message":"pong"}, /healthz → ok, /info → v2.3.9, arch: linux/amd64.
• Update: with ~/.bark-server set to 2.3.8, the update detected 2.3.8 -> 2.3.9, stopped the service, redeployed the binary and restarted it. A marker file placed in /opt/bark-server_data survived, confirming the data directory is outside the wiped app dir.
• Footprint: the running server idles at about 18 MB RSS; 1 vCPU / 256 MB is comfortable.
• I (chazkii) manually tested the install script again, and repointed all my Bark clients to it and tested notifications working.
• There is no selfhst icon for Bark, so the logo points at the official one (https://bark.day.app/logo.png).

---

📦 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

• Upstream: https://github.com/Finb/bark-server (3,657 stars, created 2018-06-26, MIT, latest release v2.3.9)
• iOS app: https://github.com/Finb/Bark
• Documentation: https://bark.day.app/

[github-actions]

Try this script

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

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

Can you replace this with one from selfh.st/icons?

[CrazyWolf13]

I think you are missing the architectures field