How does Admaxxer store my credentials?

Admaxxer is a DTC analytics platform with built-in Meta + Google ad ops. Given the sensitivity of ad-account access, the first security question most teams raise is: how does Admaxxer store my credentials? The short version is that every token we hold — Meta user tokens, Google refresh tokens, and similar secrets — is encrypted with AES-256-GCM inside the application before it ever reaches the database, using a key that never sits in Postgres. ## The short answer Ad-platform credentials (Meta tokens, Google refresh tokens, and similar secrets) are encrypted with AES-256-GCM at the application layer before being written to Postgres. The encryption key lives outside the database so a DB-only breach cannot expose tokens. ## Full answer ### The encryption model Every write path that handles an ad-platform credential runs it through `server/crypto.ts`, which uses: - **AES-256-GCM** — authenticated encryption, so a tampered ciphertext fails to decrypt rather than silently returning garbage. - A **per-record IV** (initialization vector) generated fresh at encrypt time. - An **auth tag** stored alongside the ciphertext to detect modification. The plaintext token is never written to disk. Only the encrypted payload, IV, and auth tag land in the `ad_platform_connections` table. ### Where the key lives The `ENCRYPTION_KEY` is set as an environment variable on the application server, sourced from a secrets manager (Replit secrets in the managed product; whatever secrets store you configure when self-hosting). It is not stored in Postgres, not checked into the repo, and not exposed to the frontend. An attacker who dumps the database gets ciphertext and no way to decrypt it. ### Rotation and expiry Tokens are rotated proactively: - **Meta long-lived tokens** expire ~60 days after issue. A background cron refreshes them inside a rolling window (default 7 days before expiry) so active workspaces never hit an expired token. - **Google refresh tokens** do not expire under normal use, but Admaxxer revalidates them on every sync and emails you immediately if Google revokes a token so you can reconnect. ### Session and user auth Application sessions use an HTTP-only, signed cookie backed by Postgres session storage. Passwords are not stored at all — auth is magic-link or OAuth (Google, Apple). Magic-link tokens are single-use, expire in 24 hours, and are invalidated immediately on redemption. ### Deletion When a workspace disconnects an ad platform, the encrypted credential row is soft-deleted and scheduled for hard deletion on the next cleanup pass. Workspace deletion removes all associated credentials within the standard data-retention window. ## Related questions - [How does Admaxxer connect to Meta Ads?](/faq/how-does-admaxxer-connect-to-meta-ads) - [How does Admaxxer connect to Google Ads?](/faq/how-does-admaxxer-connect-to-google-ads) - [Is Admaxxer self-hosted?](/faq/is-admaxxer-self-hosted)