Security & Architecture
Last updated: October 11, 2026
This page documents where Home Field (Vault, Coyote Cam, Big Screen, and Relay) stores data, how data moves between systems, and the safeguards protecting it. See also our Privacy Policy.
Encryption
- In transit: All connections use TLS 1.2+ — between users and the app, and between the app and Ring, Google, Supabase, SendGrid, and Twilio. No data ever moves over an unencrypted channel.
- At rest: The database and object storage are encrypted at rest (AES-256) by our infrastructure provider. Ring and Google OAuth tokens are additionally encrypted at the application layer (AES-256) before being written to the database, so tokens are unreadable even with raw database access.
- Key management: Application encryption keys and API credentials live only in the hosting platform's encrypted environment configuration — never in source control. Webhook authenticity is verified with per-app HMAC-SHA256 signatures using constant-time comparison.
Television access tokens are never stored in readable form — only a SHA-256 hash, so a copy of the database cannot be used to watch anyone's cameras. Live-session URLs are HMAC-signed to the device that opened them.
Data storage locations and systems
| System | Location | What it holds |
|---|---|---|
| Supabase (Postgres) | AWS us-east-1 (N. Virginia, USA) | Accounts, encrypted OAuth tokens, device records, clip/sighting metadata, preferences |
| Supabase (object storage) | AWS us-east-1 | Coyote Cam sighting media (snapshot + clip per confirmed sighting) and one snapshot per Relay alert, in private buckets |
| User's own Google Drive, OneDrive, or S3-compatible bucket | User's own Google, Microsoft, or storage provider account | Vault clip backups — never stored on our servers |
| Supabase (Postgres) — Big Screen | AWS us-east-1 | Per paired television: a name the owner chose and a SHA-256 hash of its access token. No video, ever. |
| Supabase (Postgres), Relay | AWS us-east-1 | Alert contacts (names, phone numbers, consent records), alert rules, escalation order, and alert records, readable only by the server. No video. |
| Vercel (serverless compute) | USA | No persistent storage; processes requests in memory only |
| SendGrid / Twilio | USA | Transient delivery of alert emails, opt-in SMS, and Relay alert texts and voice calls |
Data flow between systems
Coyote Cam — detection flow
- Ring sends a motion-event webhook to our API (HMAC-SHA256 signature verified before processing).
- The event is queued; a worker retrieves a snapshot for the camera from Ring's API over TLS.
- The snapshot is sent to Google's Gemini API for classification (inference only; not used for training; not retained by us unless a coyote is confirmed).
- Not a coyote → the snapshot is discarded. Nothing is stored.
- Coyote confirmed → snapshot and clip are stored in object storage under the owning user's account, and the user is alerted by email (SendGrid) and optional opt-in SMS (Twilio).
Big Screen — live view flow
- The television authenticates to our API with an opaque device token, issued only after a signed-in person entered the pairing code shown on screen. The TV never holds Ring credentials.
- Our API asks Ring for a live session for a camera the owner has shared, signing the request with the account's token server-side.
- Our API passes only connection setup (the WebRTC SDP offer and answer) between the television and Ring. Live video and audio then travel directly from Ring to the television over encrypted WebRTC (DTLS-SRTP). Live media never passes through our API or any Home Field server, and nothing is recorded.
- Ring ends each session at about 60 seconds; the app opens a replacement before the cutoff and closes the outgoing one explicitly, so cameras are never held awake.
- Only the owner's per-camera choices are stored, and they are enforced on our side, not on the TV.
Relay: alert flow
- Ring sends a doorbell, motion, or device offline/online webhook (HMAC-SHA256 signature verified before processing).
- A worker matches the event against the owner's rules (camera, event type, schedule, cooldown). No match, no alert.
- The escalation runs in Inngest: Twilio texts or calls each contact in the owner's order until someone taps Got it or presses 1. Contacts who have not accepted the invite, or have not allowed calls, are skipped.
- Ten seconds after the alert, a worker fetches one snapshot from Ring's Snapshot API and stores it in a private bucket. The alert page serves it through a signed URL that expires in 5 minutes.
- If the owner added webhooks, the alert's id, type, severity, title, details, camera name, time, and alert page link are POSTed to them, signed with HMAC-SHA256. Private and internal addresses are refused.
Uptime: camera status flow
- Ring sends a device offline or online webhook (HMAC-SHA256 signature verified before processing).
- The outage is recorded. After the owner's grace period, if the camera is still offline, one alert goes to the owner's verified phone by text, or by email. No video or snapshot is fetched.
- When the camera has stayed online for 5 minutes, the owner gets one back-online note. A scheduled check asks Ring for device status to close outages a lost webhook left open.
- Outage history older than 90 days is deleted automatically.
Gate Log: arrivals flow
- Ring sends a doorbell or motion webhook (HMAC-SHA256 signature verified before processing). Only doorbell presses and motion Ring labels person or vehicle are logged.
- The event is added to the owner's log, or merged into a recent entry from the same camera and kind.
- Ten seconds later, a worker fetches one snapshot from Ring's Snapshot API and stores it in a private bucket. The dashboard serves it through a signed URL that expires in 5 minutes. No AI is applied, and no plates or people are identified.
- Optional: an arrival during quiet hours sends an alert through the same escalation engine as Relay. Entries and snapshots older than 90 days are deleted automatically.
Vault — backup flow
- Ring sends a motion/doorbell webhook (signature verified).
- A worker retrieves the clip from Ring's API and streams it directly into the user's own storage (Google Drive, OneDrive, or an S3-compatible bucket).
- Only metadata (camera, timestamp, saved-file reference) is recorded in our database. The video itself never persists on our systems.
Access controls
- Every database row is scoped to its owning user with Postgres Row-Level Security; API routes require an authenticated session.
- Sighting media is served only through short-lived signed URLs scoped to the owner (or a share link the owner explicitly created). Relay snapshots are shown only on the alert page, through signed URLs that expire in 5 minutes.
- Storage access is minimal: Google Drive access is limited to files Home Field itself creates (
drive.file); OneDrive access is limited to Home Field's own app folder (Apps/Home Field); S3-compatible storage uses an access key the user limits to one bucket, and Home Field tests write, read, and delete before saving it. OAuth tokens and storage access keys are encrypted at rest. Ring access uses Ring's official Partner API scopes. - Production credentials are restricted to Home Field's operator; no human reviews customer footage.
Backups and resilience
The database is backed up automatically every day by our managed database provider. Object storage is redundantly stored by the provider. We intentionally hold minimal data — Vault media lives only in the user's own storage, so a failure on our side never puts a user's video library at risk.
Home Field is a third-party app and is not affiliated with, endorsed by, or sponsored by Ring or Amazon. Ring is a trademark of Ring LLC.