← Security at QuotaGuard

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.

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.

Diagram of QG Shield inbound requests: HTTPS traffic routed by SNI through the Shield proxy without TLS termination, to an allow-listed trusted IP.
Shield inbound: SSL passthrough, routed by SNI, never 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.

Diagram of QG Shield outbound requests: encrypted CONNECT wrapper terminated for authentication and routing; the inner TLS session to the destination is not decrypted.
Shield outbound: outer wrapper terminated for auth and routing; inner session never decrypted.

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.

Diagram of QG Static outbound requests: unencrypted CONNECT wrapper read at the proxy hop; customer payload to the destination stays end-to-end encrypted over HTTPS.
Static outbound: plaintext CONNECT wrapper; HTTPS payload stays end-to-end encrypted.

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 re-encrypts to the destination. 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.

Diagram of QG Static inbound requests: TLS terminated at the proxy with a QuotaGuard or customer certificate, routed at the HTTP layer, re-encrypted to the destination.
Static inbound: SSL termination at the proxy, by design.

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.
  • 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.

4. What is not in the customer traffic path

  • Cloudflare provides DNS only. Once DNS resolves to the Shield static IP, traffic goes directly to that IP. Cloudflare is not in the path of customer proxy traffic.
  • 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 runs on Amazon Web Services in a single AWS account across 12 regions. 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 inboundNot terminated; SNI routingNoNo
Shield outboundOuter TLS wrapper terminated for auth and routing; inner session not decryptedNoHost and port only
Static outboundUnencrypted CONNECT wrapperNoHost and port for HTTPS; full URL for plain HTTP
Static inboundTLS terminated at the proxyYes, by designFull 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.

7. Governance

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