ChurchCRM: self-hosted church management without a subscription

The workflow it is built around

ChurchCRM helps churches organize people and families, groups, events, attendance, giving, volunteers and reports in one place, and the readme lays out the chain it is designed for: people and families, then groups, then events and attendance, then giving and financial tracking, then volunteers, then reports. That ordering is the product. A church is not a company with a customer relationship management system bolted on, it is a set of people who belong to groups, turn up to things, give money, and help each other, and the records of those five things are the same records seen from different angles. The pitch in the repository description is free, no subscription, your data is yours, and the follow-up paragraph explains what that means in practice, that ChurchCRM is open source and self-hosted, so a church can choose where its information runs and how it is managed. That is the whole reason to look at it rather than at a hosted product, and it is also the whole reason it is a different kind of commitment. The project is MIT licensed, written in PHP, and the site is churchcrm.io with documentation at docs.churchcrm.io.

Four routes to a running instance

The readme offers four ways in, ordered by how much you are trusting someone else. There is a live demo, where Softaculous creates a private, temporary ChurchCRM instance for you, it expires automatically, and the readme asks you to use fictional data only, which is the right instruction given that a demo instance is not a private vault. There is the installation path, running it on your own hosting with the official installation guidance. There is Docker, with official churchcrm/crm images on Docker Hub, built for amd64 and arm64 from each stable release, which is the route that makes a trial cheap and the route that makes an ARM deployment possible on cheap hardware. And there is the documentation, which covers installation, configuration, administration and user guides, with a separate quick start section for a fast setup. For core development there is also DEVELOPING.md, which covers the architecture, the builds and the testing. A church office that has never deployed a web application will find the demo first and the Docker route second, and the documentation last.

The build runs PHP and the front end at the same time

The toolchain in the repository is the interesting part for a developer, and it is in package.json rather than in a PHP file. The build script runs the PHP build and the front end build in parallel and waits for both, failing if either fails, which is the pattern you want in a project where the two halves are separate. The PHP half is a composer install followed by a validation step, and the front end half is webpack with a formatting pass and a signature generation step that runs a node script. There are two build targets that are worth singling out because they show how the code is generated. build:openapi runs the composer scripts that produce the public and private OpenAPI definitions, and build:orm runs the ORM generator. So the database access layer and the API description are not hand written and not stale, they are produced from a source of truth on each build. The project also ships rector.php for automated refactoring of the PHP code and a biome configuration for the JavaScript, which suggests the front end tooling is modern. Node 24 or newer is required, which is a current floor rather than a legacy one.

Tests, static analysis and the hooks that enforce them

The tree contains both a browser test suite and a second one, with cypress and playwright directories side by side, and the contribution notes say to fork the repository, create a feature branch, run the test suite and open a pull request. That instruction is the norm for this project, and the tooling around it is broader than the minimum. There is a semgrep directory with a matching ignore file, which is static analysis for security patterns rather than style, and a codespell configuration, which catches the class of typo that survives review. Style is handled by a separate styleci configuration, and CODEOWNERS is present, so the areas with the most sensitive data have named owners who are asked to review changes there. The git hooks live in a .githooks directory, and the .agents and .claude directories alongside AGENTS.md and CLAUDE.md show that some of the development work is expected to be done with coding assistants, which is a choice some maintainers make and others would decline. The SECURITY.md file is the place a reporter would start, and it is present.

Forty-nine locales and an audit that tells you the truth

Localization is the part of the project with the most honest numbers. ChurchCRM currently lists 49 supported locales, and the readme immediately qualifies that, since translation coverage varies by locale, and points to the generated audit report for the current status, which lives in locale/poeditor-audit.md. That is a better arrangement than a badge that claims fifty languages, because it tells you which of them are actually finished. Contributions go through a project on poeditor.com, so the translation workflow lives in a dedicated tool rather than in pull requests against the repository, and the environment file shows what that needs, a POEDITOR_TOKEN with a link to where to get it. The environment file is also where you can see the rest of the toolchain's external dependencies, and there is one that surprises people, an ANTHROPIC_API_KEY used by the release-marketing script and by local Claude agents, which means parts of the project's own automation are model driven and the key is optional for anyone who does not run them.

What the environment file tells you to run

The .env.example is short and worth reading before anything else, because it describes the whole runtime in a dozen lines. The database is MySQL, with the host on localhost, the port on 3306, the database name and the user both set to churchcrm, and a default password of changeme that obviously has to change. The comment says that both local development and Docker use the same defaults, which is a good sign, since it means the two paths are meant to be the same path. There is a separate block for the POEditor API configuration used by the locale download and audit commands, and a third for the Anthropic API, with a comment naming release-marketing.js and the local Claude agents as the consumers. The rest of the configuration is elsewhere, in the docs and in the application itself, but this file is the map of the moving parts. The repository also carries a docker directory, an openapi directory, an orm directory, a locale directory, a changelog directory with its own tooling, a scripts directory, a docs directory and a webpack directory, so the generated artefacts and their generators live next to each other.

Release pace, and a version ahead of the release

The recent tags are 7.7.1 on 2026-09-27, 7.8.0 on 2026-10-10 and 7.8.1 on 2026-10-18, which is roughly one release a week, a pace that suits software with volunteer contributors and a church community that wants fixes quickly. The package file in the tree already reads 7.8.2, so the working copy is one patch ahead of what you can install, and the last push was on 2026-10-20. That combination, active maintenance and a version number that moves in the repository, is worth remembering when you pin a version for a church deployment, because the difference between the tree and the tag is exactly where unreleased work lives. The Docker images are built from each stable release, so a container deployment follows the tags rather than the branch, which is the behaviour you want for a system that holds membership records.

Editorial conclusion

ChurchCRM is a good fit for a congregation that wants its member data on hardware it controls and does not want a per-seat subscription, and the Docker images make a trial installation cheap. It is the wrong choice for a small church that would rather have someone else host and maintain it, since self-hosting is the whole promise and the cost lands on you. Before you commit, read the installation guidance and the documentation on administration, run the live demo with fictional data to see whether the workflow matches how your church actually operates, and check the locale audit report if your congregation needs a language that is not fully covered yet.

Frequently asked questions

Official sources

1. ChurchCRM/CRM on GitHub
2. License: MIT
3. Project website
4. README
5. Releases