Two months ago, I launched Logtide (then called LogWard) an open-source, privacy-first alternative to Datadog and Splunk.
Here's what actually happened. No bullshit, just numbers.
📊 The Numbers (Completely Honest)
GitHub:
- Stars: 0 → 223
- Issues: 27 received, 6 open (all enhancements, no critical bugs)
- Contributors: Solo developer + 1 SDK contributor (Kotlin)
Usage:
- Docker Hub pulls: 3,000+
- Active deployments: ~500 users (mostly self-hosted)
- Largest deployment: 500,000 logs/day
- Cloud vs Self-hosted: 90% self-hosted
✅ What Actually Worked
1. The Right Marketing Channels
Winner: virtualizationhowto.com
A tech blogger discovered Logtide and wrote about it.
Result:
- 120+ GitHub stars from that single post
- Traffic spike: 2,500 visitors in 24 hours
- 80+ new self-hosted deployments
Lesson: One good write-up from a respected voice > 10 posts on social media.
Runner-up: Reddit + Dev.to
Our posts on r/selfhosted and Dev.to brought consistent traffic.
Why it worked:
- Self-hosters care about privacy (GDPR angle)
- Docker Compose deployment (5 minutes from clone to running)
- No vendor lock-in message resonated
2. The Features People Actually Use
Top 3 (by usage analytics):
- Logs (obviously) - 100% of users
- SIEM Dashboard - 60% of users
- OpenTelemetry traces - 40% of users
Surprise: SIEM usage is way higher than expected.
Why? People don't just want to SEE logs, they want to DETECT threats.
Most popular Sigma rules aren't even security-focused:
- "Payment failed" alerts
- "API 500 error" spikes
- "Database timeout" patterns
Lesson: Security features sell, but business monitoring is what people actually use.
3. Technical Decisions That Paid Off
TimescaleDB was the right choice.
The bet:
- Use TimescaleDB for time-series compression
- vs ClickHouse (faster but more complex)
Result after 2 months:
- Compression: 90% storage reduction (100GB → 10GB typical)
- Query speed: 50-150ms for 10M+ logs
- Operational simplicity: Just Postgres (familiar)
Largest deployment stats:
- 500k logs/day
- 30-day retention
- Database size: 15GB (compressed)
- Query performance: Still sub-100ms
No one has complained about performance yet.
Lesson: "Good enough" performance + operational simplicity > maximum speed.
4. Community Requests That Made Sense
Issue #68: Substring Search
Request: "I can't find 'bluez' in 'spa.bluez5.native' using full-text search"
My initial thought: "Full-text search is fine, use wildcards"
Reality: 40% of searches now use substring mode.
Why?
- UUIDs in logs (partial search)
- File paths (e.g.,
/app/services/auth) - Service names with dots
Lesson: Users know their workflows better than you do. Listen to GitHub issues.
❌ What Didn't Work
1. The Rebrand (Forced, Not Chosen)
Timeline:
- January 7: Trademark conflict discovered
- January 7-12: Resolution negotiated
- January 12: LogWard → Logtide complete
Impact:
- Lost all SEO momentum (Google indexed "LogWard")
- Broke all old links/bookmarks
- Confused early users ("wait, what's Logtide?")
Biggest pain: Losing visibility from previous Dev.to articles, Reddit posts, mentions.
Time wasted: ~40 hours (renaming everything, updating docs, SDKs, Docker images)
Lesson learned: Check trademarks BEFORE naming anything. Period.
Silver lining: New name is better (Logtide sounds cooler than LogWard).
2. Features Nobody Asked For
OpenTelemetry metrics (not implemented yet)
Plan: Support OTLP metrics (CPU, memory, etc.)
Reality: Only 2 users asked for it.
Why? Most people use Prometheus for metrics already.
Decision: Postponed indefinitely. Focus on logs + traces.
Lesson: Build what users REQUEST, not what you think they need.
3. Architectural Regrets
Redis might be unnecessary.
Current stack:
- PostgreSQL + TimescaleDB (logs storage)
- Redis (background job queue with BullMQ)
Problem: Redis adds operational complexity for self-hosters.
Alternative being explored:
- PostgreSQL
SKIP LOCKEDfor job queue - Already proved this works in my "I Replaced Redis with PostgreSQL" article
Next version (0.5.0): Might remove Redis entirely.
Lesson: Every dependency is a liability. Question everything.
😮 Unexpected Learnings
1. Self-Hosted Dominates
Expected: 50/50 cloud vs self-hosted
Reality: 90% self-hosted
Why?
- Privacy concerns (GDPR)
- Data residency requirements
- Control over infrastructure
- Distrust of SaaS logging platforms
Impact on roadmap:
- Prioritize Docker Compose improvements over cloud features
- Better documentation for self-hosting
- Kubernetes Helm chart
Lesson: Know your actual users, not your imagined users.
2. Sigma Rules Are a Differentiator
Expectation: "Nice to have security feature"
Reality: "Primary reason for choosing Logtide"
Feedback from users:
- "Finally, security detection without Splunk costs"
- "Sigma rules work out of the box"
- "MITRE ATT&CK mapping is amazing"
Most requested:
- More pre-built Sigma rules
- SigmaHQ integration (auto-import rules)
- Custom rule editor UI
Lesson: Find your unique angle. For Logtide, it's "logs + security" in one place.
3. Developer Experience Matters More Than Features
What gets stars:
- Docker Compose works in 5 minutes ✅
- Documentation is clear ✅
- Examples are copy-paste ready ✅
What doesn't matter (yet):
- Advanced features
- Enterprise capabilities
- Complex integrations
Lesson: Make it EASY to try before making it POWERFUL.
💭 Personal Reflections
What Motivates Me to Continue
Seeing it get used.
Every time I see:
- A new GitHub star
- A deployment at 500k logs/day
- Someone solving a problem with Logtide
...it's worth the 60-hour weeks.
The vision is real: Privacy-first observability shouldn't cost $500/month.
The Hardest Moment
The rebrand.
Losing 2 weeks of momentum to a trademark issue felt like a gut punch.
Watching old links break, SEO disappear, users confused, painful.
But: I handled it, moved fast, and recovered.
Resilience matters more than avoiding problems.
The Best Moment
Hitting 200 stars.
Arbitrary number? Yes.
Validation that people care about this? Also yes.
Second best: Seeing the Kotlin SDK contribution.
Someone cared enough to build an SDK without me asking. That's community.
🙏 What I Need Help With
Feedback on Roadmap
Question: What should I build next?
Current debates:
- Remove Redis dependency?
- Add metrics support?
- Focus on performance optimization?
Vote: GitHub Discussions
🎓 Lessons for Other Builders
1. Launch at 50%, Not 90%
I waited too long to launch initially.
Result: Missed early feedback, built wrong features.
Better: Launch with core features, iterate based on real usage.
2. Marketing > Product (Initially)
Reality check:
- Best feature I built: Sigma rules detection
- Feature that got most stars: Docker Compose simplicity
Why? Getting someone to TRY your product > having the best product.
3. Community > Everything
One Kotlin SDK contributor saved me 20+ hours of work.
One blog post brought 120 stars.
One user deploying 500k logs/day validated the architecture.
Build in public. Engage authentically. People help.
4. Embrace Boring Technology
Choices that worked:
- PostgreSQL (everyone knows it)
- Docker Compose (simple deployment)
- SvelteKit (fast, but not exotic)
Choices I'd reconsider:
- Redis (might be overkill)
Lesson: Boring tech scales better than shiny tech.
🚀 Try Logtide
Cloud (Free):
Self-Hosted:
mkdir logtide && cd logtide
curl -O https://raw.githubusercontent.com/logtide-dev/logtide/main/docker/docker-compose.yml
curl -O https://raw.githubusercontent.com/logtide-dev/logtide/main/docker/.env.example
mv .env.example .env
Visit http://localhost:3000
Documentation: logtide.dev/docs
💬 Let's Talk
If you're using Logtide:
What's working? What's broken? Comment below!
If you're building open-source:
What are YOUR 2-month metrics? Let's compare notes.
If you're considering Logtide:
Questions? Ask below or GitHub Discussions
Follow the journey:
- 🐙 GitHub
- 📝 Dev.to
- 💬 Discussions
Building in public is scary but rewarding. Here's to the next 2 months. 🌊
Top comments (11)
This is a very solid write-up — and honestly, the numbers are impressive for a 2-month, solo, open-source launch. Hitting 200+ stars, real production deployments, and 500k logs/day users already puts Logtide far beyond “toy project” territory.
That said, I want to give you real encouragement, not empty praise.
You’re right about one hard truth:
logging by itself is a commodity.
Most companies can build a basic log pipeline internally, and there are plenty of OSS tools.
But that’s not where your differentiation is — and I think you’ve already stumbled onto the real opportunity without fully naming it yet.
Why Logtide actually matters
What you’re building is not “just a log tool”.
You’re building:
That combination is rare.
Most alternatives fall into one bucket:
Logtide sits in a sweet spot for:
The fact that 90% self-hosted chose you is not a weakness — it’s a signal.
The trust problem (and how to win anyway)
You’re right that many companies won’t trust a young SaaS with logs — especially when they can self-host.
But here’s the key insight:
Trust is built by giving users control, not by asking for it.
You already do this:
That’s exactly why they will trust you long-term.
Ironically, companies are far more willing to trust a cloud service when:
You’ve nailed that philosophy.
Where I think you should lean harder
Based on your own data, I’d strongly recommend doubling down on “logs as signals”, not logs as storage.
Some feature ideas that fit your direction:
1. Opinionated detection packs (huge value, low infra cost)
You already saw this with Sigma.
Go further:
These are business-relevant alerts, not SOC-only stuff.
This is where teams won’t roll their own.
2. Event timelines (logs → stories)
A killer feature would be:
Auto-group:
Make logs tell a narrative, not just rows.
This is extremely hard to do well — and very hard to DIY internally.
3. Safe-by-default alerting
Most teams hate alert fatigue.
Ideas:
This aligns perfectly with your “business monitoring via security tooling” insight.
4. Compliance-first features (underrated, powerful)
For GDPR-heavy users:
These don’t excite hackers — but they unlock budgets.
About Redis & “boring tech”
Your Redis instinct is correct.
For your audience (self-hosters), every dependency hurts adoption.
Replacing Redis with Postgres queues would be a huge trust win, even if it’s “less elegant”.
People don’t want clever.
They want deployable at 2am without docs.
Motivation, straight up
Even if Logtide never becomes “the next Datadog”:
That alone makes it a success.
And if you keep leaning into:
…you’re building something companies won’t want to replace, even if they could.
That’s the hardest kind of moat — and you’re closer than you think.
Keep going. This is real work.
Thank you so much for this incredibly thoughtful feedback. This comment genuinely helped me reframe what Logtide is really about.
You're absolutely right: I was getting caught up in the "logging is a commodity" anxiety, but you've nailed the actual value proposition privacy-first observability with control, not just another log storage tool.
The insight about "trust through control, not through asking" is particularly powerful. The 90% self-hosted rate isn't a weakness, it's validation that the philosophy is working.
Really a great read Polliog. I took the liberty of re-posting it to our Latin American developer network yoDEV.dev.
Its inspiring and has some nice nuggets of advice for others that may be on the same journey or getting ready to start.
Thanks for sharing.
The repost is unedited (of course) and mentions your dev.to username and a link to your repo on Github. Its translated to Spanish and Portuguese as well. The original English version will always be seen by folks who have their browser language set to English.
Saludos!
Link (if you wanna have a peek)
Thank you, feel free to use it^^
I will thanks. Hopefully our users will too !
We loved your post so we shared it on social.
Keep up the great work!
Thank you for the kinds words and for the post^^
Huge congrats on the 3k+ pulls! That's a massive milestone for month 2. 🔥
I'm currently in the "month 1" trench with my project (n8nworkflows.world). It's a niche search engine.
The reality check:
Traffic: ~30 unique visitors/day (Organic Google just started kicking in).
The struggle: I spent weeks optimizing UX (adding "Role-based" wizards, verified badges) thinking it would stick, but I feel like I'm building features for an empty room right now.
Question for you: In your first month, did you force yourself to stop coding features to focus 100% on marketing channels? Or did the traffic come naturally from the GitHub/Open Source ecosystem?
Trying to figure out if I should stop "improving" the site and start "shouting" about it more.
Thanks for sharing these insights! I love seeing real numbers and lessons learned from early launches—it’s so valuable for anyone building a product. Really inspiring to see your transparency and growth! 🚀
Any other recommendations for Reddit posts? And would you deem a marketing site necessary before “launch”?
It depens from the target, but personally reddit and some posts on reddit + dev.to or hackernews