SuiteCRM 7.15.2: self-hosted CRM on a LAMP stack

The problem SuiteCRM 7 solves, and for whom

SuiteCRM is a customer relationship management application you host yourself. The README frames the project's vision as giving "users full control of their data and freedom to own and customise their business solution", which is the practical difference between it and a subscription CRM: the database, the file uploads and the application code all sit on infrastructure you control. The topics list names the record types it covers: accounts, contacts, leads, opportunities, cases, contracts, quotes, documents, campaigns and reports, with multi-currency and multi-language support.

The audience is narrower than the feature list suggests. This is software for organisations that have a Linux server, a database administrator or a developer who is comfortable with PHP, and a reason to keep customer data inside their own network. The README states plainly that SuiteCRM 7 "is compatible with most Linux and Windows servers", while recommending a properly configured LAMP stack for performance and compatibility. That recommendation is the honest summary of the deployment model. If your organisation has no one who can run Apache, PHP and MySQL, the README points at SuiteCRM Ltd's managed hosting rather than pretending self-hosting is trivial.

What the repository layout tells you about the architecture

SuiteCRM is not a framework with a CRM bolted on. It is a large PHP application with a long history, and the top-level entries show that history directly. There is index.php as the front controller, install.php and the install/ directory for the web installer, and cron.php plus run_job.php for scheduled work such as campaign mail and workflow. sugar_version.php and suitecrm_version.php hold the version metadata, and files.md5 is a manifest of shipped files.

Interface surfaces are split across several entry points rather than a single API layer. soap.php and the soap/ directory handle SOAP, json_server.php handles JSON, and the Api/ and service/ directories hold further service code. Modules/ contains the record type implementations, metadata/ holds the framework definitions that describe fields and layouts, include/ holds shared libraries, and themes/ holds the front-end skins. The custom/ directory is the extension point that survives upgrades, which is why the documentation steers modifications there rather than into modules/.

The consequence is that customisation happens in two different ways, and they cost different amounts. Metadata and vardef changes are declarative and generally survive an upgrade. Changes made directly to files under modules/ or include/ are overwritten when you replace the codebase, which is the normal upgrade path. That distinction matters more than any single feature when you estimate maintenance effort.

Installing SuiteCRM 7.15.2 and logging in for the first time

The README gives the key system requirements rather than a step-by-step install: Apache (recommended) or IIS, PHP 8.1 to 8.4, and MySQL or MariaDB (recommended) or MSSQL. It defers the detailed procedure to the Compatibility Matrix and the Installation Guide on docs.suitecrm.com. What the repository provides is a web installer, so the practical route is to place the code on a web server and open the installer in a browser.

Start by cloning the repository. The default branch is hotfix, which is where releases are cut from, so check out the release tag if you want a fixed version rather than a moving branch.

Installing SuiteCRM 7.15.2 and logging in for the first time (commands)

The commands below match the repository layout: composer.json and composer.lock are present at the top level, and install.php is the installer entry point. Run the clone, then point your web server's document root at the resulting directory and open install.php in a browser. The installer will ask for database credentials and an admin user; the README does not document a non-interactive or CLI install path, so treat the browser step as required.

git clone https://github.com/SuiteCRM/SuiteCRM.git suitecrm
cd suitecrm
git checkout v7.15.2
composer install --no-dev

After the installer finishes, the application is served from index.php. Scheduled jobs are the part most first-time installs get wrong: cron.php exists at the repository root and must be called by your scheduler, otherwise campaign mail and workflow actions queue without running. The README does not document the exact crontab line, so take the interval from the Installation Guide rather than guessing.

php cron.php

Running it manually once is a reasonable way to confirm it completes without a fatal error before you hand it to a scheduler. The README does not document rollback for an upgrade, and the upgrade documentation is linked rather than reproduced, so verify the procedure there before you replace a production codebase.

Where SuiteCRM 7 is the wrong choice

