iOS & web apps
Native iOS and browser-based tools sign in securely, then talk to our encrypted API. Role-based access is enforced on every request — not only in the UI.
1:1Church-to-database mapping in production
100%Server-side permission checks on protected routes
TLSEncryption for all admin and member traffic
AuditLog of sensitive admin actions per church
High level
What ChurchRelay does for your church
ChurchRelay is one platform for members, leaders, and staff: directory, calendar, chat, serving, check-in, lobby displays, and your public website. Each church is its own tenant — your people, events, and messages never mix with another congregation's data.
Clients
iOS app
Web & admin
Public sites
Lobby displays
ChurchRelay API
HTTPS · role checks on every request
Platform registry
church lookup only
Your church database
members · chat · calendar · audit
Connected services (auth, realtime, email, files)
Identity
Realtime
Email
File storage
Every client talks to one encrypted API. Your church's data is resolved after sign-in — not mixed with other congregations.
Admin console
Church admins manage members, ministries, billing, check-in, signup sheets, and site content from churchrelay.app/admin.
Public surfaces
Church websites live at {slug}.churchrelay.site. Visitors can use live chat and public signup links without a ChurchRelay account.
How a request works
From sign-in to your church database
Every authenticated action follows the same path. That keeps tenancy predictable and auditable.
- 1
Sign in
Verified session + active church
- 2
Resolve church
Platform registry lookup
- 3
Open your DB
Tenant database for that church only
- 4
Check permissions
Role & ministry scope
- 5
Respond
Data scoped to your congregation
Data isolation
Where your data lives
We use a control + tenant database model. In production, each church typically gets its own tenant database — not a shared row in one big table.
Platform registry
maps sign-in → your church
Church A
dedicated DB
Your church
← you are here
Church C
dedicated DB
No cross-church queries · switching church = different database connection
In production, each congregation's member data, messages, and settings live in a separate database — not a shared table with a church ID.
| Database | Scope | Examples |
|---|---|---|
| Platform registry | One per platform | Church lookup, join requests, invite codes, billing metadata — no member messages or directory data from other churches |
| Church database | One per church (production) | Members, families, ministries, chat, calendar, serving, check-in, office displays, site config, audit logs |
Your church = your database. When someone switches church in the app, the API opens only that congregation's database. There is no shared members table across churches in production.
Security & privacy
How we keep your data safe
Encrypted in transit
HTTPS/TLS for all web and API traffic
Authentication
Sign-in required; sessions expire
Authorization
Roles enforced server-side on every route
Data isolation
Separate database per church in production
Audit trail
Privileged admin actions logged
Multiple independent layers — compromising one does not bypass the others.
- HTTPS everywhere — API and admin traffic encrypted in transit.
- Server-side authorization — roles (visitor through account holder) and ministry scope are checked on every protected route.
- Directory visibility rules — email and sensitive fields follow role-based visibility; visitors see less than full members.
- Audit logging — privileged admin actions are recorded in your church audit log.
- Member data export — members can request a copy of their data from their profile settings.
- Rate limiting — join, search, messaging, and export endpoints are throttled to reduce abuse.
- Verified webhooks — billing and identity webhooks verify signatures; duplicate events are rejected.
- No secrets in mobile builds — database tokens and API keys stay on the server only.
Production safeguards
Bootstrap and setup routes are disabled in production. Credentials live in encrypted environment secrets — never in source code.
Signed-in church admins can open Stack health for live connection status to your databases and integrations.
Technical detail
What we build on
ChurchRelay is a modern web and mobile stack on managed cloud infrastructure — no self-hosted servers or DIY security patches. We use established, audited vendors for hosting, identity, and storage rather than rolling our own.
Application hosting
Managed cloud with HTTPS, auto-scaling, and global edge delivery.
Identity & access
Enterprise-grade sign-in, organizations, and session management.
Database
Encrypted storage with a dedicated database per church in production.
Realtime & push
Live chat, calendar updates, and mobile notifications.
Email & files
Transactional email and secure media uploads via vetted vendors.
Monitoring
Uptime checks and error tracking to catch issues early.
Why we don't list every vendor name here. Church admins care that data is encrypted, isolated, and handled responsibly — not which email API we picked last quarter. Competitors already know the common building blocks; our value is the church-specific product, workflows, and how we wire it together. For security questionnaires or vendor reviews, contact support@churchrelay.app.
Operations
What ChurchRelay operates
We manage
- Cloud projects, domains, and environment configuration
- Database creation, migrations, and backups
- Third-party service accounts and integration health
- iOS / tvOS builds and App Store distribution
- Automated quality checks before every release
Trusted partners host
- API compute and CDN delivery
- Database hosting with encryption at rest
- Authentication and session management
- Realtime messaging, push, email, and file delivery
Background work runs inside the API — there is no separate server fleet for church admins to maintain.
Reliability
Monitoring & status
Public system status
Live platform health and uptime history are at churchrelay.com/status.
Church stack health
Admins with console access can view database connectivity and integration status at /admin/health.
Questions
Common admin questions
Can another church see our data?
No. Production uses separate databases per church. The platform registry only stores the mapping from your sign-in to your database — not other churches' member or message data.
Who can access the admin console?
Users with church admin or account_holder roles. Access requires sign-in and active membership in your congregation.
Where is data physically stored?
Hosted on managed cloud infrastructure; exact regions depend on configuration. Ask support if you need a compliance or DPA discussion.
Need a full vendor list?
Email support@churchrelay.app for security questionnaires, subprocessors, or architecture reviews — we share details under NDA when needed.