Trellis · Updated September 18, 2026
Trellis holds names, phone numbers, pastoral notes, giving records and volunteer records for real people, for more than one church, in one database. This page says plainly how that information is kept apart and protected, what Trellis and the services it runs on do, and what people who sign in are responsible for.
One church cannot see another
Every church’s records carry the church’s id, and every rule about access lives in the database, not in the web page. Each request a browser makes is checked against row-level security policies in Postgres, which return only rows belonging to the church the signed-in person is a member of, and within that church only what their role allows: a leader gets the groups they lead, a director gets the areas they direct, a volunteer gets their own asks, finance gets gifts, staff and administrators get the whole church. Changing the web address, editing the page, or calling the database directly with a person’s session yields the same limited view.
These rules are tested by an automated suite that signs in as members of two churches with every role and asserts that each sees exactly their own rows and nothing of the other church’s. The suite runs before changes ship.
Roles
Roles are set only by an administrator, and the database refuses to remove a church’s last administrator. Every change to people, groups, gifts, messages, volunteers and settings is written to an audit log with who made it and what changed; the log cannot be edited or deleted from the app.
Signing in
There are no shared passwords. People sign in with a link or six-digit code sent to their email, or with a personal password they set themselves. Passwords are stored only as salted hashes. Sessions are short-lived tokens that refresh while you use the app and end when you sign out. Access is granted by email address, so a person’s inbox is the key to their account; protect it with a strong password and, where offered, two-step verification.
Encryption
All traffic between your browser and the service is encrypted with TLS. The database and uploaded files are encrypted at rest by Supabase using AES-256. Uploaded files sit in a private storage bucket; when someone opens one, the app requests a signed link that works for one hour and only for a file that person is allowed to see.
Payments
Trellis never sees a card or bank number. Gifts are entered on Stripe’s hosted checkout on the church’s own connected account, and the church’s billing card is entered on Stripe’s billing pages. Stripe is a PCI DSS Level 1 service provider. Trellis stores only Stripe’s reference numbers and the amounts, and every message Stripe sends back to Trellis is checked against a signing secret before it is trusted.
Church messages and serving reminders are sent through Resend from the church’s own domain, which the church proves it controls by adding DNS records before anything is sent. Delivery reports coming back are checked against a signing secret. The unsubscribe link in every email is a signed token, so it cannot be forged to unsubscribe someone else, and it asks for a confirming click so a link scanner cannot unsubscribe people by accident.
Scheduled jobs
The daily reminder job runs on Vercel and is accepted only with a secret the server holds. Jobs and webhooks use a service credential that is never sent to the browser and lives only in the hosting environment.
Where it runs
The database, file storage and sign-in are provided by Supabase in its US East (Ohio) region. The app is served by Vercel. Payments run on Stripe and email on Resend. All four publish their security practices and hold SOC 2 Type II reports. Trellis does not run its own servers.
What Trellis doesn’t do
No analytics, no advertising, no tracking scripts, no third-party fonts loaded from services that track you, and no selling or sharing of information for anyone else’s purposes. The app loads from a single origin and talks to a single database.
Backups and recovery
The database is backed up daily by Supabase under the plan Trellis holds, and point-in-time recovery is used where that plan includes it. Uploaded files are stored redundantly. Restoring from backup restores every church at once; Trellis does not offer per-church restores today.
Changes to the software
Trellis is deployed as a whole and can be rolled back to a previous version in minutes. Database changes are applied as recorded migrations, in order, and the isolation suite runs against them first. Only the people Trellis has authorized can deploy or run migrations.
What people who sign in are responsible for
- Keep your sign-in link, code and password to yourself. Never forward a sign-in email.
- Lock your phone and laptop. Sign out on shared devices.
- Don’t screenshot rosters, notes, gifts or volunteer lists into group chats or personal notes apps beyond what the work needs that week.
- Record only what helps you care for people, and write as if they could read it.
- Tell your church’s administrator the same day if a device with Trellis open is lost or stolen, or if you think someone else has used your account.
If something goes wrong
If Trellis learns that information has been exposed to someone who should not have seen it, it will find out what was affected, close the gap, and tell the affected churches promptly and without waiting for every detail, so they can tell the people involved. Where the law requires notice to a regulator or to individuals, Trellis will help the church give it or give it itself.
Reporting a problem
If you find a security problem, a way to see something you shouldn’t, or anything that looks wrong, write to nadirmims@sgmtllc.com. Describe what you saw and how to reproduce it. Please don’t look further than you need to in order to report it, and don’t share it with others until it is fixed. Trellis is grateful for reports made in good faith and will not pursue anyone who reports responsibly.
Changes
This page is updated when the way Trellis is protected changes. The date at the top shows the current version.