Densar BK
Rebuilds your Windows dev setup, not just the files
I moved my work to a new PC and lost a day to it, with everything already in git.
The code came back fine. What didn't:
The junctions. My project folders point outside themselves, and a plain copy turns a junction into a second real folder. Two copies that drift apart quietly, with no error and no failing test.
The .env files and local configs, gitignored for good reasons and therefore nowhere.
The AI agent's memory, which lives outside the project and is keyed on the absolute path. On the new machine the agent silently starts from nothing.
The toolchain. Knowing which things to reinstall is easy. Remembering the one you installed once to make a single project build, and never thought about again, is not.
Densar scans the root folder, finds those by itself, and writes an encrypted archive. It skips what can be rebuilt from scratch: in one real run, 0.38 GB archived against 21.73 GB of caches left out. On the new PC it recreates the junctions rather than duplicating them, remaps the paths, reinstalls the toolchain, and lists what is still missing for each project, with the command and the folder.
Windows to Windows. The analysis is free and shows what it would find on your system before you decide.
14 Comments
The junction-to-duplicate-folder failure mode is nasty specifically because nothing errors — you just get two copies quietly diverging until something breaks weeks later for a reason nobody can explain. That's a much scarier bug class than a missing file, since a missing file at least fails loudly.
The "agent memory keyed on absolute path" one hit close to home — I built a small research agent a couple days ago and didn't think twice about hardcoding paths relative to its home directory. Never considered what happens to that state on a machine move until reading this.
Curious how Densar handles the toolchain side specifically — is it inferring "installed once, forgotten about" tools from build logs/error output, or does it need some kind of manifest to know what a project actually needs versus what's just present on the system?
Neither, actually: no build logs and no manifest to write. Densar walks the project folders and reads the manifests that already exist: package.json means Node, Cargo.toml means Rust, requirements.txt or pyproject.toml means Python, and so on. On the new machine it installs them itself, at the press of a button; the same winget commands also end up in the guide that travels with the archive, but that's the fallback, not the mechanism.
The distinction you ask about, what a project needs versus what's merely present, lives in the next step: it doesn't trust declarations of success. I deliberately chose not to infer from logs: a backup has to come out identical on every run, and log inference isn't. It looks at the disk instead: node_modules is there or it isn't, the pip packages are installed or not, the first Rust build has happened or not. That part was born from a real failure: runtimes installed, "completed" on screen, and the project still refusing to start.
Git handles the code, but the real project state is often everything around it.
The AI agent memory piece is becoming more relevant as workflows become more personalized. Curious if you see this expanding beyond PC migration into ongoing developer environment backups?
Not today, and I'd rather be straight about it: there's no scheduler in it. You run it by hand, when you're about to change machine or rebuild one, or just to make yourself an archive that works and keep it there as a safety net.
The rebuild is done by the program though, not by you. On the new machine you open Densar, hand it the archive, and it puts things back where they belong, junctions included. The dependencies you need to install are ones it has already found for you, and it's a couple of clicks in the interface. A guide travels with the archive, but it comes along for the ride, it isn't how the job gets done.
The agent memory part is the piece I care about most too. The configs an assistant reads, the skills written for it, the local state it keeps: none of that is in git, and file sync doesn't really cover it either, because half of that stuff only means something together with the paths and the credentials sitting around it. In Densar it's the one thing that lands outside the folder you pick, so it's a checkbox you turn on yourself.
I'm not ruling it out for the future at all, and it will depend a lot on how people use it. The technical route is already there: I have a scheduler in another product of mine and I could hook it up to that, it would just mean working on both at once. If I do it, I want to do it properly. For now what it does is rebuild the environment.
I appreciate you taking the time to explain your thinking.
I'd be interested in continuing the conversation by email if you're open to it. What's the best email to reach you on?
Yes, it's in the footer of my site. If it's a technical question though, leaving it here in the thread makes it useful to whoever lands on it later.
“Rebuilding the setup, not just files, is interesting. What’s the moment where devs realise this saves them real time?”
For me it was the move I describe in the post: a day lost with everything already in git. But that's something you only notice afterwards, which is the worst place to notice it.
I don't have customers telling me this yet, so the rest is my reading rather than data. The part that costs time isn't the code, it's what sits around it: API keys in local config files, junctions between folders, virtual environments, fonts, and paths hardcoded into scripts written a year earlier and forgotten.
That’s such a painful category of problems because it only shows up after the damage is done.
The tricky part is that awareness is low until someone loses a day like you did.
Have you thought about how you’d surface this earlier in the workflow, before the ‘oh shit’ moment happens?
That's the thing: before the damage there is no signal, because nothing is broken. A junction that turned into a real folder still works. Agent memory keyed to the old path throws no error, it just stops being found.
So I stopped trying to catch it earlier and flipped the approach: the backup also captures what git doesn't see, and the moment of truth becomes the restore, not the move. That's really where Densar came from: the list of things I had to fix by hand that day.
That’s a sharp shift — you’re basically accepting that the system won’t warn you, so you’re anchoring around the moment where correctness actually matters.
What’s interesting is that this turns Densar into less of a “backup tool” and more of a “guarantee that recovery won’t break under real conditions.”
The products that come out of these kinds of failures usually resonate most with people who’ve already been burned the same way — not people trying to be proactive.
Curious — are your early users finding you after experiencing something like this, or are they adopting it before anything breaks?
Happy to take a look at how you’re framing this — feels like one of those where positioning it around that “moment of truth” could pull in much higher-intent users.
I don't know yet, and I'd rather say so: it went on sale a few weeks ago and I don't have a user base to read that from. My bet is the same one you describe: someone who has already been burned understands the product in ten seconds, and someone who hasn't has no reason to go looking for it.
That's also why the analysis is free: you download it from the site, run it, and it shows what it would find on your system before you decide anything. It's the only way I've found to talk to someone before the damage: not a warning, but the concrete list of what their git isn't saving. If you're curious, the quickest way to get a feel for it is exactly that.
This is a classic “pain only exists after it happens” product.
The free analysis is smart — it creates that “oh shit” moment before loss.
I’d double down on showing real examples of what Git misses — that’s what converts curiosity into action.
The examples are the part I have, since the list came out of my own move: a junction that came back as a real folder and quietly diverged, .env files sitting next to the code and never in it, the agent's memory keyed to the old path, the virtual environments and toolchains git has no reason to know about. The free analysis prints exactly that for your own disk, sizes included, before you decide anything. Putting those cases up front rather than leaving them in the post is a fair point.