The AGPL-3.0 licence is the first constraint to think about, not the last. If you modify SuiteCRM and let users interact with it over a network, the licence's network clause applies to the modified version. That is a real consideration for anyone planning to build a differentiated product on top of the codebase, and it is a different situation from permissively licensed libraries. This is a description of the licence, not legal advice; read LICENSE.txt and talk to someone qualified if the distinction affects your business model.

The second constraint is version confusion. The README states that SuiteCRM 8 lives in a separate repository, SuiteCRM/SuiteCRM-Core, and that "at the time of writing, SuiteCRM 8 is in the levelling up phase and not yet as feature complete". Anyone searching for how to install SuiteCRM 8 is looking at a different codebase with a different stack. Installing 7.15.2 does not give you the SuiteCRM 8 interface, and the README does not promise a migration path or a date.

The third is operational. A self-hosted CRM means you own uptime, backups, PHP upgrades and security patching. The README recommends upgrading to the latest ESR release "at their earliest opportunity" for security and bug fixes, which only works if someone is watching releases. A team with no one assigned to that will drift onto an unpatched version, and the release cadence here (v7.15.2 on 2026-07-31, v7.15.1 and v7.14.9 both on 2026-03-19) means there is a maintenance branch to track as well as the current line.

SuiteCRM compared with SugarCRM

The search data shows people asking about SuiteCRM versus SugarCRM, and the relationship is historical rather than competitive in the ordinary sense. SuiteCRM began as a fork of the SugarCRM Community Edition, which is why the codebase still carries Sugar-era names such as SugarSecurity.php and sugar_version.php at the top level. That shared ancestry is visible in the directory structure and in the module metadata format.

The practical difference today is governance and distribution. SuiteCRM is published under AGPLv3 and developed in public, with a community forum, a public issue tracker and a separate extensions directory. SugarCRM is a commercial product with vendor-controlled distribution. If your requirement is a CRM you can read, modify and host on your own terms, the fork is the relevant one. If your requirement is a vendor contract with defined support obligations, the fork is not trying to be that, although SuiteCRM Ltd does sell support plans and managed hosting alongside the open source project.

Maintenance, upgrades and what the repository does not tell you

The repository was last pushed on 2026-09-17 and is not archived, so the hotfix branch is receiving commits. The recent releases are v7.15.2 on 2026-07-31, with v7.15.1 and v7.14.9 both dated 2026-03-19, which shows two maintained lines rather than one. For an operator that means deciding early whether you run the 7.15 line or stay on 7.14, because the upgrade documentation is external to the repository and the README only says to move to the latest ESR release.

Upgrade cost is dominated by customisation, not by the upgrade itself. Because the documented upgrade path replaces application files, anything you edited under modules/ or include/ has to be re-applied, while changes made through Studio or placed in custom/ generally persist. The repository ships files.md5, a manifest of shipped files, which is the mechanism used to detect files that differ from the release. That is worth knowing before you start editing, because it turns a vague worry about upgrades into a checkable list.

On licensing, AGPLv3 means the source of your modified version must be made available to users who interact with it over a network. Internal deployments where you are the only user are a different case from a hosted service offered to third parties. The README does not discuss licence compliance beyond stating the licence, so treat LICENSE.txt as the source and get proper advice for a commercial deployment.

Editorial conclusion

Adopt SuiteCRM 7 if you need an on-premise CRM you can modify in PHP and you have someone who will own patching, backups and upgrades. Do not adopt it if you want a vendor-run service, if nobody on the team reads PHP, or if you expect SuiteCRM 8 feature parity today, since the README describes SuiteCRM 8 as still in a levelling up phase. Before committing, verify three things on a staging copy: that the web installer completes against your exact PHP and MySQL build, that cron.php actually runs from your scheduler, and that your mail settings deliver campaign and notification mail rather than queueing it silently.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. SuiteCRM/SuiteCRM on GitHub