Bun Memory Leaks Are Ruining My Life (And Probably Yours Too)

Bun uses JavaScriptCore instead of V8, and its garbage collector is weird as hell - like, genuinely unpredictable weird. I've been fighting these memory issues in production for what feels like forever, and the debugging tools are absolute garbage compared to Node.js memory debugging. Here's the stuff I wish someone had told me before I wasted months on this.

JavaScriptCore does this thing where... fuck, I don't even know how to explain it properly

It holds onto closures like a hoarder. V8 at least tries to optimize scopes, but JavaScriptCore? Nah, it keeps the entire parent scope alive. Found this out when our API server went from maybe 200MB to... shit, 8GB? Over a single weekend because we were creating handlers that referenced this massive config object. Took me like 2 weeks to figure out what the hell was happening.

The GC does whatever it wants. V8 at least has some predictable patterns, but JavaScriptCore just decides when it feels like cleaning up. Your memory can grow for hours - I've watched it climb to like 3GB before it bothered doing anything. Sometimes it never happens at all.

The debugging tools are garbage. This pisses me off more than anything. Chrome DevTools? Good luck with that. The object structure looks completely alien compared to V8 and nothing makes sense. I've wasted more time trying to decode heap snapshots than actually fixing leaks.

The memory leaks that will absolutely ruin your week (I'm still recovering from these)

1. File Processing That Never Releases Memory (this one almost made me quit programming)

If you're processing files, images, or any large data, Bun has this nasty habit of never releasing Blobs and ArrayBuffers. Issue #12941 documents this exact problem, and there are tons of related ArrayBuffer issues scattered across their issue tracker. The Blob API documentation conveniently doesn't mention any of these limitations. This shit will straight up eat your memory:

// This killed our image processing server
const processFiles = async (urls) => {
  let blobs = [];
  
  for (const url of urls) {
    const response = await fetch(url);
    const blob = await response.blob(); // Never gets freed
    blobs.push(blob);
  }
  
  // None of this works:
  blobs = null;
  Bun.gc(true); // Useless
  // Memory still climbing to 8GB
};

2. Next.js Builds That Eat All Your Memory (took down our entire deployment pipeline)

If you're using Bun with Next.js for static generation on anything bigger than like 50 pages, you're completely screwed. Issue #16339 documents this continuous memory growth during builds, and there are a bunch of similar Next.js problems from other poor bastards who tried this. The Next.js + Bun guide doesn't warn you about any of this bullshit. I literally sat there and watched our massive site go from maybe 400MB to... fuck, 6GB? Before it just crashed when it hit the container limit. Wasted my entire afternoon debugging this crap.

// This config won't help
module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0, // Doesn't work
}
// Build: 400MB -> 1GB -> 2GB -> 4GB -> CRASH

We had to split our build into chunks and restart the process every 1000 pages. Fun times.

Actually, speaking of fun times - trying to explain this to management was... well, "Hey, so our new super-fast runtime randomly eats 8GB of memory and crashes" didn't go over well.

3. Workers That Leave Memory Ghosts Behind

Bun's workers leak memory when they terminate. Multiple worker-related memory issues exist in the tracker. The Worker API documentation doesn't mention cleanup problems. Create 100 workers that do some processing and exit? You'll still see their memory usage hanging around like ghosts. The only fix is restarting your main process, which is pretty fucking useless in production.

How to Catch Memory Leaks Before They Kill You

Simple Memory Monitoring (Actually Works):

// This saved us when containers started dying
setInterval(() => {
  const memMB = Math.round(process.memoryUsage().rss / 1024 / 1024);
  if (memMB > 1500) {
    console.error(`MEMORY CRITICAL: ${memMB}MB - shutting down gracefully`);
    process.exit(1); // Better than OOMKill
  }
}, 30000);

Heap Snapshots: Good luck with that. They're way harder to read than Node.js ones and Chrome DevTools barely makes sense of them.

Pro tip: Chrome DevTools can load these, but the object structure is different from V8. Compare this to Node.js heap profiling and clinic.js flame graphs - it's night and day. I spent hours trying to make sense of the snapshots before giving up and just adding more monitoring. The Bun profiling guide helps, but it's still confusing compared to V8 debugging tools.

