How Ring data moves through Driveway Alert, where it is stored, and what is never stored. All storage under our control is inside Amazon Web Services (AWS), region us-east-1.Processing is not entirely inside AWS: the step that describes the vehicle runs on Erbacci-owned hardware outside AWS, reached through a relay hosted by a German infrastructure provider, and it retains nothing. Two paths reach outside AWS storage as well: that analysis path, which stores nothing anywhere; and, only if a customer switches on the optional telephone trigger, a telephony provider that keeps call detail records until we delete them. Both are described below.
Erbacci LLC · Last updated August 20, 2026 · Contact: info@erbacciltd.com
Correction (this revision, August 20, 2026). Until today this page described the Erbacci-owned hardware as performing only a coarse "is a vehicle present?" pre-screen, with the appearance analysis itself running on Amazon Bedrock inside AWS. That pre-screen has been removed and the roles have swapped: the appearance analysis now runs on the Erbacci-owned workstation, and Bedrock is the automatic fallback. The path itself — relay in Germany, GPU workstation in the United Arab Emirates — is unchanged, and was declared in and approved as part of our V5 and V7 Ring certifications. No new processor, no new country and no new company is involved; what changed is which step happens where. Earlier revisions of this page also stated that all processing ran inside AWS, and omitted the third-party provider that terminates TLS on that path (Contabo GmbH, Germany); both were corrected on August 7, 2026 and the provider is named in section 3 below.
1. Data flow between systems
The diagram above shows the inbound path only. The self-hosted vision analysis and the optional outbound gate trigger are not drawn; they are described in the steps below and in sections 3 and 4.
Motion event. Ring sends a signed webhook (motion event with a vehicle subtype) to our AWS Lambda endpoint. The HMAC signature is verified before any processing.
Queue. The event is placed on an SQS queue for asynchronous processing (with a dead-letter queue for failures).
Snapshot. The worker retrieves a single still image for that event via the Ring Partner API.
Vision analysis (first party, outside AWS). The still is analyzed by an Erbacci-owned vision model (an open-weights Qwen model via Ollama on an Erbacci-owned GPU workstation in Dubai, UAE, reached over TLS through an Erbacci-managed relay on Contabo infrastructure in Germany — the relay only terminates TLS and forwards over an encrypted tunnel; it processes and stores nothing). The analysis runs entirely in memory: no image is written to disk or retained anywhere on this path, and only a short text description is returned — make, model, body type, color, confidence. If that model is unreachable, times out or returns an unusable answer, the request falls back automatically to Claude Haiku 4.5 through Amazon Bedrock inside AWS (inference-only; the provider does not train on our traffic), which returns the same description.
Store snapshot + derived result. The minimal derived description and the match outcome (matches a vehicle the customer saved, or unfamiliar) are stored in DynamoDB. The still image itself is stored in a private, encrypted (AES-256) Amazon S3 bucket with public access blocked, so the customer can see who arrived. It is served only to the authenticated customer via a short-lived signed URL — never public — and is auto-deleted after 90 days (and immediately on unlink or account deletion).
Notify. The customer receives a push notification, or an email fallback when no push token is registered.
Optional gate trigger (off by default). Only if the customer has switched the feature on, consented, and armed that specific saved vehicle, one signal leaves our systems to a destination the customer supplied: either a single signed HTTPS request to a web address they entered, or a short unanswered ring to a telephone number they entered and verified, placed through a telephony provider. This is the only path in the whole product by which anything derived from a Ring event reaches a destination we did not choose. Section 4 below describes exactly what it carries. Delivery is at-most-once and is never retried.
What never happens: raw video is never persisted (only a single still snapshot per event is kept, privately and encrypted, and auto-deleted after 90 days); no facial or biometric recognition is performed; no license plates or other personally identifying vehicle information are read or stored; snapshots are never public and are never used to train any AI model; no camera image or snapshot link is ever included in a gate trigger, in an email, or in a push notification.
Who processes what, stated exactly. Vision analysis is performed by (a) an Erbacci-owned first-party model on Erbacci-owned hardware, reached over TLS through a relay operated by Contabo GmbH (Germany) — which terminates TLS and forwards over an encrypted tunnel, performs no analysis of its own and stores nothing — with the GPU workstation itself located in Dubai, United Arab Emirates, processing in memory only; and (b), only when that model is unavailable, Anthropic's Claude Haiku 4.5 via Amazon Bedrock, inside AWS, inference-only. Neither trains on our traffic and neither retains the image. If the optional gate trigger is enabled, a telephony provider and the customer's own chosen endpoint also receive data, as set out in section 4. That is the complete list; there is no other recipient.
3. Where processing happens (not only AWS)
Storage under our control is exclusively AWS us-east-1. Processing is not, and neither is the telephony provider's own record-keeping if a customer enables the optional telephone trigger. This is the section that says so precisely.
Everything described in sections 1–2. Retained per the table above
Vehicle appearance analysis (make, model, body type, color)
Erbacci — first party, Erbacci-owned GPU workstation, open-weights Qwen model via Ollama
Dubai, United Arab Emirates
Receives the still image, in memory only. Retains nothing. Returns a short text description
TLS termination + encrypted-tunnel forwarding on the analysis path
Contabo GmbH — third-party infrastructure provider hosting an Erbacci-managed relay
Germany
Terminates TLS and forwards over an encrypted tunnel. Performs no analysis and retains nothing. Named as a sub-processor in our privacy policy
Fine-grained appearance analysis (make, model, body type, colour)
Anthropic — Claude Haiku 4.5, via Amazon Bedrock
AWS us-east-1, United States
Receives the still image for inference only. Not trained on our traffic
Telephone ring / verification call (optional feature only)
Twilio Inc. (United States, Delaware)
United States
Number dialled, our caller ID, call time and duration. No camera data of any kind
Gate web request (optional feature only)
The customer's own chosen endpoint — not a processor we select, vet or control
Wherever the customer points it
The eight-field message in section 4. Governed by whoever operates that endpoint, not by us
Every frame that reaches this stage is analysed in full; nothing is filtered out beforehand. Any error, timeout or unusable answer from the self-hosted model falls through to the AWS fallback (fail-open), so an outage of that machine changes where the analysis runs, not whether it happens.
4. Optional gate trigger — the one outbound flow
This feature is off by default at four independent levels: a server-side master switch, a per-channel switch, the customer's own consent, and a per-vehicle arming step. Nothing below happens for a customer who has not enabled it. It is not an access-control system and not a security system; it is a convenience that can be late, missed, or wrong.
The web request carries exactly eight fields, always and only these: a format tag (spec); the event name (trusted_vehicle_arrival — the only value it can ever have); keyId, the version of the customer's derived signing key; deliveryId; sentAt; occurredAt; vehicle.id, the identifier of the customer's own saved vehicle; and test. Two further fields are sent only if the customer switches them on: vehicle.label (the name they chose) and deviceRef, a keyed pseudonymous camera reference that is stable within one account, meaningless outside it, is not the Ring device id, and from which the Ring device id cannot be derived.
It contains no image, no snapshot link, no email address, no Ring account identifier, no Ring device identifier and no location. It is signed with HMAC-SHA256 using a key derived per customer from a master held in AWS SSM Parameter Store (SecureString); no signing key material is ever stored in the users table. Anti-replay material (deliveryId, sentAt) sits inside the signed body, and we send no unsigned idempotency header.
The telephone trigger carries no content at all. It rings without waiting for the call to be accepted, and hangs up immediately if anything answers — equipment, a voicemail service or a person — having played nothing and recorded nothing. The single exception is the number-verification call the customer explicitly requests, which reads a six-digit code in a synthetic voice and nothing else.
Only "open" exists. There is no close, lock, stop or deny message in the protocol and no code path that can emit one. Delivery is at-most-once: any received HTTP status of any class is treated as proof the request landed and is never repeated, because a second pulse can reverse a moving gate. Pulses are deduplicated by delivery identifier, separated by a hard 120-second floor, capped per vehicle per day, gated behind a stricter recognition threshold than notifications, and the channel auto-disables after repeated failures.