Limitations

Understanding Logstyx's limitations helps you make informed decisions about whether it's the right logging solution for your use case. While Logstyx provides comprehensive features for self-hosted logging with privacy and security in mind, there are some architectural trade-offs and constraints to be aware of.

Search Behavior

Index-Based Search Model

How it works: Logstyx uses a searchable select component (Mantine) that presents all decrypted index values as selectable options.

Trade-offs:

• Search is based on pre-defined indexed fields, not arbitrary text across all log content
• You select from available indexed values rather than typing free-form search queries
• No full-text search across entire log messages or unindexed fields

Impact:

• Excellent performance for searching indexed fields
• Privacy-preserving (hashed indexing) while still being user-friendly
• Requires thoughtful index design during implementation

Best Practice: Structure your logs with well-defined, indexed fields using the logstyx SDK to ensure the data you need to search is properly indexed.

// Good: Fields will be indexed and searchable via select
logger.error("Payment failed", {
  errorCode: "PAYMENT_DECLINED",
  userId: "user_123",
  service: "payment-gateway"
});

// Limited: Only indexed fields are searchable
logger.error("Some random error message without structured fields");

Scalability Considerations

Message Queue Dependency

Limitation: The system relies on RabbitMQ for inter-service communication.

Impact:

• Very high-throughput scenarios (>100K logs/second) may require RabbitMQ tuning
• Queue failures can temporarily impact log ingestion
• Memory consumption increases with queue depth during traffic spikes

Mitigation:

• Monitor RabbitMQ metrics and scale horizontally when needed
• Configure message TTL and dead-letter queues appropriately
• Consider using external RabbitMQ clusters for production deployments
• Logstyx's self-monitoring project will alert you to ingestion issues

MongoDB Storage Growth

Limitation: All logs are stored in MongoDB, which requires capacity planning as your data grows.

Impact:

• Storage costs increase linearly with log volume
• Very large datasets (multi-TB) may benefit from sharding
• Query performance can degrade without proper index maintenance and retention policies

Mitigation:

• Implement retention policies to archive or delete old logs
• Use MongoDB sharding for horizontal scaling if needed
• Monitor storage usage through Logstyx's self-monitoring
• Plan storage capacity based on your log volume projections

Manual Horizontal Scaling

Limitation: While the microservices architecture supports horizontal scaling, it requires manual configuration.

Impact:

• Scaling requires manual intervention or custom automation
• No built-in auto-scaling capabilities
• Load balancing between service replicas must be configured externally

Mitigation: Deploy Logstyx in Kubernetes or similar orchestration platforms that provide auto-scaling and load balancing capabilities.

Security & Privacy

Manual Key Rotation Process

Limitation: Encryption key rotation is a manual process, though simplified through the install.sh script.

Why: Balancing security best practices with deployment simplicity.

Impact:

• Key rotation requires running the installation script and updating environment variables
• Service restart needed after rotation
• Lost encryption keys mean permanent data loss

Mitigation:

• The install.sh script automates most of the key rotation complexity
• Store backup keys in external secret management solutions (HashiCorp Vault, AWS Secrets Manager)
• Document and test your key rotation procedures regularly
• Always backup encryption keys securely in multiple locations

Authentication Methods

Current State: Supports email/password authentication with JWT tokens, plus webhook integration for external auth systems.

Limitation: No built-in OAuth2, SAML, or multi-factor authentication (MFA).

Impact:

• Enterprise identity provider integration requires custom webhook implementation
• MFA must be handled by external authentication layer
• Direct SSO integration not available out of the box

Mitigation: Use webhooks to integrate with your existing authentication infrastructure, or implement a reverse proxy that handles advanced authentication before forwarding to Logstyx.

Operational Considerations

Backup Strategy

Limitation: Logstyx doesn't include automated backup functionality for MongoDB or configuration files.

Why: Backup strategies vary greatly between deployments and are better handled at the infrastructure level.

Impact:

• Data loss risk without external backup solution
• Recovery procedures must be implemented separately
• No point-in-time recovery out of the box

