Are there any examples of encrypting rows before storing the data in convex and then decrypting when that data is queried?
#Encrypting Rows Before Storage
raw hinge
rugged haloBOT
Hi @raw hinge. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
Yes, there are examples and discussions about encrypting data before storing it in Convex and decrypting it when queried.
A concrete example is the "Whisper" app, which implements end-to-end encryption on top of Convex. In this approach, the data (a secret message) is encrypted on the client side using AES before being sent to Convex. The encrypted data is stored in Convex, and only the client (with the password) can decrypt it. The decryption also happens on the client side after fetching the encrypted data from Convex. Here’s a simplified flow:
- Encryption before storage:
const encryptedSecret = CryptoJS.AES.encrypt(secret, password).toString(); await createWhisperMutation(name, encryptedSecret, passwordHash, creatorKey, expiration); - Decryption after retrieval:
const encryptedSecret = useQuery(api.readSecret.default, name, accessKey); const decrypted = CryptoJS.AES.decrypt(encryptedSecret, password).toString(CryptoJS.enc.Utf8);
This ensures that the unencrypted data never exists on the server—only encrypted blobs are stored and transmitted. The password (or key) is never sent to Convex, so only clients with the key can decrypt the data. This is a true end-to-end encryption pattern, and you can find more details and the full source code in the End-to-End Encryption with Convex post.
Additionally, there are discussions in the Convex community about encrypting sensitive data (like PII or API keys) before storing it in Convex. The recommended approach is to encrypt data on the client or in an action (using a key stored in an environment variable or external secrets manager), store the encrypted data in Convex, and decrypt it only when needed, ideally outside of queries for security and architectural reasons. However, Convex does not currently provide built-in field-level encryption; you must implement this pattern yourself as shown above End-to-End Encryption with Convex.
If you need to perform decryption on the server (e.g., using AWS KMS), you should use an action, since queries cannot call actions or perform asynchronous decryption. The decrypted data should not be stored in the database, but returned directly to the client as needed. This is discussed in this Discord thread.
In summary:
- Encrypt data before storing in Convex (client-side or in an action).
- Store only encrypted data in Convex.
- Decrypt data after retrieval (client-side or in an action, not in a query).
For a full example, see the Whisper app’s implementation.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
raw hinge
@rugged halo WorkOS vs better-auth
rugged haloBOT
Let me check the knowledge base for you again. One moment! :books:
When comparing WorkOS AuthKit and Better Auth for use with Convex, here’s what the knowledge sources reveal:
WorkOS AuthKit
- Integration: There is an official guide for integrating WorkOS AuthKit with Convex, and a template project exists (template-convex-nextjs-authkit). WorkOS is positioned as a strong choice for B2B apps, especially if you need SSO and user management at scale. It is free for up to 1M users and is actively mentioned in Convex’s official documentation as a recommended third-party provider Convex & WorkOS AuthKit.
- Dev Experience: There have been some issues reported around token refreshes causing brief unauthenticated states and component remounts, but recent updates and community fixes have improved the experience. The integration is considered stable for most use cases, especially for web/Next.js apps. There is ongoing work to improve the experience and documentation, and the integration is actively maintained Discord thread.
- Mobile Support: Some users have noted that WorkOS does not have official React Native/Expo support yet, which may be a limitation if you need cross-platform support Discord thread.
Better Auth
- Integration: Better Auth is also compatible with Convex, and there is a dedicated integration guide. It is described as being in alpha, so it may have more issues or breaking changes than the WorkOS integration. The documentation is improving, and there is an active community around it.
- Dev Experience: Some users are experimenting with Better Auth as an alternative to WorkOS, especially if they run into issues with WorkOS. However, it is still considered alpha and may not be as stable as WorkOS at this time Discord thread.
- Features: Better Auth is designed to be flexible and framework-agnostic, but some features (like device/terminal auth) may require custom setup Better Auth Basic Usage.
Community Sentiment
- WorkOS is generally seen as more mature and stable, especially for B2B and SSO use cases.
- Better Auth is promising, especially for those looking for more flexibility or who want to avoid vendor lock-in, but it is still in alpha and may require more effort to set up and maintain.
- If you are building a large Next.js/React app and need robust SSO, WorkOS is likely the safer choice right now. If you want to experiment or need something more customizable, Better Auth is worth exploring, but be prepared for potential issues as it matures Discord thread.
In summary:
- WorkOS: More mature, better for B2B/SSO, official Convex support, some quirks with token refresh but actively maintained.
- Better Auth: More flexible, alpha status, active community, may require more setup and troubleshooting.