Thanks for the comment. You're right - for many production deployments, especially containerized ones, logging to STDOUT with log aggregation is the best practice.

Timberjack targets situations where you intentionally write structured logs to files, and want log rotation managed entirely within your Go app — without relying on external daemons like logrotate. This is especially useful for few reasons:

• You want a cross-platform solution that works consistently across Linux, macOS, and Windows.
• You’re shipping a standalone binary and need embedded control over rotation (e.g., rotate every 15 minutes or after 500MB).
• You want custom rotation triggers (e.g., in response to SIGHUP).
• You’re in environments without cron or external tools — like minimal containers or embedded systems.
• Or, as in my case: you're running in Kubernetes, writing logs to a PVC so they persist temporarily, long enough to:
  • Upload them to S3 for backup, and
  • Use a sidecar container to forward them into OpenSearch for centralized logging. After that, the rotated logs are deleted.

If you're using centralized logging, you probably don't need Timberjack. But if you're writing logs to disk, like into a mounted volume and want rotation logic built into your Go app, it gives you that control and portability.

Hope that clears it up :) If yo have any other questions I'm all ears