What we hold, and how we hold it.
Running your community on Drry means trusting us with your members, your mailing list and your livelihood. This page is the honest account of how that works: what we encrypt, who else processes your data, how deletion behaves, and, at the bottom, what we do not have yet.
Six things that are true today.
There is no password to steal
Drry has no passwords. Signing in sends a one-time code to your email address, so there is no password hash in our database, nothing to reuse from another site's breach, and nothing for you to rotate. Sessions are cookies scoped to the single host you signed in on, so a session on one community is not a session on another.
We never see a card number
Payments are taken by Stripe, on a Stripe account in your own name, through Stripe's own checkout. Card details go from your buyer to Stripe and never touch our servers, which is also why your customers and their subscriptions remain yours if you leave.
Everything is encrypted in transit
Every connection to Drry, to the video gateway, and to our own services is over HTTPS. Our database and object storage providers encrypt what they hold at rest, and integration tokens (the keys a coach gives us when they connect Google, for example) are encrypted by us with AES-256-GCM before they are written down at all.
Your media is not public
Uploaded video, audio and attachments live in a private bucket. Nothing is served from a guessable URL: a video plays through a signed token that expires, an attachment download checks your membership first, and a locked lesson's media is refused by the route rather than merely hidden in the interface.
Deletion actually deletes
A member can erase their account, and a coach can delete a whole community, from inside the product. Both cascade rather than flagging a row as hidden: media objects, stored email bodies, queued mail and log entries go with them. This is the same mechanism that answers a GDPR erasure request, so it is exercised rather than theoretical.
Your data leaves as easily as it arrived
Contacts and members export to CSV on every plan, including free, and importing a list is a browser-side upload rather than a support ticket (up to 100 contacts on free, your whole list from Creator). We would rather you stayed because the product works than because leaving is difficult.
Everyone else who touches your data.
Drry is built on managed services rather than on our own machines, which means other companies necessarily handle parts of your data. This is all of them, with what each one actually receives, and underneath, the third parties we transmit to that are deliberately not on it, with the reasoning in each case.
Customer data is stored and hosted primarily in the United States. Cloudflare and Vercel deliver content and real-time traffic through their global edge networks, so data may transit or be briefly cached outside the United States while it is being served. List last updated November 8, 2026. We email creators and update this list at least 30 days before a new sub-processor handles your data, as our data processing agreement says.
Vercel
Hosting and delivery for the application itself.
What it receives
Every request to a Drry page or API passes through it, including the request metadata that comes with one.
PlanetScale
The managed Postgres database behind the product.
What it receives
The application record: accounts, communities, memberships and profiles, posts and comments, courses and progress, contacts, orders and subscription state.
Cloudflare
Object storage for uploaded media (R2), the gateway that streams gated video, the on-demand containers that transcode an uploaded video into streamable quality levels and generate its captions, live chat, the WebRTC layer that carries a live room or webinar, the transcript behind a session's meeting notes, the speech-to-text model (Workers AI) that writes live captions as people speak, and the registrar and DNS for domains bought through Drry.
What it receives
Uploaded video, audio, images and attachments, the uploaded media file and the database row describing it while it is transcoded, plus live chat messages and the real-time media of anyone in a room; while captions are on, short clips of each speaker's audio with the display names of the people speaking, written out and discarded, never stored; the audio of a session with meeting notes on; and the DNS records of a domain bought through Drry (registered in Drry's name, not the coach's).
Amazon Web Services (SES, in us-east-1 and us-west-2)
Sends all outbound email, sign-in codes included, receives calendar replies to event invitations, and reports what became of each message.
What it receives
Recipient email addresses and the content of the messages sent to them (sign-in codes included), the content of a calendar reply sent back to us, plus delivery, bounce and complaint events.
Stripe
Bills coaches for their Drry plan. Payments from a community's buyers are taken on a Stripe account in the coach's own name, which is a separate relationship between the coach and Stripe.
What it receives
For Drry's own platform billing: the coach's name, email and billing and payment details, which go to Stripe directly. Card numbers never reach Drry's servers.
Groq
Runs the language and speech models behind six features: transcribing audio and video, screening posts and messages when AI moderation is switched on, writing the recap after a live session, checking the pages and emails communities publish for phishing, malware, scams and spam, matching an Instagram comment or message to the Auto-DM reply it asks for, and writing the public reply Auto-DM posts under a comment.
What it receives
The audio of the media being transcribed, the text of a post or message being screened, the transcript of a recorded session, the text, links and custom code of a published page or an email, and the text of an Instagram comment or message with the coach's own description or example replies.
When
Transcription runs on published media for every community, and on a direct-message voice note when the member agrees to transcription. Screening runs only where a coach has switched AI moderation on, and recaps only where meeting notes are armed for a session. The abuse check runs in the background on every community's published pages and emails, once per version. Auto-DM's matching and AI replies run only on automations where a coach has switched them on: matching only when no keyword matched, and AI replies only for the public reply under a comment.
OpenAI
Screens content for prohibited and harmful material: the platform's own content-safety check, and every public reply Auto-DM's AI writes, before it is posted.
What it receives
The text or image being screened: posts, replies, messages and uploaded images in the background safety check, and the words of an AI-written Auto-DM reply. Not used to train their models.
When
The safety check runs in the background on every community. An AI reply is screened only where a coach has switched AI replies on for an automation.
Anthropic
Provides Claude, the AI model our team uses to build and maintain Drry.
What it receives
What our team works with while building and maintaining the service, which can include accounts and member records.
When
Only by our team: no feature sends data to Anthropic on our behalf. A coach who connects Claude as their own assistant shares what it reads under their own agreement with Anthropic.
Sentry
Collects application errors so failures are visible to us.
What it receives
Error reports and the technical context attached to them, which can include identifiers such as an organisation or user id.
Creates a Google Meet link for a session, reads busy times, and adds sessions to a connected Google Calendar, when a coach connects a Google account and asks for them.
What it receives
The access token for the connected Google account; busy times on the calendars the coach selects; and, for sessions the coach adds to Google Calendar, the session title, description, location, time and the booker's name.
When
Only for a community that has connected a Google account.
Meta (Instagram, Facebook)
Carries Auto-DM: tells us when somebody comments on or messages a coach's connected Instagram account or Facebook Page, and delivers the replies, messages and public comment replies Auto-DM sends from it.
What it receives
The access token for the Instagram account or Facebook Page the coach connected, which we use to read its profile and recent posts, to subscribe it to, or unsubscribe it from, these notifications, and to send its Auto-DM messages and public replies. In return Meta sends us the comment or message, the Instagram or Page-scoped id of whoever wrote it, and for a comment their username or, on Facebook, their name. What we send through Meta is the message or reply the coach wrote, addressed to that id or comment.
When
Only for a community that has connected an Instagram account or a Facebook Page to Auto-DM.
Apple (Push Notification service)
Delivers notifications to the Drry member app on a member's iPhone.
What it receives
The notification's words (for example who replied and the title of the post, or who sent a message, never what a message says), the community and screen it opens, the app's unread count, and a token identifying the app on that phone.
When
Only for members who use the Drry iPhone app and allowed it to send notifications.
Not on the list, and why
- Browser push services (Google, Mozilla, Apple)
- Sending a browser notification means POSTing to a push endpoint operated by whoever made the member's browser. What they receive is a routing token, the delivery metadata needed to route a message, and a block of ciphertext: the notification content is encrypted to a key held only by that browser (RFC 8291), so the push service can deliver it without being able to read it, and the endpoint identifies a browser install rather than a person. They receive what they need to route a message, not its content, which is why they are named here rather than above.
- Advertising and attribution scripts
- These load on drry.com's own marketing pages and never inside a coach's community: they are mounted in the marketing navigation, which does not render on a member surface. So they see visitors to this website, not anybody's members, and the privacy policy rather than this list is where they belong.
The privacy policy covers what we collect and why, and the terms cover the agreement itself. The accessibility statement covers the standard we build to and how to report a barrier.
The part most vendors leave out.
Drry is a small company. Here is what that means, stated by us rather than discovered by you halfway through a purchase.
No SOC 2, ISO 27001 or equivalent certification
We have not been through a formal security audit and do not hold a certificate. If your organisation requires one to buy software, we are not able to meet that today, and we would rather tell you now than at the end of a procurement process.
No third-party penetration test
Nobody external has been paid to attack Drry. The defences described on this page are real and are covered by an automated test suite, which is a different and lesser thing than an adversary having tried them.
No published uptime commitment
We do not publish an SLA and do not offer service credits. Drry runs on infrastructure with its own strong availability record, but we are not going to promise a number we have no way to enforce on your behalf.
No public status page yet
If something is broken, the honest answer today is to email us and we will tell you what we know. A status page worth reading needs monitoring behind it, and we would rather build that first than publish a page that is green during an outage.
The questions procurement asks.
Can I get a data processing agreement?
Yes. Every creator is covered by our data processing agreement at drry.com/legal/dpa, on every plan, at no extra charge and with no signature needed. Email hello@drry.com if your organisation needs a countersigned copy or to use its own form.
Where is my data stored?
In the managed services listed on this page. The database and object storage are run by PlanetScale and Cloudflare respectively, the application runs on Vercel, and outbound email goes through Amazon SES in the us-east-1 region. We are a small company and we have not built our own data centre, which we think is the right answer for a product this size.
Who at Drry can see my community's data?
Support and engineering access is limited to the people who run Drry, and it exists: someone has to be able to fix a broken import or investigate a failed payment. There is an operator console that can list communities and suspend one, and it is limited to a named list of accounts. We do not read your community's posts or your members' messages as a matter of course.
What happens to my data if Drry goes away?
The most important part is already outside our control: payments run through your own Stripe account, so your customers and their subscriptions belong to your business and would survive us. Everything else exports, and your content is yours. We would give notice and time to move rather than switching anything off abruptly.
How do I report a security problem?
Email hello@drry.com with what you found and how to reproduce it, and we will reply. We do not run a paid bug bounty, and we would rather hear about something quietly than read about it later.
Something here not answered, or answered in a way that does not fit how your organisation buys software? Write to hello@drry.com and a person will answer.