civicrm-core: A Constituent CRM That Runs Standalone or Inside Your CMS

A CRM aimed at groups that fundraise rather than sell

CiviCRM is a constituent relationship management system designed to meet the needs of advocacy, non-profit and non-governmental groups. The word constituent rather than customer is the tell: this is a system built around donations, campaigns and memberships rather than around sales pipelines. The topics attached to the repository match that framing, with fundraising, nonprofit, crm-platform, open-source and a dcode-2025 tag that suggests the project participates in an annual community code event. It is an open source project under the GNU AGPL 3, and it is coordinated by CiviCRM LLC, which is the arrangement that lets a commercial entity steward a community-governed codebase. The project website is civicrm.org, and the readme is deliberately short because it is an index to the resources rather than a narrative about the software.

Standalone or a module inside your existing CMS

The distribution model is the most consequential decision in the project and it is stated in two sentences. CiviCRM is released as a standalone PHP web application, and as a module that runs within the Backdrop, Drupal, Joomla and WordPress content management systems. That means the same CRM can sit on its own stack with its own database and its own admin interface, or it can live inside the site your editors already use, with the same data model underneath. For an organisation that already publishes on WordPress and has a web team, the module route removes the second system. For an organisation that wants a CRM to be the system of record with a separate public site, standalone is the cleaner answer. The two routes are supported in parallel rather than one being a legacy path, which is a maintenance commitment the project has to keep paying.

Where installation actually happens

The readme deliberately does not contain installation steps. The download URLs and installation instructions are on the project website at civicrm.org/download, and the detailed instructions are in the sysadmin guide at docs.civicrm.org. That is a deliberate division of labour rather than an omission: the download page is a landing page that changes with each release, while the sysadmin guide is versioned documentation, and pinning instructions in a readme that ships with the source would guarantee they go stale. The same split appears for developers, where installing the latest developmental code requires special steps documented in the developer documentation under tools/git. If you are evaluating this software, the sysadmin guide is the document to read, not the repository, and the download page is where you find the version matrix and the requirements.

The repository layout of a mature PHP application

The top level tells you how large and how settled this codebase is. There is a CRM/ directory, a Civi/ directory, an api/ directory, and separate top-level entry points including Civi.php and functions.php. The user interface is separated into templates/, with a templates/ directory for the screens, js/ and css/ for the assets, and an i/ directory for images. The data layer has schema/, sql/ and a header.sql file, and the XML directory holds configuration that is read at runtime. The extension system has an ext/ directory and an extension-compatibility.json file, which records which extensions work with which core version, and a mixin/ directory for shared behaviour. The release machinery is visible too, with release-notes.md, release-notes/ and a distmaker/ directory, and there is a deleted-files-list.json, which is the kind of file only a project with years of backwards compatibility commitments accumulates.

Front end tests run through Karma and Jasmine

The JavaScript side has its own test harness, and the package manifest shows it. The dev dependencies pull in Karma, jasmine-core, karma-jasmine and a preprocessor for Angular templates, with bower and the civicrm-cv package also listed.

  "scripts": {
    "postinstall": "bash tools/scripts/npm/postinstall.sh",
    "test": "bash tools/scripts/npm/test.sh"
  }

The two npm scripts delegate to shell scripts under tools/scripts/npm, which is the pattern for a repository that has to support several package managers and a non-npm build path for the PHP side. The presence of karma.conf.js at the top level confirms the browser test configuration lives with the project. It is worth noting what the manifest version says, 4.6.0, which is the release line the front end tooling tracks, and it also carries a license field of MIT for the package itself, separate from the AGPL-3.0 that covers the application code.

The AGPL-3.0 licence and the exception file next to it

The licence arrangement is more nuanced than the single AGPL-3.0 line in the readme suggests, and the repository root makes the nuance visible. There is a LICENSE file, plus agpl-3.0.exception.txt, a gpl.txt, a header-agpl.txt, a header-afl.txt, a header.txt and a header.tpl. In other words, the project maintains per-file licence headers, and the template that generates them is itself in the repository. The exception file exists because the AGPL requires that any linked work also be free, and an exception mechanism is how a project that links libraries with different terms stays compliant. The presence of a composer.compile.json and composer.json alongside the header files shows the licence is enforced at the packaging stage as well as in the source. This is a mature and deliberate compliance posture, and it means an organisation embedding CiviCRM into a proprietary product needs to look at the exception terms rather than assuming the readme's one line is the whole story.

Support channels, and where development actually happens

The readme separates the audiences. Answers for users, administrators and integrators go to the CiviCRM Stack Exchange site, and paid support is offered through the providers list on civicrm.org. Developers are encouraged to join chat.civicrm.org and post questions and ideas in the Developer Discussion room, which is a Mattermost-style instance with a channel per topic. And the issue tracker is not on GitHub at all: the readme says to report all issues to CiviCRM via GitLab at lab.civicrm.org/dev/core. That last point matters for contributors, because it means the project hosts its own forge for core development while the source lives on GitHub, and the two are not interchangeable. The repository also carries AGENTS.md and CLAUDE.md files at the root, alongside a .pre-commit-config.yaml, which is the usual sign of a project that has added tooling for automated contribution workflows.

Editorial conclusion

civicrm-core fits an advocacy or non-profit organisation that needs a CRM with fundraising, constituent records and campaign workflows, and that wants to run it on its own infrastructure rather than on a hosted product. It is the wrong choice if you want a plug-and-play SaaS, because installation is deliberately not a one-liner, and the wrong choice if you need a lightweight system, since the framework carries a large surface. Before you commit, read the sysadmin guide and confirm your hosting meets the requirements the download page lists.

Frequently asked questions

Official sources

1. civicrm/civicrm-core on GitHub
2. Issues
3. License: AGPL-3.0
4. README