[TaiKamilla]

✍️ Description

New script: Shopware 6 (open-source e-commerce platform, Symfony + Vue.js) in a Debian 13 LXC, set up following the official Shopware hosting and performance guides (shopware/docs → guides/hosting/), not a minimal dev install:

• PHP 8.5 FPM (newest version in Shopware's own CI; 8.2+ required), memory_limit 512M, extra modules soap, zstd. php.ini tweaks from Performance Tweaks (zend.assertions, opcache interned strings / max files, realpath cache).
• MariaDB 12.3 LTS (MARIADB_VERSION="12.3", the version Shopware CI tests; 13.x is rolling) with max_allowed_packet 64M, group_concat_max_len 320000 and an sql_mode without ONLY_FULL_GROUP_BY, as the docs ask.
• Valkey 9 (Shopware's recommended Redis-compatible store). Debian 13 only ships 8.1, so the upstream prebuilt binaries from download.valkey.io are deployed with fetch_and_deploy_from_url + get_latest_github_release. Two instances, because the docs require different eviction/persistence per data type (Infrastructure → Redis):
  • valkey@cache (:6379, no persistence, volatile-lru): app/system cache (redis_tag_aware), delayed HTTP cache invalidation.
  • valkey@persistent (:6380, AOF everysec, volatile-lru): sessions, cart, number ranges, increment storage, lock store and the Messenger transports (symfony/redis-messenger, one stream per transport).
  • Run via a valkey@.service template with DynamicUser=yes (no useradd).
• OpenSearch 3.x single node (localhost only, security plugin off, 1 GB heap, 1 shard / 0 replicas) for storefront and admin search. SHOPWARE_ES_THROW_EXCEPTION=0 as in the docs' production example: OpenSearch needs about a minute after a container boot, and this way the shop serves from MariaDB in that window instead of answering 500. Optional via var_opensearch=no for small shops (search then falls back to MariaDB). The 2.x apt repo is signed with a SHA1-bound key that Debian 13's sqv rejects, so the 3.x repo + opensearch-release.pgp is used (Shopware supports OpenSearch 3 since 6.7.3.1).
• Node.js 24 LTS (listed as required by the docs, for building extension assets).
• HTTP cache enabled, admin worker disabled, CLI workers as systemd units (messenger:consume async low_priority failed, scheduled-task:run), mails through the queue, monolog level error, .env.local.php dumped.
• nginx with Shopware's reference server block, enabled via nginx_enable_site.
• Admin user/password via var_admin_user / var_admin_pass (generated with random_password when empty) / var_admin_email, saved to ~/shopware.creds.

Update: check_for_gh_release against shopware/shopware; create_backup of .env.local and config/packages/prod (Flex recipes may touch config), maintenance mode → system:update:prepare → composer update → restore_backup → system:update:finish. Stays inside the template's ~v6.7.0 line; major upgrades (6.8) are manual and noted in the JSON. Valkey binaries are updated the same way against valkey-io/valkey.

Upstream research: Shopware has no release tarball meant for self-hosting; the documented production install is composer create-project shopware/production, used here. The official production images (shopware/docker) are Alpine + PHP-FPM + Caddy/Nginx with external DB/Redis/OpenSearch; this script reproduces that stack bare-metal inside one LXC. shopware/core 6.7.15.1 requires PHP ~8.2 || ~8.3 || ~8.4 || ~8.5.

🔗 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=yes: every component publishes arm64 builds (Sury PHP, MariaDB 12.3 trixie repo, OpenSearch 3.x apt, Valkey noble-arm64 tarball, Node). I have no arm64 host to test 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.

Unattended clean runs on Proxmox VE (Debian 13 template, unprivileged, default resources 2 CPU / 6 GB / 20 GB): all services active (nginx, php8.5-fpm, mariadb, valkey@cache, valkey@persistent, opensearch, shopware-worker, shopware-scheduler), storefront 200 (~28-47 ms once cached), /admin 200, Admin API login OK, full reindex queued through the Valkey transport and drained by the worker, 18 OpenSearch indices, 0 CRITICAL entries in var/log, ~2 GB RAM used. Also tested: container restart (all services come back) and update_script() run inside the container with the version files removed (Valkey and Shopware both went through the update path, services back up, storefront/admin 200, config restored). Versions installed: Shopware 6.7.15.1, PHP 8.5.12, MariaDB 12.3.3, Valkey 9.1.3, OpenSearch 3.9.0.

---

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

Deviation to flag: Shopware itself is installed and updated with Composer (composer create-project / composer update), which is the only production install method Shopware documents; there is no deployable release archive.

---

🤖 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 (Anthropic) running as an agent, default reasoning effort: researched the Shopware hosting docs and CI matrix, drafted the three files from the EspoCRM template, then iterated through several real unattended installs on Proxmox VE, fixing every failure found (OpenSearch 2.x SHA1 key, stale Symfony container after composer require, one Messenger stream per transport, version file from composer.lock). Reviewed and approved by the author before submission.

---

📋 Additional Information (optional)

• Default resources are 2 CPU / 6 GB RAM / 20 GB disk because of the OpenSearch heap; with var_opensearch=no 4 GB is enough.
• The shop is set up on the container IP; for a domain or reverse proxy, change APP_URL in /opt/shopware/.env.local and the sales channel domain (JSON notes).

---

📦 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 1,000+ 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

• Website: https://www.shopware.com/
• Repository: https://github.com/shopware/shopware (3.4k+ stars, since 2018)
• Production template: https://github.com/shopware/production
• Hosting docs: https://developer.shopware.com/docs/guides/hosting/
• Docker production images (reference stack): https://github.com/shopware/docker

[github-actions]

Try this script

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

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

[github-actions]

✅ Requirements check passed. Thanks for fixing the description — the stale mark has been removed.

[TaiKamilla]

This might be interesting to you @shyim

This is the main project:
https://community-scripts.org