Now that you understand why Bun's memory behavior is so unpredictable, let's look at how to actually debug these issues when they hit production.

First: Figure Out If It's Actually Broken (Or Just Being Bun)

JavaScriptCore's garbage collection is lazy as hell. Like, stupidly lazy. Memory can grow for hours before any GC happens, which drove me crazy until I realized this is just how it works. Don't immediately panic and start rewriting everything like I did the first time - that was a nightmare week where I basically rewrote our entire caching layer for nothing.

Oh, and another thing that pisses me off - the docs act like everything's fine but clearly nobody at Bun has tried to run a real production app with this thing. The Bun memory monitoring guide covers some of the basics, along with Bun's debugging blog post and the web debugger docs, but honestly here's what actually works:

Check if memory ever goes down:

// Throw this in your app and watch the logs
const startingMemory = process.memoryUsage().rss;
let peakMemory = startingMemory;

setInterval(() => {
  const memMB = Math.round(process.memoryUsage().rss / 1024 / 1024);
  
  if (memMB > Math.round(peakMemory / 1024 / 1024)) {
    peakMemory = memMB * 1024 * 1024;
    console.log(`Memory hit ${memMB}MB`);
  }
}, 60000);

You'll see some weird shit happen:

• Normal (I think?): Goes up, then down, then up again - JavaScriptCore being lazy
• Actually fucked: Only goes up, never comes down - real leak, time to panic
• Who knows: Goes up to some ridiculous number and stays there - might be fine? Makes me nervous though

The Usual Suspects That Cause Memory Leaks

File/Data Processing (Kills You Every Time):

If you're processing files, images, or big chunks of data, you're probably leaking memory. The File I/O documentation doesn't warn about this, but community discussions are full of similar problems. Check out Stack Overflow posts, Render community reports, and production debugging guides. Here's what performance benchmarks don't tell you:

// This killed our image processing API
const processImages = async (urls) => {
  const results = [];
  
  for (const url of urls) {
    const response = await fetch(url);
    const buffer = await response.arrayBuffer(); // Memory never gets freed
    const processed = await resizeImage(buffer);
    results.push(processed);
  }
  
  return results; // 500 images = 8GB memory usage that never goes down
};

// What actually works (learned this the hard way)
const processImagesSafely = async (urls) => {
  const results = [];
  
  for (let i = 0; i < urls.length; i++) {
    const url = urls[i];
    const response = await fetch(url);
    const buffer = await response.arrayBuffer();
    const processed = await resizeImage(buffer);
    results.push(processed);
    
    // Give GC a chance every 10 images
    if (i % 10 === 0) {
      await new Promise(resolve => setTimeout(resolve, 10));
    }
  }
  
  return results; // Much better, but still not perfect
};

Closure Scope Leaks:

JavaScriptCore's scope retention is more aggressive than V8. I still don't fully understand why, but basically if you create closures that reference big objects, they stick around forever. Here's what I learned the hard way:

// Problematic - entire parent scope retained
function createHandlers(largeDataSet) {
  return largeDataSet.map(item => {
    return async (request) => {
      // This closure keeps entire largeDataSet alive
      return processRequest(request, item.id);
    };
  });
}

// Better - minimize scope retention
function createHandlers(largeDataSet) {
  return largeDataSet.map(item => {
    const itemId = item.id; // Extract only needed value
    return async (request) => {
      // Only itemId retained, not entire largeDataSet
      return processRequest(request, itemId);
    };
  });
}

Platform-specific weirdness you'll encounter

Next.js Static Generation Investigation:

For Next.js apps experiencing build-time memory growth:

// Add to next.config.js for debugging
const { writeHeapSnapshot } = require('v8');
let snapshotCount = 0;

module.exports = {
  webpack: (config, { isServer, dev }) => {
    if (isServer && !dev) {
      // Monitor memory during static generation
      const originalEntry = config.entry;
      config.entry = async () => {
        const entries = await originalEntry();
        
        // Memory monitoring wrapper
        const memoryCheck = setInterval(() => {
          const memMB = Math.round(process.memoryUsage().rss / 1024 / 1024);
          if (memMB > 1000) { // 1GB threshold
            clearInterval(memoryCheck);
            writeHeapSnapshot(`build-leak-${++snapshotCount}.heapsnapshot`);
            console.error(`Build memory critical: ${memMB}MB`);
          }
        }, 10000);
        
        return entries;
      };
    }
    return config;
  }
};

