lager
Lager is a production-grade logging framework for Erlang/OTP applications that integrates cleanly with Unix tooling like syslog and logrotate. It offers fine-grained log levels, multiple backends (console, file, custom), multiple sinks, and built-in protections against log-induced memory exhaustion.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | erlang-lager/lager |
| Owner | erlang-lager |
| Primary language | Erlang |
| License | Apache-2.0 — OSI-approved |
| Stars | 1.1k |
| Forks | 446 |
| Open issues | 52 |
| Latest release | 3.9.1 (2021-03-02) |
| Last updated | 2025-08-26 |
| Source | https://github.com/erlang-lager/lager |
What lager is
Lager uses compile-time parse transforms to inject module/function/line/PID metadata with zero runtime overhead when a log level is disabled. It supports multiple named sinks as gen_event managers, configurable backends, custom formatters, async thresholds, and internal/external log rotation with load-shedding capabilities.
Get the lager source
Clone the repository and explore it locally.
git clone https://github.com/erlang-lager/lager.gitcd lager# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Compile-time parse transform is mandatory for call-site metadata; add `{parse_transform, lager_transform}` to module or compiler flags during build.
- Explicit `lager:start()` call required before any logging; can be automated via OTP app startup or `-s lager` flag in erl invocation.
- Configuration is application-level (app.config or app.src); changes to handlers or sinks typically require node restart—plan accordingly.
- Multiple backends and sinks add configuration complexity; start with console + file backend; extend only if audit/multi-sink separation is needed.
- Load shedding is optional but recommended for high-volume logging; requires tuning `async_threshold` and `async_threshold_window` per sink based on expected message rates.
When to avoid it — and what to weigh
- Non-Erlang/OTP environment — Lager is Erlang-only and relies on BEAM VM primitives (parse transforms, gen_event). Not usable in Python, Go, Node.js, or other runtimes.
- Requirement for recent OTP versions with guaranteed support — Support is limited to the three most recent OTP major versions. As of Aug 2019, only OTP 20, 21, 22 were officially tested; older versions may not work reliably.
- Need for structured/JSON logging without custom development — Lager's default formatting is text-based. Structured logging (JSON, structured fields) requires custom formatters; not built-in.
- Active maintenance and rapid feature development expected — Latest release (3.9.1) is from March 2021, over 3 years old. While repository shows recent activity (Aug 2025), no new feature releases. May indicate maintenance-only mode.
License & commercial use
Lager is licensed under Apache License 2.0 (SPDX: Apache-2.0), which is an OSI-approved permissive license.
Apache 2.0 permits commercial use, modification, and distribution under the stated terms (attribution, license copy, notice of changes). No patent indemnity clause. For proprietary derivative works or high-risk liability scenarios, consult legal counsel on indemnification adequacy.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Moderate |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | Low |
| DEV.co fit | Strong |
| Assessment confidence | High |
Log contents are not encrypted by default; sensitive data (passwords, tokens, PII) can be logged in plaintext. No built-in data masking or encryption of log files. Operators must enforce file permissions, encrypted storage, and secure log transmission. Parse transform operates at compile time and does not perform security validation of log messages.
Alternatives to consider
Kernel logger (OTP 21+)
Native OTP logging; no dependencies or parse transforms. Lower performance and less feature-rich than Lager, but sufficient for simple applications and integrated with OTP tools.
error_logger (legacy OTP)
Pre-OTP 21 standard; basic but now deprecated in favor of kernel logger. Lager integrates with it but does not replace it.
Elixir Logger (if using Elixir)
Higher-level abstraction, structured logging, better Elixir integration. Runs on BEAM but language-specific; not suitable for pure Erlang codebases.
Build on lager with DEV.co software developers
Our team specializes in Erlang/OTP application development and DevOps integration. Let's evaluate Lager's fit for your logging infrastructure and ensure production readiness.
Talk to DEV.coRelated on DEV.co
Explore the category and the services that help you build with it.
lager FAQ
Does Lager work with OTP 24 or later?
Can I use Lager with Elixir?
How do I send logs to a remote syslog server?
What is the performance impact of Lager on my Erlang application?
Custom software development services
Need help beyond evaluating lager? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source observability integrations — and maintain them long-term.
Ready to deploy Lager in your Erlang stack?
Our team specializes in Erlang/OTP application development and DevOps integration. Let's evaluate Lager's fit for your logging infrastructure and ensure production readiness.