Hey everyone,
I just wanted to chime in because my team experienced this exact same issue recently. During a massive traffic spike on our Ghost site, the log files grew drastically high over a short period. Since standard rotation is purely time-based (e.g., waiting 1 day to rotate), the file had plenty of time to indiscriminately consume our infrastructure until the site crashed entirely with a no space left on device error.
It was frustrating enough that we actually dug into the Ghost framework’s core codebase to see why we couldn’t just restrict the file size limit inside config.production.json.
Here’s what we found to fix it: Ghost does actually possess an incredibly robust log rotating engine natively (bunyan-rotating-filestream) that supports strict size-limits and gzip compression! However, it was completely hidden in the background, making it impossible for server admins to natively access these capabilities via regular defaults.
To solve this for all of us, we just created a Pull Request that formally exposes these advanced parameters to the default file structure. Once merged, any admin can securely cap their logs by size and enable compression, like this:
{
"logging": {
"rotation": {
"threshold": "50m",
"gzip": true
}
}
}
With this, Ghost will actively monitor the log size and instantly compress and rotate it the moment it hits 50m, fully preventing the disk-space bloat crashes.
If this has been a major pain point for you as well, it would be awesome if you could support/review the PR over on GitHub to help us get it merged into core faster!
You can check out the Pull Request here: https://github.com/TryGhost/Ghost/pull/27107
Hopefully, this permanently resolves the log nightmares for high-traffic sites