Worker Thread Leak Detection:

// Monitor worker memory lifecycle
const workers = new Map();

const createWorker = (scriptPath) => {
  const worker = new Worker(scriptPath);
  const startMemory = process.memoryUsage().rss;
  
  workers.set(worker, {
    startMemory,
    created: Date.now()
  });
  
  worker.on('exit', () => {
    setTimeout(() => {
      // Check if memory was actually freed
      const currentMemory = process.memoryUsage().rss;
      const workerInfo = workers.get(worker);
      
      if (currentMemory > workerInfo.startMemory + (50 * 1024 * 1024)) {
        console.warn(`Worker may have leaked ${Math.round((currentMemory - workerInfo.startMemory) / 1024 / 1024)}MB`);
      }
      
      workers.delete(worker);
    }, 5000); // Allow time for GC
  });
  
  return worker;
};

Production is where this gets really ugly

Container Memory Pressure Detection:

// Early warning system for container environments
const checkContainerLimits = () => {
  try {
    const fs = require('fs');
    const memLimit = fs.readFileSync('/sys/fs/cgroup/memory/memory.limit_in_bytes', 'utf8');
    const memUsage = fs.readFileSync('/sys/fs/cgroup/memory/memory.usage_in_bytes', 'utf8');
    
    const limitMB = parseInt(memLimit) / 1024 / 1024;
    const usageMB = parseInt(memUsage) / 1024 / 1024;
    const usagePercent = (usageMB / limitMB) * 100;
    
    if (usagePercent > 80) {
      console.error(`Container memory critical: ${usagePercent.toFixed(1)}% (${usageMB.toFixed()}MB/${limitMB.toFixed()}MB)`);
      return true;
    }
  } catch (e) {
    // Not in container or cgroup v2
    const rss = process.memoryUsage().rss / 1024 / 1024;
    return rss > 1000; // 1GB fallback threshold
  }
  
  return false;
};

// Check every minute
setInterval(checkContainerLimits, 60000);

Once you've mastered debugging, here are the solutions that actually work in production.

Stuff to try first (before you rage quit and go back to Node.js like I almost did)

1. Update Bun (Sometimes They Actually Fix Stuff)

Bun releases happen pretty frequently and they do fix memory issues... sometimes. Check the release notes, GitHub releases, and the main Bun repository for memory-related fixes. The recent v1.2.2 update supposedly addressed several memory issues, and DEVCLASS coverage mentions new debugging improvements. Worth checking if you're on some ancient version that has known problems:

## See what you're running
bun --version

## Update to latest (might help, might break something else entirely)
bun upgrade

2. Stop Collecting Blobs Like Pokémon Cards

The Blob/ArrayBuffer memory leak is real. Don't store them in arrays or they'll never get freed:

// This kills your server
const blobs = [];
for (const url of urls) {
  const response = await fetch(url);
  blobs.push(await response.blob()); // Never gets freed
}

// Process immediately instead
for (const url of urls) {
  const response = await fetch(url);
  const blob = await response.blob();
  await processBlob(blob); // Use it and lose it
}

3. Next.js Build Memory Management

For large Next.js builds, you basically need to kill the process before it eats all your memory:

// Kill build before it crashes
setInterval(() => {
  const memMB = Math.round(process.memoryUsage().rss / 1024 / 1024);
  if (memMB > 2000) { // 2GB = time to die
    console.error(`Build memory at ${memMB}MB - killing before OOM`);
    process.exit(1);
  }
}, 30000);

Here's some stuff that actually works

4. Process Stuff in Chunks

Don't try to process everything at once or you'll run out of memory. Break it into chunks of like 100 items and force GC between them (though it probably won't do anything).

5. Cycle Your Workers

Workers leave memory ghosts, so kill them after like 1000 tasks and make new ones. It's annoying but it works.

6. When Everything Goes to Shit

If memory hits like 1500MB, clear any caches you have, spam Bun.gc(true) a few times, and if that doesn't work just restart the process. Not ideal but better than OOMKilled.

These solutions might save your servers, but you'll probably still have questions. Here are the ones I get asked most often.