Data Flow

What is decrypted, logged, and stored in each of the four traffic modes.

1. Purpose and scope

This document describes how customer traffic and customer data move through the QuotaGuard Static and QuotaGuard Shield services, what is processed at each step, and where data is stored. QuotaGuard's encryption handling depends on the product and direction, and this document is the reference that underlies QuotaGuard's security-review and compliance answers. In every mode except Static inbound, the proxy does not decrypt the customer's application payload.

2. Traffic data flow

QuotaGuard's encryption handling depends on the product and direction. In every scenario except Static inbound, the proxy does not decrypt the customer's application payload to its destination.

Architecture overview: Traffic Path

This diagram follows outbound requests from your application through your QuotaGuard proxy to a destination, and inbound requests from outside callers through the proxy to your origin. It compares Static and Shield in both directions, showing where TLS is terminated, what the proxy can read, and what is logged. HTTPS payloads remain end-to-end encrypted for outbound traffic and Shield inbound; Static inbound terminates TLS at the proxy. Customer payloads are not stored in any mode.

QuotaGuard traffic architecture: outbound application requests and inbound caller requests pass through Static or Shield proxies. The diagram compares TLS termination, payload visibility, and URL logging for all four modes.

Traffic Path: request routing and encryption for Static and Shield, inbound and outbound. Open full-size diagram (PNG).

Shield inbound

The customer's client resolves the Shield hostname through DNS and connects directly to the Shield static IP. The proxy operates in TCP mode on the encrypted bytes and routes by SNI without terminating TLS. Inbound Shield is limited to port 443, port 80 redirects to HTTPS, and the only plaintext-forwarded path is the Let's Encrypt validation challenge, which carries no customer payload. The customer's payload is not decrypted.

Shield outbound

The customer's application opens a TLS connection to the proxy and sends a CONNECT request. The proxy terminates that customer-to-proxy TLS layer to read the CONNECT command and the proxy authentication credentials, which authenticates the customer and selects the destination. The customer's application traffic to the destination travels in a separate inner TLS session between the customer's app and the destination, which the proxy does not decrypt. For outbound HTTPS the proxy sees the destination host and port only.

Static outbound

The same outbound flow, except the customer-to-proxy connection wrapper (the CONNECT request) is not encrypted, so the proxy reads the proxy credentials and the destination host and port in plaintext at the proxy hop. The customer's payload to the destination remains end-to-end encrypted when the customer uses HTTPS. For plain HTTP the destination field holds the full URL, because an HTTP proxy must read the request line to forward it.

Static inbound

This is the one mode where QuotaGuard decrypts. The proxy terminates TLS using either a QuotaGuard-provided certificate (getstatica.com) or a customer-uploaded certificate that includes its private key, determines routing at the HTTP layer, and forwards the request to the destination, re-encrypting it when the customer's forwarding address uses HTTPS. In this mode the full request URL is visible at the proxy and is logged. Request and response headers, cookies, and bodies are not logged.

3. What is logged, and where it is stored

Connection metadata. The proxy records operational connection metadata: timestamps, source and destination host and port, byte counts, status codes, and proxy identifiers. This metadata is written to the traffic-log store in DynamoDB, encrypted at rest with AES-256, with a 60-day time-to-live and no long-term archive. Monthly request and byte totals per subscription are derived from these records and held in Redis Cloud in us-east-1; they contain no addresses and, for HTTPS traffic, no destinations, and they are retained without expiry. Automated account-level alerts carrying the subscription username are delivered to Slack.
Account and billing data. Customer account, subscription, and billing records are held in RDS MySQL, encrypted at rest with AES-256, in us-east-1.
Dashboard application logs. The customer dashboard's application log, which records request metadata and the administrative audit trail (which staff member acted, including account impersonation), is retained in Datadog in the United States for 450 days. It contains no proxy connection records.

Architecture overview: Control Plane & Data

This companion diagram shows dashboard access, account and billing records, traffic metadata, usage counters, administrative access, and third-party services. Connection metadata is stored in DynamoDB with a 60-day time-to-live; account and billing records are stored in RDS MySQL, and monthly usage totals are retained in Redis Cloud. It also distinguishes dashboard application and administrative logs from proxy connection records, and shows which third parties sit outside the customer proxy traffic path.

QuotaGuard control plane and data architecture: team browser access to the dashboard and Usage API, account records in RDS MySQL, connection metadata in DynamoDB, usage counters in Redis Cloud, restricted administrative access, and third-party service boundaries.

Control Plane & Data: dashboard access, data stores, retention, administrative access, and third-party boundaries. Open full-size diagram (PNG).

4. What is not in the customer traffic path

Cloudflare provides DNS, and routing for the public website only. Once DNS resolves to a static IP, traffic goes directly to that IP. Cloudflare is not in the path of customer proxy traffic or of the customer dashboard.
Billing and marketplace (Stripe, Heroku, AWS, Azure), transactional email (Postmark), website analytics (Plausible), support (Freshdesk), administrative email (Google Workspace), and source control (GitHub) are not in the customer traffic path; see the QuotaGuard subprocessor list.

5. Infrastructure and regions

QuotaGuard's proxy infrastructure runs on Amazon Web Services in a single AWS account across 12 regions; the customer dashboard is hosted by Gigalixir (see the subprocessor list). The AWS services in the path of customer Shield traffic are on the AWS HIPAA Eligible Services list. Customer TLS private keys are never uploaded for Shield, because Shield routes on SNI without terminating TLS. Hostnames and domains are customer-controlled metadata visible to the proxy for routing, and customers are instructed not to encode sensitive data in them.

6. Encryption by product and direction

Scenario	Customer-to-proxy connection	Proxy decrypts customer payload?	URL logged?
Shield inbound	Not terminated; SNI routing	No	No
Shield outbound	Outer TLS wrapper terminated for auth and routing; inner session not decrypted	No	Host and port only
Static outbound	Unencrypted CONNECT wrapper	No	Host and port for HTTPS; full URL for plain HTTP
Static inbound	TLS terminated at the proxy	Yes, by design	Full URL logged; headers and bodies not

The QuotaGuard data flow diagram set illustrates these four scenarios visually and is the canonical diagram for this document. Two system overview diagrams, Traffic Path and Control Plane & Data, accompany the set and show where connection metadata, account data and third parties sit around the proxy.

7. Governance

This document is owned by the founder, reviewed annually, and updated on any material change to the architecture.