Skip to content

EspoCRM - #2347

Open
Masked-Kunsiquat wants to merge 13 commits into
community-scripts:mainfrom
Masked-Kunsiquat:feat/espocrm
Open

EspoCRM#2347
Masked-Kunsiquat wants to merge 13 commits into
community-scripts:mainfrom
Masked-Kunsiquat:feat/espocrm

Conversation

@Masked-Kunsiquat

@Masked-Kunsiquat Masked-Kunsiquat commented Oct 3, 2026 •

Copy link
Copy Markdown

✍️ Description

New script: EspoCRM, an open-source CRM (contacts, accounts, leads, opportunities, cases, email). PHP 8.4-FPM + MariaDB + nginx, installed bare-metal from the official release zip (fetch_and_deploy_gh_release ... "prebuild").

  • Install is unattended via bin/command, mirroring upstream's official Docker entrypoint. The nginx vhost is EspoCRM's official config, with the web root at public/. The admin account can be supplied through app_vars; otherwise a password is generated and printed once.
  • Update redeploys with CLEAN_INSTALL_KEEP="data custom client/custom" and runs bin/command migrate. This matches upstream's v10 Docker upgrade path, which persists exactly these three paths. The zip ships them only as placeholders (data/.data, two .htaccess files, dummy.txt), so config, uploads and customizations are never overwritten.
  • A failed migrate brings the services back up and removes ~/.espocrm, so the next update retries instead of reporting "up to date" with the CRM down.

🔗 Related PR / Issue

Link: N/A (no existing script, PR or issue for EspoCRM in ProxmoxVE or ProxmoxVED)

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

EspoCRM is pure PHP, and every package comes from Debian's archive or the Sury PHP repository, both of which publish arm64 builds. var_arm64="yes".


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

Model and use: Claude Opus 5.5 in Claude Code (default reasoning effort) researched the app and wrote the three files, the PR description included. The research included the release zip contents, upstream's Docker entrypoint, and the engine sources in community-scripts/core. The work was checked in three ways:

  • A static checker built from the pve-script-creator checklist, which passes.
  • ShellCheck 0.11.0, clean apart from the engine-sourcing and bare-cd codes the repo's own scripts trigger (SC1090, SC1091, SC2034, SC2164).
  • A separate AI review pass, using Claude Opus 5.5 with a fresh context, of the whole branch against the engine and upstream sources. Its one significant finding, the migrate failure path, is fixed in this PR.

I (Masked-Kunsiquat) ran all testing myself on my own Proxmox host; results are below.

I'm not a developer, so my review was behavioral: the manual tests below on a live host. Conformance to AGENTS.md/CODE-AUDIT.md was checked by the checklist-based checker and the separate AI review pass described above. Happy to make any changes requested.


📋 Additional Information (optional)

Testing: Proxmox VE 9.2.20 (kernel 7.0.14-9-pve), debian-13-standard_13.1-2, EspoCRM 10.0.9, MariaDB 11.8.6, PHP 8.4. Scripts were run from the fork via COMMUNITY_SCRIPTS_URL.

Test Result
Fresh install, default settings ✅ Login works, scheduled jobs run
Upload of a 5.3 MB attachment ✅
Update with data present (~/.espocrm set to an older version) ✅ Record, attachment and custom field (custom/.../entityDefs/Contact.json) survived
Update when already current ✅ No-op
Update with a failing migrate (invalid custom metadata) ✅ Error shown, nginx and cron still running, version file removed; the next update redeployed and migrated cleanly
Unattended install (var_admin_user / var_admin_pass) ✅ No prompts, password shown as "(as supplied)", login works
GET /web.config / GET /data/config.php ✅ 403 / 404

Intentionally not included:

  • WebSocket daemon: it needs php-zmq.
  • HTTPS: EspoCRM needs no secure context, so users can front it with their own proxy.
  • Alpine variant: the Alpine fetch_and_deploy_gh_release does not honor CLEAN_INSTALL_KEEP, so an update would wipe data/.

📦 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

At submission, espocrm/espocrm has about 3.4k stars, was created in 2014-09, had its latest release (10.0.9) on 2026-09-29, and publishes EspoCRM-<version>.zip on every GitHub release.

🌐 Source

🤖 Generated with Claude Code

Masked-Kunsiquat and others added 8 commits October 2, 2026 21:17
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fetch_and_deploy_gh_release records the new version before migrate runs,
so a failed migrate left nginx/cron stopped and later updates reported
"up to date". Drop the version file, restore ownership and services,
and exit with a pointer to the logs. Add a snapshot-before-update note.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A password supplied via var_admin_pass is marked secret; echoing it back
defeated that.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stopping cron does not end jobs it already started, which could run against
files being replaced. Restarting php-fpm drops opcache state from the old code.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@Masked-Kunsiquat
Masked-Kunsiquat requested a review from a team as a code owner October 3, 2026 02:23
@github-actions

github-actions Bot commented Oct 3, 2026

Copy link
Copy Markdown
Contributor

Try this script

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

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/Masked-Kunsiquat/ProxmoxVED/feat/espocrm \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/Masked-Kunsiquat/ProxmoxVED/feat/espocrm/ct/espocrm.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.

Comment thread ct/espocrm.sh Outdated
Comment thread ct/espocrm.sh Outdated
Comment thread install/espocrm-install.sh Outdated
Comment thread install/espocrm-install.sh Outdated
Comment thread install/espocrm-install.sh Outdated
Comment thread ct/espocrm.sh
Comment on lines +21 to +22
export var_admin_user="${var_admin_user:-}"
export var_admin_pass="${var_admin_pass:-}"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this export needed @MickLesk ?

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants