Honestly, We Got Attacked — But Your Data Is Safe
Reverie Team
12/1/2025
It All Started with "Free"
Two weeks ago, we made a decision: launch free AI models to let more users experience Reverie.
That night, the team cracked open some Pepsi to celebrate. (Yes, specifically Pepsi.)
We clinked our cans together, watching the user signup numbers climb in real-time. Someone pulled up a growth projection chart. The vibes were good.
72 hours later, we understood why experienced founders always look slightly tired.
What followed was a four-wave attack sequence that felt like a boss rush — except we were learning the mechanics while getting hit.
But first, the most important thing: Your account data, conversations, and personal information have never been compromised. They're safe now and will remain safe. We have a dedicated security team monitoring 24/7, and these attacks targeted our resources and wallet, not your data. The attackers wanted our bandwidth and money — your conversations with your AI companions were never at risk.
Now, let's walk through what happened.
Wave 1: The Crawler Army
What Happened
Day two after going free. Morning standup. Engineer casually mentions: "Hey, our character API got a few hundred times more requests yesterday."
Us: "Wow, the free launch is really taking off!"
Engineer: "...but DAU barely moved."
Awkward silence.
We dove into the logs and discovered crawlers systematically harvesting our public character data. Names, bios, avatars — the publicly visible information. Being vacuumed up by bots.
To be clear: the core character descriptions, personality settings, and other private creator content were never exposed — only creators can see those. But even scraping public info at industrial scale is frustrating when you're trying to build a healthy platform.
How We Responded
- Implemented pagination limits on character discovery (you can browse, but you can't download the entire library)
- Deployed intelligent rate limiting that distinguishes "enthusiastic user" from "definitely a bot"
- Built behavioral analysis to detect and block crawler patterns
- Added some... let's call them "creative responses" for confirmed bad actors
What We Learned
"Open platform" doesn't mean "all-you-can-eat buffet." Even publicly visible content deserves reasonable access boundaries. We want users to discover characters — not to build a competing database overnight.
Wave 2: The Bandwidth Assassins
What Happened
We barely finished patching the crawler holes when wave two hit. And this one went straight for the wallet.
Someone figured out our media URLs and started bulk-downloading every image and video on the platform. Character portraits. Generated videos. Everything with a file extension was getting pulled down at maximum speed.
We were using a major cloud provider's OSS service. Pay-per-bandwidth pricing. Seemed reasonable at the time.
Monday morning. Finance opens the cloud console. The billing dashboard loads.
Their face: 😐
Dashboard finishes loading: 😮
Sees the actual number: 😱
"Hey, so... our bandwidth bill is currently higher than three months of runway."
The Slack channel went very quiet. Someone nervously suggested we just turn off the CDN. Someone else pointed out that would also turn off the entire platform.
How We Responded
Emergency migration. Destination: Cloudflare R2 and Cloudflare Stream.
Here, we must formally thank Cloudflare — R2's zero egress fee policy saved us. When you're watching your bill climb by hundreds of dollars per hour, "no egress fees" becomes very, very relevant.
The migration took 30 hours. Sleep became optional. 3 AM code reviews have a certain meditative quality to them.
Worth it? Absolutely. Our bandwidth costs dropped by over 90%, and the attackers' bulk downloads now cost us essentially nothing.
What We Learned
When choosing infrastructure, don't just ask "how fast is it?" Also ask: "If someone attacks me tomorrow, will I still be able to afford rent?"
This dimension of infrastructure planning doesn't appear in most tutorials. It should.
Wave 3: DDoS Arrives
What Happened
We finally stabilized the bandwidth situation. Team morale was recovering. Someone even made a joke at standup. Things were looking up.
Then the DDoS hit.
Imagine turning on a fire hose and pointing it at a paper cup. That's what our database connection pool experienced. Thousands of requests per second, all demanding fresh data, all refusing to use cache, all hitting endpoints that required database queries.
Our monitoring dashboard looked like a heart attack EKG. Response times went from 200ms to 20 seconds. Then to timeouts. Users started reporting errors. Our AWS bill started doing that thing where it updates every few minutes with a bigger number.
The database connection pool hit its limit. Queries started queueing. The queue started backing up. Classic cascade failure, happening in real-time.
How We Responded
We threw every caching technique we knew at the problem:
- ISR (Incremental Static Regeneration) — Popular pages now get pre-rendered and served from edge nodes. The database doesn't even know these requests exist.
- Multi-layer caching — Response cache, query cache, connection pooling optimization. If data doesn't absolutely need to be fresh, it gets cached.
- Database query optimization — Some queries that used to take 500ms now take 50ms. Less time holding connections = more connections available.
- Cloudflare's DDoS protection — Finally enabled all the security features we'd been meaning to configure "eventually"
- Smart rate limiting — Legitimate users get through; attack traffic gets shown the door
The philosophy: if a request can be answered without touching the database, it should be.
What We Learned
Caching isn't just a performance optimization — it's a security architecture. When attacks come, cached responses absorb the blow. The database stays protected. The site stays up.
Also learned: "we'll configure security properly later" is a philosophy that ages poorly.
Wave 4: The Wool-Pullers (API Abusers)
What Happened
This one didn't threaten our infrastructure directly. It threatened our budget.
We had built all these wonderful free AI features:
- AI Character Creation — Describe your character, AI generates the full profile
- AI Moment Generation — Create dynamic story moments with AI assistance
- AI Plugin Creation — Build character plugins with natural language
Our vision was beautiful: lower the barriers to creativity. Let everyone experience the magic of AI-assisted creation. Make the platform more accessible.
Someone's vision was different: "Free API? Let me just write a script that calls this 10,000 times."
We watched our AI token consumption dashboard climb. And climb. And climb. The graph looked like a hockey stick, except the hockey stick was made of money leaving our bank account.
Each AI generation costs us real money — API calls to language models aren't free. Watching thousands of automated requests burn through our AI budget felt like watching a taxi meter in a car that's driving in circles. You know it's going to be expensive, and it's never going to stop.
The worst part? These weren't even real users creating real content. It was just... someone testing how much free stuff they could extract. The generated characters were gibberish. The moments made no sense. Pure waste.
How We Responded
With a heavy heart, we added credit requirements to these AI features.
This decision genuinely hurt. We spent weeks building these tools specifically to make creation more accessible. Now we had to put a price on them — not because we wanted to, but because unlimited free access was being weaponized against us.
We tried to be fair about it:
- Credit costs are minimal for normal usage
- Free credits are given to new users
- The core chat experience remains free
- Only resource-intensive AI generation requires credits
But still. It felt like putting a lock on something we wanted to keep open.
What We Learned
"Free" is a business model, not a moral position.
We still believe in accessibility. We still want to lower barriers. But "unlimited free for everyone" only works if everyone acts in good faith. When bad actors exploit generosity, the generous system becomes unsustainable — and then nobody gets anything.
Reasonable limits aren't distrust of users. They're protection of the ecosystem that serves all users. The alternative — shutting down features entirely — would be worse for everyone.
Sometimes protecting the commons means building some fences.
Your Data Is Safe (Let Us Be Absolutely Clear)
We want to be unambiguous about this:
These attacks were about resources, not data. The attackers wanted:
- ✅ Our bandwidth (to download content)
- ✅ Our compute (to overwhelm our servers)
- ✅ Our money (to drain our AI budget)
They did NOT access:
- ❌ User accounts
- ❌ Conversation histories
- ❌ Personal information
- ❌ Payment details
- ❌ Any private data whatsoever
We have a dedicated security team that monitors for actual security threats 24/7. User data is encrypted at rest and in transit. Access controls are strict. Authentication is robust. The boring, important security work that doesn't make for exciting blog posts — we do all of it.
Zero user data was compromised. We can state this confidently because we logged everything, analyzed everything, and verified everything. The attackers got bandwidth bills and headaches from us. They got nothing from you.
Your characters, your conversations, your creative work — all safe, all intact, all exactly where they should be.
Why We're Telling You This
You might wonder: why share this publicly? Doesn't it make us look vulnerable?
We thought about this carefully.
Transparency Builds Trust
We're asking users to trust us with something meaningful — their creative work, their emotional connections to AI characters, their conversations. That trust requires honesty about challenges we face.
The old playbook is to hide problems until they explode, then issue a vague "we experienced technical difficulties" statement. We'd rather be upfront: here's what happened, here's how we handled it, here's what we learned.
Other Builders Can Learn
We're not the first small team to get attacked after launching free features, and we won't be the last. If our expensive education helps someone else prepare better, that's a win for the whole ecosystem.
Consider this our contribution to the "things they don't teach you in startup school" curriculum.
You Deserved to Know
Some users noticed slower response times during these weeks. Some noticed features now require credits. You deserved an explanation — not corporate PR speak, but the actual story.
We were fighting to keep the platform running. We made hard decisions under pressure. Some of those decisions affected your experience. You should know why.
What's Next
We're not just patching holes — we're building a more resilient platform:
Already Implemented:
- Multi-layer caching with edge-first architecture (your requests are faster AND we're harder to attack)
- Smart rate limiting with behavioral analysis (bots get blocked, humans don't notice)
- Cloudflare's full security suite (finally configured properly, not "eventually")
- Credit-based access for resource-intensive AI features (sustainable generosity)
Coming Soon:
- Enhanced anomaly detection (catch attacks earlier)
- Geographic optimization (faster for everyone, everywhere)
- More sophisticated abuse prevention (stay ahead of the bad actors)
What Won't Change:
- We'll try our best to maintain free tier access — though it may be unstable or change without notice
- User data privacy and security — always our top priority
- Transparent communication — if something goes wrong, you'll know
A Note to Fellow Builders
If you're building an open platform, here are lessons we paid real money (and real stress) to learn:
- Rate limiting isn't optional — implement it from day one, not day "we're being attacked"
- Choose attack-resistant infrastructure — Cloudflare is genuinely excellent; egress fees will destroy you
- Cache aggressively — it's your dual shield for performance and security
- Free features need boundaries — unlimited goodwill gets exploited by unlimited bad actors
- Monitor everything — the earlier you detect anomalies, the smaller the damage
- Keep emergency budget — you never know when the next wave hits
And maybe most importantly:
- Don't be too proud to ask for help — the indie dev community is more supportive than you'd expect
We hope you don't have to learn these the expensive way. But if you do, know that you're not alone.
To Our Users
Being attacked is a strange experience.
It's like you spent months decorating a cozy living room, arranged the furniture just right, put out snacks, and sent invitations to all your friends. Opening night arrives. Your friends show up — wonderful!
But also: a group of people you've never met shows up with moving trucks, attempting to dismantle your couch, photograph every corner of your house, and somehow also set small fires in the kitchen.
We had options. We could have welded the door shut. Gone invite-only. Made everyone prove they're not a bot before seeing anything.
We didn't.
Instead, we installed better locks. Hired smarter security. Built reasonable house rules. Because the vast majority of people who come to Reverie are here to create, connect, and enjoy themselves. We're not going to punish the many for the sins of the few.
The party continues. The door stays open. We just got better at spotting the people carrying moving trucks.
Thank You
To every user who stuck with us through slower load times and credit requirements: thank you.
To everyone who reported issues instead of just leaving: thank you.
To the indie dev community that shared advice and war stories: thank you.
To Cloudflare: thank you. 🙏
We're stronger now. More resilient. Battle-tested. The platform that emerged from these attacks is better than the one that went in.
Next time we write to you, we hope it's to announce an exciting new feature.
Not another boss we defeated.
But hey — if another boss shows up, we'll handle that too.
See you in the next update. 💙
The Reverie Team
December 2025
Ready to Experience Dynamic AI Conversations?
Join thousands of users already exploring infinite personality and engaging interactions on Reverie.