Security policy

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 the rules about who sees what live 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, the day’s check-in team gets the children checked in to that day’s sessions with their care notes and pickup details for that day only, and, to check a family in, can find any family with children by name or a phone’s last four digits and see the children’s first names, ages and allergies and the adults’ first names, finance gets gifts, staff and administrators get the whole church, apart from Check-in’s records, which only administrators, the role that runs Check-in and that day’s team see. The one exception is a child’s own family: when the church turns on door passes, anyone in the child’s household, or its second household, who signs in sees on Your week the child’s allergy and that day’s check-ins, never the care note or pickup note. Changing the web address, editing the page, or calling the database directly with a person’s session yields the same limited view. A few things the server does for someone, such as building an administrator’s full download or showing a person’s photo, read with Trellis’s own key instead, and the server checks who is asking before it reads anything.

A self-serve station, a device a church leaves at the door for families to check in with a door pass or family card, has nobody signed in on it. Its cookie holds a random secret, and the database keeps only that secret’s hash. The station’s database functions can be called only by Trellis’s server, never by a signed-in or anonymous browser, and each one first finds a live station by that hash, in a church with Check-in on, or refuses. Through them the station reads only what checking a family in needs: for a door pass or family card it is shown, the family’s name, the children’s first names and what suggests each one’s room, and the church’s rooms. It never reads a child’s last name, allergy, care note, pickup note or pickup code, except on the tags and stub it prints for check-ins it made in the last two minutes. After 5 codes that match nothing in a minute, it opens nothing until that minute is up.

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 on every proposed change to the database.

Roles

Roles are set by an administrator, except that staff may invite someone as a group leader; a person may hold several, 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. A Trellis account is made only by Trellis’s server, never by the sign-in form on its own: when someone starts a church, opens the demo, asks for a church’s Sunday link with an email the church already has, or signs in with an invitation waiting for them. Trellis confirms the email with a link before anything attaches to the account, and an invitation takes effect only once the invited person has confirmed their email.

Two-step sign-in (multi-factor authentication) adds a 6-digit code from an authenticator app after the first step, however that step was taken. It is required for anyone who is an administrator or in finance at any church, who have 14 days to set it up, counted from when the requirement began for them; anyone else may turn it on. The requirement is enforced by the database, not only by the web page: every request a signed-in person makes is checked first, and every table, file and private live channel carries a rule that refuses a session that skipped the second step or belongs to someone past their 14 days without it. Setting it up gives 10 recovery codes, each usable once and stored only as keyed hashes; using one removes the authenticator and signs the person out on every other device. After 5 wrong codes, the step is locked for up to 5 minutes. Turning it off needs a current code, and is not possible for anyone it is required for. The person is emailed when it is turned on or off and when a recovery code is used. Someone with no authenticator and no recovery codes writes to support, which confirms who they are before removing it.

Public forms

The forms anyone can reach (event sign-up, giving, Request a demo, opening the demo, a church’s Sunday link, sign-in and Start a church) check that a person, not a program, is filling them in, and limit how often they can be used from one place or for one email. Names given on them are kept to one line without web or email addresses, so a form can’t be used to send a church’s email carrying someone else’s link. A public sign-up that uses an email the church already knows waits for the office to confirm it is the same family before it joins one.

Encryption

All traffic between your browser and the service is encrypted with TLS, and browsers are told to use only encrypted connections (HSTS). The database and uploaded files are encrypted at rest by Supabase using AES-256. Files on the shelf 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. A church’s logo and staff photos, and the pictures and files placed in its emails, sit in public buckets so that public pages and people’s inboxes can show them; anyone with one of those addresses can open it. People’s photos sit in a private bucket and are shown only to people signed in to that church. Storage accepts only set types and sizes: logos and staff photos as PNG, JPEG or WebP up to 2 MB, people’s photos up to 1 MB, pictures and PDFs in emails up to 10 MB, shelf files as PDF, Word, PowerPoint, images or plain text up to 25 MB. Spreadsheet exports write anything that looks like a formula as plain text.

Every page also tells the browser what it may load: scripts only from Trellis and the check that screens out automated forms, connections only to Trellis, its database and that check. No Trellis page can be shown inside another website, so it can’t be dressed up to trick someone into clicking. The one exception is the giving page, which churches may place on their own website.

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. A church may connect a Stripe account it already has; the link is made on Stripe’s own sign-in and approval screen, tied to the church whose admin started it, and the church can withdraw it from its Stripe dashboard at any time, which turns off online gifts and paid event sign-ups in Trellis. An admin can likewise disconnect the account under Church settings, Payments, and connect another; gifts and payments already recorded stay, and are never edited: a correction is a refund or a new entry. Stripe reports back on two separate endpoints, one for the church’s own connected account and one for Trellis’s subscriptions, each with its own signing secret, and every message is checked against it before it is trusted. Trellis’s prices are created under fixed keys, so nothing about billing has to be typed into a configuration by hand.

Email

Church messages and serving reminders are sent through Resend. They go from send.trellischurch.app, a domain Trellis shares between churches and keeps separate from its own mail, until the church has its own sending domain, which Trellis sets up on request. Once the church proves it controls that domain by adding DNS records, they go from it; those records also sign every message (DKIM) and say which servers may send for the domain (SPF). Trellis’s own mail, such as sign-in links, goes out from mail.trellischurch.app under the same protections; an invitation goes out in the church’s name. A sender of the church’s own, for a team or a person, lives only on a domain the church has verified; a personal address made for a group leader is created by the platform on that domain, never on Trellis’s own, and only when the church has left the feature on. Until the church has a domain, a group leader writes from the church’s shared address under their own name. 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. The private link in an event confirmation is signed the same way, with a key of its own. The other links in emails, such as a one-tap serving answer, and the reply addresses share the unsubscribe link’s key, but each is signed for its one purpose, so none can pass for another. No signing key is the database’s.

Scheduled jobs

Seventeen scheduled jobs run on Vercel, two of them every hour, one every 5 minutes and one every hour on Mondays and Tuesdays: serving and care reminders, clearing private event answers after an event, deleting the day’s pickup codes, deleting a closed church once its 90 days are up, notices about a church’s billing, Lighthouse AI’s nightly reading and its Monday forecast and insights, deleting Ask Silas questions after 90 days, deleting change history and problem reports once their time is up, the Monday email to Trellis support of the questions help didn’t cover, and signing out anyone entering many wrong two-step codes or signing in again and again without one. Each 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. These four, which hold the church’s records, publish their security practices and hold SOC 2 Type II reports. Cloudflare checks the public forms. Anthropic reads for Silas and Lighthouse AI when a church’s administrator turns Silas on, answers Ask Silas’s help questions, which carry no church records, and helps Trellis draft replies to email sent to support. 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. There are two records of use: church emails report when they are opened, and, as a pilot, Trellis notes the day a signed-in person opens Your week or Sunday, read only by Trellis. The app loads from its own origin, plus the check on public forms, and talks to a single database.

Backups and recovery

The database is backed up daily by Supabase, and each backup is kept for 7 days. Every week an encrypted copy of the database and of every uploaded file goes to a storage provider separate from Supabase, where it is kept for 90 days and can’t be deleted early, even by Trellis. Only a key Trellis keeps apart from all of these services can open it. A restore of that copy was first tested on October 25, 2026, bringing back every record and file, and is tested again twice a year. 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. 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.
• 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.

The acceptable use policy says how to treat what you see in Trellis.

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 support@trellischurch.app. 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.