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. 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.
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, live chat, and the WebRTC layer that carries a live room or webinar.
What it receives
Uploaded video, audio, images and attachments, plus live chat messages and the real-time media of anyone in a room.
Railway
Runs the transcoding worker that turns an uploaded video into streamable quality levels and writes its captions.
What it receives
The uploaded media file and the database row describing it.
Amazon Web Services (SES, in us-east-1)
Sends effectively all outbound email and reports what became of it.
What it receives
Recipient email addresses and the content of the messages sent to them, plus delivery, bounce and complaint events.
Resend
Sends sign-in codes, and receives calendar replies to event invitations.
What it receives
The email address a sign-in code is going to, and the content of a calendar reply sent back to us.
When
Sign-in codes ride Resend for every community that has not connected its own sending domain, and it is also the backup path when a coach's own domain fails, so that an email outage can never lock somebody out of their account.
Stripe
Takes every payment, and bills coaches for their Drry plan. Money moves through a Stripe account in the coach's own name.
What it receives
Buyer name, email and payment details, which go to Stripe directly. Card numbers never reach Drry's servers.
Groq
Runs the language and speech models behind three features: transcribing audio and video, screening posts and messages when AI moderation is switched on, and writing the recap after a live session.
What it receives
The audio of the media being transcribed, the text of a post or message being screened, and the transcript of a recorded session.
When
Transcription runs on published media for every community. Screening runs only where a coach has switched AI moderation on, and recaps only where meeting notes are armed for a session.
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, when a coach asks for one.
What it receives
The access token for the Google account the coach connected, and the request to create a meeting space.
When
Only for a community that has connected a Google account, and only for the sessions it generates a link for.
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 and a block of ciphertext: the notification 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 carry our messages without receiving our members' data, 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 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. Email hello@drry.com and we will send one for signature. If your own DPA form is what your organisation needs to use, send it over and we will work from that instead.
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.