Honest answers, including the ones where Densar is not the right tool.
These questions were not invented by us: they came from people who read about Densar and pushed back.
Copying it is half the job. The paths inside are written in full: on the new PC the user changes, or a folder gets a different name, and from that moment the memory is there but points at places that no longer exist. It happened to us after renaming one folder: forty paths still pointing at the old name, and not one error message anywhere. What stays out is everything else: junctions, the files git ignores on purpose, and the programs to reinstall.
You can, and it will write you the scripts too. The catch is that a new PC is full of traps you only meet there: on a fresh Windows npm does not start, because it is a script and the execution policy refuses it; a command can fail and still return zero, that is, claim success; a junction copied as a folder becomes a duplicate that quietly diverges from that day on. We hit all of them, one by one, and what you get is the result.
For documents they are fine. For a working setup they are not, and the reason is specific: an ordinary copy walks through junctions and duplicates them, so instead of one link you end up with two real folders that quietly drift apart from then on. On top of that, the assistant's memory stays pinned to the old paths. Densar recreates them as links, remapped to the new location.
They do a different job, and in their own field they do it better than us: Docker isolates a runtime environment, Ansible rebuilds a machine from a description, which however you write and keep up to date. Densar starts from the opposite end: it looks at the machine as it is today and works out for itself what is needed to rebuild it elsewhere, without you having written anything.
Exactly what the repository leaves out on purpose: .env files, keys and credentials. Then junctions and linked folders outside the root, the assistant's memory, local configuration, and the list of dependencies to reinstall, with the command and the folder for each one. The .git folder goes in whole, so history and remotes stay where they were.
The archive is encrypted with age, an open standard, and the password is mandatory. The stream goes from disk to archive without a single byte being written in the clear, not even into a temporary file to be deleted afterwards. Next to the archive there is a readable guide with the steps to restore it, because on the day you need it we might not be around.
Yes, and it is not a promise: it is how the program is built. Restoring never asks for a licence, on any machine, not even from someone who never bought it: the archive and the password are enough. And since age is a standard, that archive opens with other tools too, on the day we are no longer around.
No, and it is not a temporary gap: the engine is tied to Windows exactly where it matters (NTFS junctions, PowerShell, winget). macOS is not in development. If you want it, leave your email on the download page: that is the only measure we look at to decide whether it is worth building.
The whole analysis, with no account: Densar reads your disk and shows what it would take and what it would skip, junctions, memory and secrets included, before you decide anything. On a real case that was 0.38 GB to archive against 21.73 GB of caches skipped. Every classic backup stays free forever, BK Mirror included, and so does restoring: you only pay to create a BK Smart AI, 39 euro once.
The download page shows the file's SHA256 fingerprint, right under the warning box. On your PC, in the folder where you saved it, open PowerShell and run Get-FileHash densar.exe (or, in Command Prompt, certutil -hashfile densar.exe SHA256). It prints a long string: if it matches the one on the page, character for character (upper or lower case does not matter), the file is byte for byte the one we published. If it does not match, do not run it and write to us at info@chrononyte.com.