Silent Killer in Production: Memory Leak Diagnosis and Solution Journey
Article Summary
Taha Selim Aksakal from Teknasyon Engineering tracked down a memory leak that silently grew RAM usage from 160MB to critical levels over 12 hours—with zero traffic. The culprit? An unexpected interaction between two popular libraries.
This article documents a real-world debugging journey in a Next.js production environment where memory consumption steadily increased during idle periods. The team systematically investigated Docker configurations, build optimizations, and third-party dependencies to identify the root cause.
Key Takeaways
- Memory grew continuously over 12 hours despite zero traffic or load
- Docker image reduced from 2.7GB to 450MB using standalone build mode
- Zustand and framer-motion combination caused garbage collection failure
- Removing the problematic libraries stabilized memory at 160MB permanently
- Used siege tool to simulate traffic and reproduce issue locally
A seemingly innocent combination of Zustand state management and framer-motion animations created subscriber references that prevented garbage collection, causing a production memory leak that disappeared only after removing both libraries.
About This Article
Taha Selim Aksakal's Next.js app was leaking memory in production. Over 12 hours with no users and no load, RAM climbed from 160MB to critical levels.
The team dug into the Docker standalone build setup and found the culprit. Zustand's subscriber pattern was holding onto object references that framer-motion's animation loops wouldn't release. They removed both libraries to fix it.
Memory usage dropped back to 160MB and stayed there. The silent leak that had been degrading the production system was gone.
