Security & Reliability

Effective Date: 3 June 2026 Last Updated: 22 July 2026

This page explains how Injil AI hosts, protects, backs up, and monitors the Steward service. It is written for Church Customers (and their advisors) evaluating Steward. Steward is operated by Injil AI Pty Ltd (ACN 700 573 806) ("Injil AI"); the Church Customer is the data controller for its members' personal information and Injil AI acts as a data processor on its behalf (see our Privacy Policy and Terms of Service).

1. Hosting & Data Residency

• Steward runs on DigitalOcean infrastructure in the Sydney (SYD1) region. Your data is stored and processed in Australia.
• The application, database, and supporting services run in isolated containers on a managed virtual private server, behind a reverse proxy that terminates TLS.
• Off-site backups are stored in DigitalOcean Spaces in Sydney, so backup copies also remain in Australia.

2. Encryption & Network Security

• In transit: all traffic between your devices and Steward is encrypted with HTTPS/TLS. Certificates are issued and renewed automatically (Let's Encrypt).
• Internal isolation: the database and cache run on a private network that is not exposed to the public internet — only the application can reach them.
• Secrets: application secrets and credentials are held in server-side configuration, never committed to source control or shipped to client apps.

3. Access & Account Security

• Passwords are never stored in plain text — only as a salted bcrypt hash.
• Authentication uses short-lived access tokens with separate refresh tokens; tokens are kept in secure storage on mobile devices.
• Role-based access limits what each user can see and do (member, admin, and ministry-specific roles such as children's check-in).
• Per-church data isolation: Steward is multi-tenant. Every application query is automatically scoped to the church the signed-in user belongs to, so one church is not served another church's members, attendance, or content. This isolation is enforced in the application layer and covered by an automated cross-tenant test suite that runs on every change before release.

4. Availability & Monitoring

• We aim for high availability. Uptime is monitored by Better Stack, an independent third-party monitoring service that checks Steward every few minutes from outside our own infrastructure — so an outage of our hosting cannot also silence the monitoring that is meant to report it. Live and historical status is published at https://status.injil-ai.com.
• The check targets a deep health endpoint that verifies the database is reachable — so the status page reflects real service availability, not merely whether a process is running. A detected outage automatically raises an alert that notifies our team, and we have confirmed this end-to-end against a real outage rather than assuming it works.
• Monitoring is external and unauthenticated: Better Stack receives only the health endpoint's service-status response and its timing, never church or member data.
• We do not currently offer a contractual uptime guarantee (SLA). Steward is a young product on a single-region deployment; we are transparent about this rather than promise a figure we don't yet engineer for. See the Terms of Service for the formal availability terms.

5. Backups & Disaster Recovery

• The database is backed up daily by an automated job that takes a full logical dump (schema and data), together with an archive of uploaded files (profile photos, church logos, and content images). Backup files are written with restricted permissions.
• Each backup is copied off-site to DigitalOcean Spaces in Sydney, so backup copies also remain in Australia. Local copies are pruned on a rolling schedule.
• Backups are not write-once trophies: we periodically rehearse recovery, restoring a recent backup into a scratch database and verifying it, so we know recovery actually works. Our restore tooling targets a scratch database by default, so a rehearsal cannot affect live data.
• Application releases are deployed as immutable, individually tagged container images, so a misbehaving release can be reverted by redeploying the previous known-good image. Database migrations apply forward-only, so recovering from a release that also changed the database schema may additionally require restoring from backup.

6. Sub-processors

We rely on a small set of reputable providers to deliver Steward:

Better Stack is listed here for completeness rather than because it handles your data: it only performs unauthenticated health checks from outside our infrastructure and records the result, so no member personal information passes through it. That is why it does not appear in the list of recipients of personal information in our Privacy Policy.

We will update this list as our infrastructure evolves.

7. Reporting a Security Concern

If you believe you've found a security vulnerability or have a security question, please email infosec@injil-ai.com. We take reports seriously and will respond promptly.

This page describes our current practices and will be updated as Steward grows (for example, as we add redundancy, a formal SLA, or a Data Processing Agreement for customers who require one).