- Starting price
- Free alpha; hosted pricing planned
- Free tier
- Yes
- Platforms
- Web · Self-hosting planned · Developer libraries
- Developer
- FaithBase AI / Izak Filmalter
- Launched
- 2025
- Updated
- Aug 16, 2026
The verdict
OpenFaith contains unusually thoughtful ideas for breaking church-software silos, and its public architecture is valuable to developers now. It is not yet a prudent production system of record. The marketing surface describes live bidirectional Planning Center behavior while the repository still describes roadmap work and a not-yet-selected license. Evaluate with synthetic data, pin a commit, inspect the adapter and permissions, and wait for clear licensing, privacy, security, migration, and support commitments before connecting a congregation.
Try OpenFaith ↗Opens openfaith.app
OpenFaith is an open-development church software initiative centered on a canonical data model and sync engine. Instead of forcing every app to understand every other ChMS, adapters translate people, groups, teams, events, donations, custom fields, and relationships into one flexible model. The stated goal is bidirectional, near-real-time data flow between OpenFaith and systems such as Planning Center, with Church Community Builder, Breeze, Tithely, Subsplash, and Rock RMS discussed as later targets.
The product vision adds a table-first interface, one-click editing, instant filtering, relationships between any entity, custom fields across data types, spiritual milestones, ministry qualifications, scoped permissions, local-first client sync, and future natural-language commands. Those ideas address real frustration in church operations, especially fragmented records and repetitive entry.
The evidence is not yet stable. The product page and directory describe functioning Planning Center sync and a free alpha, while the repository README still contains conceptual language, roadmap steps for building the first adapter, and a license section saying an open-source license such as MIT or Apache is “TBD.” A publicly readable repository is not legally open source until a license actually grants the rights, and a planned capability is not a production guarantee.
This researched review covers the product vision, repository, architecture, data model, sync documentation, permission concepts, funding notes, and directory description. We did not deploy the stack, connect Planning Center, inspect every commit, run adversarial sync cases, test recovery, or review a hosted privacy policy, terms, DPA, security report, or support agreement. The rating deliberately reflects promising architecture at an alpha stage.
✓ The good
- Important interoperability goal - a canonical model and adapters could reduce repetitive point-to-point church integrations
- Public engineering work - code, architecture, issues, commit history, and design documents are inspectable
- Flexible ministry model - edges, subtypes, folders, and custom fields avoid forcing every organization into one vocabulary
- Sync is treated as a system - webhooks, polling, mapping, retries, rate limits, conflicts, and state appear in the architecture
- Permission-aware AI intent - natural-language tools are designed to respect scoped authorization rather than bypass it
- Table-first usability - bulk visibility and direct editing target common ChMS friction
- Donation-oriented vision - foundational tooling is intended to remain available to churches and developers
✗ Watch out
- Alpha maturity - important behavior, integrations, and operating guarantees can change without production stability
- License is unresolved - the README says the open-source license is still TBD
- Documentation conflicts - marketing presents capabilities more definitively than the repository roadmap
- Bidirectional sync is hazardous - duplicate, overwrite, delete, loop, and conflict failures can propagate into authoritative systems
- No clear hosted governance package - public privacy, terms, DPA, subprocessors, retention, incidents, and support are not established
- AI increases blast radius - natural-language write actions over church records require exceptional authorization, preview, logging, and rollback
Best for
- Church-software developers studying canonical models, adapters, permissions, and sync design
- Technical churches willing to experiment only with synthetic or disposable data
- Open-source contributors who can inspect code and help turn roadmap claims into tested behavior
- Vendors exploring an interoperable church-data standard rather than immediate production procurement
Avoid if
- You need a stable supported ChMS or integration layer for a live congregation today
- Your organization requires a settled open-source license, DPA, SLA, security report, or named controller and processors
- You cannot restore Planning Center after a faulty bidirectional change
- Nontechnical staff would assume an alpha interface and AI command are authoritative and reversible
What OpenFaith is
OpenFaith is simultaneously a specification effort, codebase, sync architecture, canonical database, developer platform, and emerging user application. Those layers mature at different rates. A church should identify exactly which commit, component, adapter, hosting model, and support promise it is evaluating.
It is not simply a new front end for Planning Center. The canonical store and bidirectional adapters can become another authoritative data layer, which creates powerful interoperability and difficult ownership questions.
Why a canonical church-data model matters
Most integrations translate one vendor directly into another. That produces many brittle mappings. OpenFaith proposes one church-aware model for people, groups, teams, events, donations, folders, relationships, custom fields, and external IDs, allowing each new adapter to connect with the shared center.
The hard part is not schema elegance; it is operational truth. Every connector needs explicit field ownership, identity matching, deletion rules, conflict policy, rate-limit behavior, reconciliation, observability, replay safety, and rollback. Churches should judge the project by tested recovery evidence as much as feature breadth.
Canonical model and adapters: a serious interoperability foundation
The public design uses Effect Schema, PostgreSQL, Drizzle, external-link mappings, code-first TypeScript adapters, webhooks or polling, transformation, sync state, and flexible entity relationships.
A production adapter should publish a field matrix and contract tests against provider sandboxes and version changes. “Supports Planning Center” is too broad unless each product, field, direction, and failure mode is enumerated.
Table interface and ministry concepts: useful operational ambition
The product vision shows people, groups, teams, events, donations, custom fields, relationships, sacraments, and qualification rules in direct editable tables rather than deeply nested screens.
Spiritual milestones and ministry qualifications are sensitive judgments, not neutral columns. Define who may record, dispute, correct, export, or delete them, and avoid automating spiritual worth or volunteer eligibility from incomplete data.
AI-first tools: powerful only after authorization and rollback
The architecture anticipates LLM tool calls that query, create, update, and automate church data using the canonical model, with permission-aware access and SQL fallback for complex questions.
Every write needs preview, exact affected-record count, reason, approval, idempotency key, audit event, and reversible transaction. Prompts and outputs should never become an invisible administration channel.
Pricing
Alpha access
Free
The current product is described as a free alpha. Do not interpret alpha access as a production warranty, service level, or permanent hosted price.
Future self-hosting
Planned free option
Self-hosting is part of the stated model, but deployment complexity, support, upgrades, backups, and the final code license must be confirmed.
Future hosted service
Planned subscription
A paid hosted subscription is anticipated; public final tiers and operating commitments were not available at review.
Current alpha access is described as free, which is appropriate for experimentation.
A free self-hosted edition and paid hosted subscription are intentions, not final procurement terms.
Self-hosting transfers substantial cost to the church: identity, secrets, database, queues, backups, monitoring, upgrades, incident response, and connector maintenance.
Do not commit production data until pricing, licensing, export, deletion, support, and end-of-service terms are concrete.
Where OpenFaith falls behind
Choose and publish an actual open-source license. “MIT or Apache TBD” does not grant reuse rights.
Separate shipped, beta, experimental, and planned capabilities in both product and repository documentation.
Publish a hosted privacy and security package: controller, processors, regions, retention, DPA, breach notice, backups, recovery targets, and assurance testing.
Release adapter matrices and destructive sync tests covering identity, conflict, deletion, loops, retry, replay, rollback, and provider API changes.
Put AI writes behind preview, dual approval for high-impact actions, scoped service accounts, immutable logs, and one-click rollback.
OpenFaith vs. Planning Center vs. Rock RMS vs. B1 Church
Planning Center is a mature hosted modular suite and the first OpenFaith target, not merely a competitor. Rock RMS is an established open-source church platform with a large operational surface. B1 Church is a nonprofit open-source church suite. OpenFaith is most distinctive as a shared data and sync layer intended to sit between tools.
Choose a mature system for current operations. Explore OpenFaith when interoperability itself is the problem and technical staff can isolate the experiment. It may eventually let specialized apps coexist without repeated migrations, but that promise is not yet proof.
The lowest-risk adoption path is read-only synthetic evaluation, then one narrow read adapter, then monitored limited writes only after restore testing.
The bottom line
OpenFaith is worth watching and contributing to because church-data interoperability is a real unsolved problem and the architecture engages with it seriously. It is also exactly the kind of alpha that can look production-ready before its legal and operational foundations are finished. Celebrate the public work, test with disposable data, demand a real license and governance package, and keep authoritative congregational records in proven systems for now.
Alternatives to OpenFaith
Planning CenterA mature hosted modular suite and OpenFaith’s first major integration target.
Rock RMSAn established open-source church management platform with a large plugin and operations ecosystem.
B1 ChurchA nonprofit open-source suite for churches seeking a current integrated platform.ChurchToolsA mature church-management alternative with hosted operations and established modules.A read-only warehouseA safer integration pattern when reporting is needed but bidirectional operational writes are not.Frequently asked questions
Is OpenFaith ready for production?
It is described as alpha. Public product and repository evidence do not yet establish production support, stable integrations, or complete governance.
Is OpenFaith open source?
The repository is public, but its README still says the license is TBD. Public source is not enough; wait for an explicit license grant.
Does it sync with Planning Center?
Product materials describe bidirectional Planning Center sync, while repository roadmap language is less definitive. Verify the exact modules, fields, directions, and commit in a test organization.
Will it replace my ChMS?
Its vision is to work across existing systems through a canonical model and adapters, though the emerging app also provides management interfaces.
Is self-hosting free?
A free self-hosting option is planned. Confirm the final license, release packaging, upgrade process, infrastructure requirements, and support before relying on it.
What does the AI do?
The architecture plans natural-language queries and actions over church data. Treat write capability as experimental until preview, approval, audit, and rollback are proven.
How should a church evaluate it?
Use synthetic data, pin a version, isolate credentials, begin read-only, test conflicts and restore, inspect permissions, and never connect production records merely to explore the interface.
Sources & further reading
More Church Management Software
B1 ChurchA genuinely free, open-source church platform - app, website, giving and check-in on one database - run by an Oklahoma nonprofit. The catch is not the price - it is that the vendor own docs call the native app deprecated.
Involv Chat (church.chat)Involv Chat combines ministry-team messaging, rosters, blocked dates and service scheduling in a focused church workspace—useful when leaders protect volunteer consent and resist turning attendance or gifts data into a spiritual score.
ChurchSoftwareChurchSoftware—formerly StoreHouse—offers an unusually broad church-management core for $0, including giving, check-in, accounting and a shared mobile app, while charging transparently for vendor-heavy extras.
Pastor Notes AppA two-app system that lets leaders publish sermon notes and invite live congregational response while attendees use the free Bible Notes companion—but its pricing math, refund terms and app privacy disclosures need correction before a church commits.
Take RootA low-cost, offline-friendly relationship tracker built specifically for evangelism and discipleship follow-up—more intentional than a spreadsheet, but its old generic privacy policy does not adequately describe the sensitive ministry data the product exists to hold.
Develop.MeDevelop.Me packages course building, cohorts, discussion, assignments, gamification and mobile learning for churches and mission-driven organizations—with unlimited learners on paid plans, but a vague free tier and a 2022 website privacy notice leave procurement questions open.