DevCleaner 1.6.0: Project Hibernation for Mac developers
Just shipped the biggest @DevCleaner update yet.
📦 Project Hibernation lets you archive projects you are not actively working on, off your disk into a single file, and restore them in one click whenever you need them. It handles dependency reinstall on restore, is iCloud aware, and verifies every archive before touching the original.
👻 Also added Ghost Projects (per project Xcode DerivedData breakdown) and Project Artifacts (stale node_modules and build folders ranked by age).
✨DevCleaner stays free for manual cleanup and scanning. The automation layer is now Pro, with a 14 day free trial. Lifetime licenses are capped for early supporters at 29 dollars.
Would love feedback from the dev community here. What would you want a tool like this to do next?
Download here
👉🏼 devcleaner.app 👈🏼
Replies
Interesting product. But project can have many dependancy config, does it package all at once and archive? like docker?
DevCleaner
the hibernation concept is the thing i didn't know i needed. i keep dead projects on disk just because "setting it back up later is annoying," which is a terrible reason to waste 30GB. archiving to iCloud with dependency reinstall on restore actually removes that excuse completely.
one thing i'd love to know: how does it handle projects with multiple package managers, like a repo that has both npm and a Python venv? that's where most cleanup tools get weird for me.
DevCleaner
@nolan_vu Good catch - and thanks for the nudge, this was a really useful idea.
How it worked until recently: Light hibernation already stripped all regenerable dependency folders (node_modules, .venv, target, .gradle, etc.) no matter how many ecosystems were in the repo. Lockfiles stayed. On restore, though, DevCleaner only suggested one reinstall command based on a fixed priority (pnpm → yarn → bun → npm → … → poetry → pip → …). The only automatic multi-step combo was one package manager + Docker Compose (npm install && docker compose build). So a repo with npm and Python would archive correctly, but one-click restore might only run npm install — you'd handle the venv yourself.
What it does now (1.6.1+): It detects every applicable ecosystem in the project and chains them into a single one-click command, in a sensible order:
One JS tool (pnpm / yarn / bun / npm - whichever lockfile wins)
Then other stacks that apply: CocoaPods, Cargo, Swift PM, Go, Composer, Poetry, pip, pipenv, Bundler, Maven, Gradle - all that have markers in the repo
Docker Compose build last, if there's a compose file
Examples:
package.json + requirements.txt → npm install && pip install -r requirements.txt
Same + compose.yml → npm install && pip install -r requirements.txt && docker compose -f 'compose.yml' build
Cargo.toml + poetry.lock → cargo fetch && poetry install
Docker named volumes are still always snapshotted; images rebuild in light mode or are saved in full archive.
So yeah - the “dead project on disk because setup is annoying” excuse should be even weaker now. Appreciate you asking; this shipped because of feedback like yours.
@dawedeveloper this is the right call. the old "one package manager wins" logic was always a bit fragile the moment you had a full-stack repo with Python tooling sitting next to the JS layer.
the chaining order matters too and sounds like you've thought through it. docker compose last makes sense, you don't want it pulling before deps are in place. shipping this kind of thing because someone asked is exactly how good tools get built.
DevCleaner
@nolan_vu I'm a solo developer, so I'm driven by feedback and ideas from users 🚀
@dawedeveloper great, I hope that you can receive positive feedback then
When you restore a project, does it fully recreate the original state or just the structure?
DevCleaner
$29 lifetime early access feels fair if it actually saves real disk + setup time.
DevCleaner
One question: have you considered adding support for Docker-based projects so developers can restore not only the codebase but also the exact runtime environment?
That would make long-term project recovery even more reliable.
DevCleaner
@prashant_patil14 Great suggestion, and it lines up really well with how Hibernation already thinks. Your Dockerfile and compose file are part of the codebase, so they get archived today. The interesting part is what they reference: built images (regenerable, like node_modules) and named volumes (your actual data, which nothing can rebuild).
The plan I am leaning toward: snapshot the named volumes into the archive since that is the irreplaceable bit, record the build or pull commands in the restore manifest, and on restore offer a one-click "docker compose build and up" the same way it offers npm install today. The new dry-run preview would show exactly which volumes and images come back before you commit.
One honest caveat: rebuilding from a Dockerfile is only as reproducible as the image tags it pins, so for a guaranteed offline restore there would be a "full" mode that exports the images too. Adding this to the roadmap. Thanks for pushing on long-term reliability, that is exactly the goal.
Project hibernation is a very practical idea. Developers accumulate local environments the same way teams accumulate unused SaaS tools: slowly, invisibly, and then suddenly it becomes a mess.
The restore confidence is the key part. If I archive a project, I need to trust that it can come back cleanly with dependencies, files, and context intact. The verification step before touching the original feels important because this is one of those workflows where one bad restore can make people stop trusting the feature entirely.
DevCleaner
@rahulbhavsar Thanks - this is exactly why I built hibernation the way I did. Archiving only removes your project after the zip/tar is built, integrity-checked, and (if configured) moved to your external drive or iCloud; any step fails and the folder stays put. On restore, we added Preview restore in 1.6.1 (eye icon in Archived Projects): it verifies the archive, shows the exact destination path, file count, and top-level contents - without downloading an iCloud-parked file or touching anything on disk. If something already lives at the original path, we restore alongside it as ProjectName (restored), never overwrite. Light archives keep source, git, and lockfiles and offer one-click pnpm install / pod install / etc. (plus Docker volume snapshots where applicable); full archives are meant to come back ready to open. Restore is free even without Pro - we'd rather you trust the round-trip than gate getting your code back.