Mitigation:

• Use MongoDB's built-in backup tools (mongodump, MongoDB Atlas backups, or replica set snapshots)
• Backup your .env file and encryption keys separately
• Implement regular backup automation using infrastructure tools
• Test recovery procedures regularly
• Logstyx's self-monitoring will alert you if logging fails, but won't protect against data loss

Development vs. Production Parity

Limitation: Development and production Docker Compose configurations have different optimizations.

Why: Development mode prioritizes hot-reload and debugging; production prioritizes performance and stability.

Impact:

• Performance characteristics differ between environments
• Some behaviors may vary between dev and prod
• Configuration drift possible if not carefully managed

Mitigation:

• Use consistent environment variables across environments
• Test in production-like staging environments before deploying
• Document environment-specific configurations clearly
• The install script helps maintain configuration consistency

Performance Considerations

Redis Cache Dependency

Limitation: Heavy reliance on Redis for caching creates a dependency.

Impact:

• Redis failures degrade performance significantly
• Cache invalidation must be managed carefully
• Memory constraints limit cache size

Mitigation:

• Use Redis in high-availability mode with replication
• Monitor cache hit rates and adjust sizing accordingly
• Implement graceful degradation when cache is unavailable
• Monitor through Logstyx's self-monitoring project

Processing Pipeline Latency

Limitation: Logs pass through RabbitMQ and multiple microservices before being queryable.

Impact:

• Logs typically take 1-2 seconds to appear in search results
• Not suitable for sub-second real-time requirements
• Burst traffic can temporarily increase latency

Reality Check: This latency is generally acceptable for most logging use cases. Logstyx's self-monitoring lets you track ingestion performance in real-time.

Data Format Constraints

JSON-Structured Logs

Limitation: The logstyx SDK expects structured JSON logs.

Why: Structured logging enables better querying, encryption, and indexing.

Impact:

• Cannot ingest plain text logs directly without transformation
• Legacy systems may require log format conversion
• Binary log formats not supported

Mitigation: Use log shippers or transformers to convert unstructured logs to JSON before sending to Logstyx. The structured approach ultimately provides better searchability and analysis capabilities.

Integration Limitations

External Tool Integration

Limitation: While Logstyx provides webhooks and alerts, deep integration with APM tools requires custom development.

Impact:

• No native plugins for tools like Grafana, Datadog, or New Relic
• Custom dashboards require using the API
• Distributed tracing requires correlation in your application code

Mitigation:

• Use the custom report widgets in the frontend for visualization
• Build custom integrations using the webhook system
• Export data via API for analysis in external tools

When to Choose an Alternative

Consider alternative logging solutions if you need:

• Full-text search across all log content (not just indexed fields)
• Sub-second real-time log availability and streaming
• Built-in APM features like distributed tracing, profiling, or automatic service maps
• Managed service with zero maintenance overhead and vendor support
• Massive scale (> 1TB/day) without significant infrastructure investment
• Out-of-the-box integrations with enterprise tools and services
• Compliance certifications for specific industries (HIPAA, SOC2, etc.)

What Logstyx Does Well

Despite these limitations, Logstyx excels at:

• ✅ Complete data ownership - Your logs never leave your infrastructure
• ✅ Privacy-first design - Encryption at rest with hashed indexing
• ✅ Self-monitoring - Automatically monitors itself during installation
• ✅ Alerts and webhooks - Built-in notification system
• ✅ Custom reporting - Frontend widgets for custom report generation
• ✅ Cost-effective - No per-GB pricing or vendor lock-in
• ✅ Searchable interface - User-friendly search via indexed field selection
• ✅ Simple deployment - One-command installation and setup
• ✅ Microservices-ready - Designed for modern cloud-native architectures

Future Improvements

The Logstyx project is actively developed. Check the GitHub repository for the latest updates and planned features.

---

Understanding these limitations helps you make informed decisions and plan your deployment appropriately. If you encounter issues or have questions, please open an issue on GitHub or join the discussions.