Polliog

Posted on Jan 15

Logtide: 2 Months After Launch (The Real Numbers)

#webdev #programming #startup #opensource

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 LOCKED for 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):

👉 logtide.dev

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. 🌊

DEV Community