It's been a while since VaultSync 1.8.9, and I wanted to explain what's actually happening with 1.9.0, why development is taking significantly longer than previous updates, and what this means for future releases.
The short version: 1.9.0 isn't just another feature update. It's the foundation for the next generation of VaultSync.
Why is it taking so long?
Until now, VaultSync has primarily focused on protecting files and projects, keeping backup history, verifying integrity, and helping users understand whether their data can actually be recovered.
With 1.9, we're going considerably further.
The central question is changing from "Can I recover my files?" to "Can I recover when my disk fails or my operating system no longer boots?"
That requires a completely different level of engineering.
We're working toward disk and partition cloning, verifiable disk images, independent bootable recovery, and safe restoration.
And those features cannot simply be developed separately and thrown together at the end.
A disk image is only useful if it can actually be restored. A recovery environment is only useful if it works without the original installation. And a cloning engine must never accidentally overwrite the wrong disk.
A small mistake in an ordinary UI feature might be annoying. A small mistake in a disk restoration operation could destroy someone's data.
That's why so much development time is going into architecture, isolation, failure handling, compatibility, and testing.
So, where are we right now?
Quite a lot has happened behind the scenes.
- Disk image foundations: We've been developing the image format, integrity verification, source identity checks, and safeguards against incomplete or corrupted images.
- Recovery architecture: The recovery worker, controller, authorization, cancellation, and restoration components are being built and tested separately from the installed application.
- Bootable recovery: Work is underway on the independent recovery environment and its graphical interaction flow. Native testing has already exposed startup and cleanup issues that need resolving.
- Desktop experience: A dedicated Disk Cloning page has been added in development, alongside navigation improvements and localization work.
- Existing VaultSync improvements: We've also addressed backup exclusions, metadata handling, cross-platform UI issues, packaging, and other reliability problems discovered during development.
But I want to be clear about what this means.
1.9.0 is not beta-ready yet.
The major remaining milestone is proving the complete workflow: create an image, validate it, boot independently, restore it, and verify the restored system.
That needs to work safely on an explicitly supported test configuration before I ask people to try a beta capable of writing to disks.
Broader operating-system and hardware support will require additional qualification.
I'm not interested in calling something finished just because individual components pass their tests.
Why should subsequent 1.9 releases be faster?
This is the part I'm particularly excited about.
Much of the time spent on 1.9.0 is being invested in systems that later updates can reuse.
Instead of rebuilding the image format, recovery foundations, safety mechanisms, testing infrastructure, and internal service boundaries every time, future releases can focus more directly on extending them.
The current roadmap includes:
- 1.9.1: Clone Explorer, for inspecting and extracting files from supported images.
- 1.9.2: Portable Recovery, including recovery without the original VaultSync installation.
- 1.9.3: Offsite Protection.
- 1.9.4–1.9.5: A more unified recovery experience, stronger recovery assurance, and expanded CLI workflows.
- Later 1.9 releases: Binary Source Control, collaboration features, and long-term stability work.
These are still substantial projects, particularly Binary Source Control, so I won't pretend every future release will be quick.
But the goal is to make development more incremental and predictable instead of requiring another enormous foundational effort for every feature.
Some of the groundwork for later releases is already being developed on separate branches, without adding that scope to 1.9.0.
What happens next?
The immediate priority is the full disk recovery workflow, followed by the remaining platform, safety, compatibility, and release checks.
I still plan to publish beta builds before the stable release, but they need to meet the minimum safety requirements first.
The roadmap has a planning target, but I'm not treating that as a guaranteed release date.
I know the gap between updates is unusual compared with earlier VaultSync releases. Development hasn't stopped. A lot of the work is simply happening in areas that aren't particularly visible in screenshots or changelogs.
I'd rather spend additional time proving that recovery works than release something that gives people a false sense of security.
The goal isn't just to make VaultSync capable of creating more kinds of backups. It's to make sure those backups can actually get you out of trouble when things go wrong.
You can follow the development here:
Thanks to everyone following the project, testing releases, reporting issues, and sharing feedback. It genuinely helps shape what VaultSync becomes.