Architecture & Data Flow

Last updated: 2026-06-23 · Operated by Aikey, Inc.

Quick reference for reviewers. This page answers Ring partner onboarding questions about data flow and architecture. Two sections, each at its own anchor:

#storage — Data storage locations and systems
#flow — Data flow between systems

1. Data Storage Locations and Systems

StrangerAIert runs in a single AWS region (configured at deploy time; AWS_REGION environment variable). The table below lists every category of data we store, where it lives, and how long it is retained. Aikey, Inc. is the data controller. All storage systems are accessible only by the StrangerAIert application and its operators.

Data category	Storage system	Location	Retention
User account (email, hashed password, time zone, country)	AWS RDS PostgreSQL AWS	Configured AWS region	While the account is active
Ring OAuth refresh / access tokens	AWS RDS PostgreSQL AWS	Configured AWS region	Until the user disconnects Ring
Camera motion video clips (mp4, audio included)	AWS S3 AWS	Configured AWS region	90 days, then deleted by a daily automated cleanup. The owning account row in the database is marked anonymized at the same time (S3 URL set to NULL).
Webhook event audit log	EC2 local JSONL EC2	Same region as compute	90 days, then pruned automatically — matches Ring's own ~90-day clip availability, so older entries cannot be used to re-pull video anyway.
Local cache of webhook clips (mp4 + faces.json)	EC2 local EC2	Same region	90 days, then deleted. S3 copy stays; we re-pull from S3 if needed for re-analysis.
Face crops + FAISS embeddings — registered persons (Familiar / Watchlist)	EC2 local EC2	Same region	Kept while the person stays registered (so future visits still match).
Face crops + FAISS embeddings — unregistered persons	EC2 local EC2	Same region	Kept in full while the person is active (any visit in the last 90 days). After 90 days of inactivity, trimmed to one best face per viewing angle (front / half-profile / profile) plus the matching FAISS vectors — enough to keep re-identifying the person when they next appear without the cost of storing every detected frame.
Person tracker metadata (sessions, categories, names)	EC2 local JSON EC2	Same region	While the account is active. Inactive entries get an `archived` marker after 90 days but the metadata itself is preserved for history.
Browser session cookie (login state)	User browser Browser	User's device	30 days inactivity then expires
Web Push subscription endpoint	EC2 local JSON EC2	Configured AWS region	Until the user disables notifications
Application + access logs	EC2 local (rolled) EC2	Configured AWS region	10 MB × 5 files (auto-rotated)
Webhook receipt audit log	EC2 local JSONL EC2	Configured AWS region	90 days (see above row)

Diagram — storage map

Where each category lives, grouped by system:

Sub-processors

Amazon Web Services (AWS) — EC2 compute, S3 object storage, RDS PostgreSQL, SES transactional email. Single configured AWS region. Acts as a sub-processor only; AWS does not access StrangerAIert customer data on its own initiative.
Let's Encrypt — TLS certificate issuance for strangeralert.aikey.ai. Stores no customer data; only manages the domain's HTTPS certificate.
Web Push providers (FCM / Mozilla autopush / Apple Push) — deliver scheduled report notifications to the user's browser or device. They receive only the encrypted push payload (title + summary line, no identifying user data beyond the device's own push subscription).

We do not use any advertising network, analytics platform, or third-party AI vendor that processes face data on our behalf.

2. Data Flow Between Systems

The numbered flows below describe how data moves through StrangerAIert. Each flow stays inside the configured AWS region for compute and storage; the only egress is the encrypted Web Push delivery to the platform push provider (FCM / Mozilla / Apple), which routes the payload to the user's device.

Flow descriptions

① Webhook — Ring posts motion_detected or ding events to the application's webhook endpoint over HTTPS with HMAC-SHA256 signature. Webhooks include event metadata only, no media.
② Clip request — On webhook receipt, our server calls Ring's clip download API with the event timestamp and a short duration (~20 seconds). Audio is included per the user's Ring camera configuration.
③ Clip download — Ring responds with an mp4 stream we save to a working directory on the EC2 instance for analysis.
④ Upload clip — Same mp4 is uploaded to S3 in the same AWS region for durable storage and dashboard playback.
⑤ User data — EC2 reads and writes account rows (email + password hash + time zone) and Ring OAuth tokens to RDS. Tokens are refreshed before they expire (the application uses the refresh_token Ring returns at login); password verification runs on every login.
⑥ Password reset — When the user requests one, EC2 sends a single-use reset link via SES to their registered email address. No inbound mail.
⑦ Web Push — At the user's local 08:00 / 18:00 / 23:00, EC2 builds a per-window summary and POSTs a VAPID-signed encrypted payload to the user's push subscription endpoint (FCM / Mozilla autopush / Apple Push).
⑧ Device push — The push provider routes the encrypted payload to the device. The provider cannot read the payload (end-to-end encrypted with the browser's keys).
⑨ Dashboard — User navigates to https://strangeralert.aikey.ai/service over HTTPS. EC2 serves filtered data scoped to the requesting user's user_id and camera ownership.

Security notes

All HTTP is TLS 1.2+ (Let's Encrypt certificate, auto-renewed).
Ring webhook payloads are rejected unless the request carries a valid HMAC-SHA256 signature in the X-Signature header, verified against the application's webhook secret (shared with Ring at app registration).
Web Push payloads are encrypted with the recipient browser's public key per the Web Push Protocol (RFC 8291); the push provider cannot read them.
Session cookies are issued with HttpOnly, Secure, and SameSite=Lax.
Ring OAuth tokens are stored only server-side in RDS — they are never sent to the browser. RDS rows benefit from AWS RDS storage-layer encryption when the instance is configured with it (default for new RDS instances since 2017).

Cross-references

The retention periods and user controls in this diagram are described in more detail in the Privacy Policy — in particular Section 9 (Data Sharing and Sub-processors) and Section 10 (Data Retention).