Encryption

Datafly Signal encrypts data at every layer — in transit between all components and at rest in storage. This page details the encryption mechanisms used throughout the platform.

Encryption in Transit

Browser to Ingestion Gateway

All event data sent from Datafly.js to the Ingestion Gateway is encrypted using TLS 1.2+. The customer’s subdomain (e.g., data.example.com) is served with a valid TLS certificate.

Service to Service

Internal communication between Datafly services within a Kubernetes cluster uses pod-to-pod networking. For deployments that require service mesh encryption (e.g., compliance with zero-trust network policies), Datafly is compatible with Istio and Linkerd mTLS.

Kafka, Redis, and PostgreSQL connections support TLS. In production deployments with managed services (MSK, ElastiCache, RDS), TLS is enabled by default:

Service to Vendor APIs

All Delivery Worker connections to vendor APIs use TLS 1.2+. Vendor API endpoints universally require HTTPS. The Delivery Worker validates the vendor’s TLS certificate and rejects connections with invalid or expired certificates.

Encryption at Rest

Vendor API Credentials

Vendor API credentials (API secrets, access tokens, OAuth refresh tokens) stored in PostgreSQL are encrypted using AES-256-GCM before being written to the database. The encryption key is provided via the ENCRYPTION_KEY environment variable.

Plaintext credential → AES-256-GCM encrypt → Store ciphertext + nonce in PostgreSQL

When a Delivery Worker needs credentials at delivery time, it decrypts them in memory. Credentials are never written to disk in plaintext.

Database (PostgreSQL)

In production, PostgreSQL should use Transparent Data Encryption (TDE):

TDE encrypts the entire database at the storage layer, protecting against physical disk theft or snapshot exfiltration.

Kafka

In production Kafka deployments:

Cross-Domain Identity Tokens

The Identity Hub uses AES-256-GCM to encrypt cross-domain identity tokens. When a user navigates between domains that share a Datafly deployment, an encrypted token is passed via URL parameter to link the anonymous IDs:

Plaintext: { "dfid": "abc123", "exp": 1740500400 }
  → AES-256-GCM encrypt with ENCRYPTION_KEY
  → Base64url encode
  → Append to URL: ?_dft=<encrypted_token>

The receiving domain’s Ingestion Gateway decrypts the token to recover the anonymous ID and link the sessions.

PII Hashing

When PII hashing is enabled in the Org Data Layer, specified fields are hashed with SHA-256 before being delivered to vendor APIs:

Email: "jane@example.com"
  → Lowercase + trim
  → SHA-256 hash
  → "a1b2c3d4e5f6..."  (delivered to vendor)

This allows vendors like Meta and Google to perform identity matching using hashed identifiers without receiving raw PII.

Key Management Summary