eraser
Eraser is a Kubernetes operator that automatically removes unused container images from cluster nodes to free up disk space and reduce attack surface. It integrates with vulnerability scanners like Trivy to help teams maintain clean, secure Kubernetes environments.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | eraser-dev/eraser |
| Owner | eraser-dev |
| Primary language | Go |
| License | Apache-2.0 — OSI-approved |
| Stars | 611 |
| Forks | 71 |
| Open issues | 78 |
| Latest release | v1.4.1 (2025-12-02) |
| Last updated | 2026-04-09 |
| Source | https://github.com/eraser-dev/eraser |
What eraser is
A Go-based CNCF-aligned Kubernetes operator that identifies and removes non-running images from nodes via a declarative API. It supports integration with vulnerability scanners for image filtering and provides cluster-wide image cleanup orchestration.
Get the eraser source
Clone the repository and explore it locally.
git clone https://github.com/eraser-dev/eraser.gitcd eraser# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Requires Kubernetes 1.18+ (typical); verify version compatibility against release notes before deployment.
- Image cleanup policy must align with application rolling update and replica recovery patterns to avoid accidental removal of in-use images.
- Monitor cleanup frequency and logging to prevent aggressive removal that destabilizes workloads; test in non-production clusters first.
- Integration with vulnerability scanners (Trivy, etc.) is optional but highly recommended for security-driven removal workflows.
- Plan for node-level resource constraints; cleanup operations may briefly increase I/O; schedule during maintenance windows if cluster is memory-constrained.
When to avoid it — and what to weigh
- Heavy image layer sharing requirements — If your workloads depend on preserving specific image layers for rapid deployment or are tightly coupled to node-local caching, aggressive cleanup may degrade startup performance.
- Minimal operational overhead is non-negotiable — Running an additional operator adds cluster complexity and requires monitoring; consider if manual cleanup or simpler node-level policies suffice for your scale.
- Immature or highly custom container runtime setup — Eraser assumes standard Kubernetes container runtime behavior; non-standard or heavily patched runtimes may experience unpredictable cleanup behavior.
- Audit or compliance requires image retention — If regulatory requirements mandate long-term image retention on nodes for forensics, Eraser's removal workflow conflicts with that obligation.
License & commercial use
Apache License 2.0 (Apache-2.0). Permissive OSI-approved license; permits commercial use, modification, and distribution with attribution and liability disclaimers. FOSSA badge and OpenSSF Best Practices compliance indicate active license hygiene.
Apache-2.0 is a standard permissive license suitable for commercial deployment. No license-level restrictions on commercial use. However, verify any internal policies requiring vendor support or indemnification; Eraser is community-maintained (no formal vendor SLA stated in README).
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | Moderate |
| DEV.co fit | Good |
| Assessment confidence | High |
Eraser removes images to reduce attack surface; no inherent vulnerabilities noted in provided data. Operator runs with node-level image access (security-critical); verify RBAC policies limit operator permissions to minimum. No security audit report, exploit database entries, or known CVEs mentioned in provided data; conduct security review of latest release before production use. OpenSSF Scorecard badge suggests basic security hardening practices.
Alternatives to consider
Manual kubelet image garbage collection + node cron jobs
Simpler for small clusters; requires no operator; use if cluster size < 10 nodes and cleanup frequency is low.
Kubernetes janitor/eviction policies (native)
Built-in node garbage collection (kubelet eviction); no external tooling; insufficient control for security-driven cleanup or cross-node policy.
Trivy + custom admission controllers
Prevents vulnerable images at admission; complements Eraser but does not remove already-cached images from nodes.
Build on eraser with DEV.co software developers
Explore Eraser's quick-start guide, join the community Slack channel, or file an issue to discuss your cluster's cleanup strategy.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
eraser FAQ
Does Eraser delete running container images?
Can Eraser integrate with our existing vulnerability scanner?
What happens if an image is removed and then needed again?
Does Eraser require cluster admin privileges?
Software development & web development with DEV.co
DEV.co helps companies turn open-source tools like eraser into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source security stack.
Ready to streamline Kubernetes image management?
Explore Eraser's quick-start guide, join the community Slack channel, or file an issue to discuss your cluster's cleanup strategy.