We just shipped Logtide 0.5.0, and it's packed with features that make log analysis more intuitive while keeping deployments dead simple. This release is all about giving you flexibility—whether you want the full power of Redis or prefer to keep things minimal with just PostgreSQL.
The Highlights
🖥️ Terminal View: Because Sometimes Table Isn't Enough
Not everyone loves tabular data. If you've ever found yourself squinting at logs in a web UI, wishing you could just see them like you would in tail -f, we heard you.
Toggle between Table and Terminal views right from the search page. Terminal mode gives you that classic monospace feel with ANSI-style color coding by log level:
[2025-01-31T14:23:45.123Z] [ERROR] [api-gateway] Database connection timeout
[2025-01-31T14:23:46.456Z] [WARN] [auth-service] Rate limit approaching threshold
[2025-01-31T14:23:47.789Z] [INFO] [web-server] Request completed in 45ms
Works seamlessly with Live Tail, and your preference persists across sessions. Sometimes the old ways are still the best ways.
📦 Detection Packs: Security Made Easy
Setting up security alerts shouldn't require a PhD in Sigma rules. Detection Packs let you enable curated bundles of security rules with one click.
Browse the gallery, find a pack that matches your needs (web attacks, brute force attempts, suspicious behavior patterns), and enable it. Each pack contains battle-tested Sigma rules configured with logsource.product: any for broad compatibility.
Don't like something? Every rule is fully customizable—packs are just a starting point that gets you 80% of the way there in seconds instead of hours.
đź”— Event Correlation: Connect the Dots
Modern applications are distributed. A single user action triggers events across multiple services, each generating its own logs. Finding the full story meant manually searching for request_id or trace_id across different queries.
Not anymore.
Logtide now automatically extracts identifiers from your log metadata—request_id, trace_id, user_id, or any custom correlation field you're using. Click any identifier in a log, and instantly see every related event across all your services.
It's distributed tracing without the distributed tracing infrastructure.
đź”® Alert Preview: "Would Have Fired"
You know that feeling when you enable an alert rule and immediately get flooded with notifications? Or worse, enable a rule that never fires because the threshold was wrong?
Alert Preview lets you test your alert conditions against historical data before going live. See exactly which logs would have triggered the alert, validate your thresholds, and tune your rules until they're perfect.
No surprises. No alert fatigue. Just alerts that matter.
🚀 Redis is Now Optional
Here's the big one: Redis is now completely optional.
We love Redis. It's fast, battle-tested, and perfect for caching and pub/sub. But not every deployment needs it, and requiring it added complexity for smaller installations.
Starting with 0.5.0, if you don't provide a REDIS_URL, Logtide automatically falls back to PostgreSQL-based alternatives:
- Jobs: graphile-worker instead of BullMQ
- Live Tail: PostgreSQL LISTEN/NOTIFY instead of Redis pub/sub
- Rate limiting: In-memory instead of Redis-backed
- Caching: Disabled (queries hit the database directly)
We've included a new docker-compose.simple.yml that deploys just PostgreSQL and Logtide—no Redis, no complexity. Perfect for development, testing, or smaller production workloads.
Your existing Redis-based deployment? Completely unaffected. This is about choice, not migration.
The Philosophy
This release embodies something we believe deeply: observability tools should get out of your way.
Making Redis optional isn't about Redis being "bad"—it's about recognizing that a two-service deployment is simpler than a three-service deployment. For many use cases, PostgreSQL is more than capable of handling job queues and real-time streaming.
Terminal view exists because sometimes you just want logs to look like logs, not spreadsheet cells.
Detection Packs exist because security shouldn't require you to become a Sigma expert before you can protect your systems.
Alert Preview exists because testing in production is unavoidable, but testing alerts in production is just masochism.
Under the Hood
Beyond the headline features, we've tightened up security and fixed some annoying bugs:
Security hardening:
- Enhanced regex validation with injection prevention
- Expanded rate limiting to additional routes
- Fixed SQL injection vulnerability in notification publisher (proper parameterized queries)
Bug fixes:
- Log context modal no longer reopens after closing when opened via URL params
- Fixed WebSocket memory leak in live tail handler
- Exception details now properly extract error data from metadata fields
UX improvements:
- Exception stack traces now include context fields (env, service, version, hostname)
- Copy button for stack traces
- Better formatting for error metadata
Upgrading
No database migrations. No breaking changes. Just pull the new images:
# Standard upgrade (with Redis)
docker compose pull
docker compose up -d
# Switch to Redis-free deployment
docker compose -f docker-compose.simple.yml pull
docker compose -f docker-compose.simple.yml up -d
What's Next?
We're doubling down on correlation and detection. Upcoming features include:
- Rate-of-change alerts: Statistical baselines that alert on anomalies, not just thresholds
- Advanced correlation: Multi-hop event graphs showing request flows across your entire stack
- Enhanced PII masking: GDPR-compliant automatic redaction of sensitive data
But more importantly, we're listening. Every feature in 0.5.0 came directly from community feedback. Keep the issues and discussions coming—we're building this for you.
Try Logtide:
- Cloud: logtide.dev
- Self-hosted: GitHub
- Docs: logtide.dev/docs
Full Changelog: v0.4.2...v0.5.0
Top comments (1)
This is a really solid release — I love how you focused on reducing operational friction while still adding genuinely powerful features, especially the Terminal View and correlation without extra infra. Making Redis optional feels like a very pragmatic call, and the PostgreSQL fallbacks are exactly what many small-to-mid setups actually want in practice. I’m excited to try this out and see how far Logtide can go as a lightweight-but-serious observability tool 🚀