Security at Wethr

Wethr is built on a fully managed, serverless infrastructure stack. There are no servers for us to patch, no operating systems to maintain, and no hardware to secure. Every component is a managed service from a provider with its own security certifications and SLAs.

This document explains how each layer of the stack is secured, how church data is isolated from other churches, how access is controlled, and what happens when something goes wrong. We publish this so your church's leadership can make an informed decision about trusting Wethr with your congregation's data.

Wethr runs on a fully serverless stack, distributed across industry-leading managed providers. Each provider is responsible for the physical and network security of the underlying hardware. Wethr is responsible for how we configure and use those services.

All infrastructure is hosted in US-based data centers. Data does not leave US jurisdiction under normal operation.

Every church in Wethr is a completely isolated tenant. One church can never access another church's data — not through the application, and not through the database. This isolation is enforced at two independent layers.

Layer 1 — Application (tRPC middleware)

Every authenticated request resolves the caller's church_id from their verified session JWT — never from user input. All API procedures receive this church_id from the request context and inject it as an explicit filter into every database query. It is architecturally impossible for a user with a valid session for Church A to query Church B's data — the wrong church_id would return no results.

Layer 2 — Database (Row Level Security)

Supabase Row Level Security (RLS) policies are enabled on every table in the Wethr database. RLS enforces church_id scoping at the PostgreSQL level. Even if a bug in the application layer were to omit a church_id filter, the database would return only records matching the authenticated user's church. The application layer is the primary enforcement point; RLS is the backstop.

Subdomain isolation

Every church accesses Wethr via their own subdomain — for example, gracechurch.wethr.co. Vercel Edge Middleware intercepts every request before it reaches the application and resolves the subdomain to a specific church context. A valid session for Church A cannot be used to authenticate at Church B's subdomain — the session is rejected and the user is shown Church B's login screen.

All data in Wethr is protected by encryption at every stage — in transit between the browser and our servers, and at rest in our database and file storage.

Wethr uses a passwordless, email-based OTP (one-time passcode) authentication model. There are no passwords stored anywhere in our system — which eliminates an entire category of credential-based attacks.

Wethr uses a five-tier role-based access control (RBAC) model. Every user is assigned one or more roles, and every API endpoint enforces the minimum role required to access it. Role resolution happens fresh on every request — there is no stale permission state cached in a JWT.

Enforcement

Role enforcement is implemented at the tRPC API layer using procedure middleware. Every API endpoint is annotated with its minimum required role. If a user's resolved role does not meet the requirement, the endpoint returns an UNAUTHORIZED error before any business logic executes. Role changes take effect immediately on the user's next request — no re-login required.

User-uploaded files — PDFs, images, documents, chord charts, and audio — are stored in Cloudflare R2. The bucket is fully private. No file is ever accessible via a direct public URL.

Access pattern

All file access (both upload and download) uses short-lived presigned URLs generated by the Wethr API:

Files are organized in a per-church bucket structure. The Wethr API validates church membership and role before generating any presigned URL — ensuring that users can only access files belonging to their own church and within their permission scope.

Wethr's database is backed up automatically on a continuous basis. Our recovery capabilities ensure that data loss from any incident can be minimized and resolved quickly.

We take a strict minimum-access approach to our own team's access to customer data.

We maintain a documented incident response process. When a security incident is detected — whether by our monitoring systems, a third-party report, or internal discovery — we follow a structured response protocol.

We welcome security researchers and community members who identify potential vulnerabilities in Wethr. If you believe you've found a security issue, please report it to us before disclosing it publicly — we will work with you to investigate and resolve it promptly.

We do not take legal action against researchers who act in good faith, follow responsible disclosure practices, and do not access, modify, or exfiltrate customer data in the course of their research.

Platform security is a partnership. Wethr secures the infrastructure — but your church's administrators play an essential role in protecting your account from the inside.