Cloud backup usually sounds binary: either keep the vault on one device or upload the whole thing. That is a poor fit for a vault that contains different kinds of risk. You may want passwords available after a lost phone while keeping a passport scan local. You may want one encrypted project folder on two devices but never place a private journal in cloud storage. Encryption helps, but it does not answer the policy question: which data should leave the device at all?
Quick answer
Yes. Krypt Pro can sync an encrypted real vault while withholding selected files, folders, folder descendants, and secure notes. Full encrypted file-blob sync is opt-in; the default cloud backup contains the encrypted vault database rather than every stored file. Before Krypt uploads either backup type, it creates a separate sanitized SQLCipher database and removes supported records whose Exclude from Sync metadata decrypts and parses successfully. A complete bundle then takes its encrypted-file inventory from that sanitized copy.
The boundary matters. Individual passwords and passkeys do not have an Exclude from Sync control. Unreadable or corrupted exclusion metadata is treated as eligible rather than stopping the backup, so this is not a fail-closed information-flow control. Excluding something today does not reach backward into an older provider snapshot, deleted-backup area, version history, or copied archive. Backup creation and ongoing cloud sync require Krypt Pro and an unlocked real vault; Krypt separately documents a narrow fresh-device restore exception for backups previously created with Pro. The decoy vault never syncs.
Start with data minimization, not the cloud toggle
A useful threat model separates confidentiality from disclosure. Client-side encryption can make an uploaded object unreadable to the storage provider, an account intruder who lacks the vault key, or someone who finds a copied archive. Yet uploading still creates another object, another retention lifecycle, another account dependency, and another place where ciphertext can be deleted, rolled back, or taken for offline analysis.
The NIST Privacy Framework treats data minimization and selective disclosure as privacy-engineering outcomes. The practical lesson is not that cloud storage is automatically unsafe. It is that a system should let the owner decide what processing is necessary instead of assuming that all available data should follow the same route.
Ask three questions for each class of vault content:
- Availability: would losing the device make this item difficult or impossible to reconstruct?
- Disclosure: does creating an encrypted off-device copy add a risk or policy conflict that matters to you?
- Recovery: do you have the matching Rescue Key, provider access, and a tested restore path?
A password database may score high on recovery value. A temporary legal document may score high on disclosure sensitivity. A large media archive may be recoverable elsewhere and expensive to replicate. The right answer can differ between folders even when the cryptography is identical.
Database-only is Krypt's cloud default
Krypt distinguishes the encrypted database from the opaque encrypted files stored beside it. The SQLCipher database holds passwords, passkeys, secure-note content, file records, organization data, and other encrypted vault state. Photos, videos, and documents are stored as separately encrypted file blobs. That split lets the backup policy avoid treating a small credential database and a large private-media collection as one indivisible object.
By default, Krypt cloud sync creates a database backup. Including eligible encrypted file blobs requires the owner to enable complete vault sync. This is an explicit opt-in because a complete bundle changes storage size, transfer time, and the disclosure surface. A newly restored device keeps complete file sync disabled until the owner deliberately enables it again. The default is therefore conservative even after recovery.
| Choice | New backup contains | Important limit |
|---|---|---|
| Database-only default | Sanitized encrypted SQLCipher database | Does not carry the separately stored photo, video, and document blobs |
| Complete vault sync | Sanitized database plus eligible encrypted file blobs and authenticated inventory | Must be enabled; larger and more data leaves the device |
| Exclude a file | Other eligible records; not that file record or blob | Controls later Krypt backups, not old provider copies |
| Exclude a folder | Other eligible records outside the excluded tree | Review after future moves, imports, and reorganization |
| Exclude a secure note | Other eligible database records | Passwords and passkeys have no equivalent per-record switch |
NIST SP 800-209 describes storage protection as a combination of controls that includes isolation, restoration assurance, encryption, authorization, and change management. Scope selection belongs in that wider system. Encryption is essential, but it should not be used as a reason to replicate unnecessary data everywhere.
How Krypt builds a sanitized cloud copy
Krypt does not edit the live database in place to prepare an upload. It creates a temporary SQLCipher copy, reproduces the schema and rows, then evaluates the encrypted metadata that carries each supported exclusion flag. It removes excluded file, folder, and secure-note rows from this destination copy. Album links to excluded files are removed as well. The open local vault remains the working source.
Folder handling is recursive in two places. When the owner toggles a folder, Krypt applies the flag to its current child folders and files. During every sanitization pass, it also recomputes the excluded descendant tree and treats a file as excluded when its containing folder remains inside that tree. This covers new descendants even when their own flag differs from an excluded ancestor. If encrypted exclusion metadata cannot be decrypted or parsed, however, Krypt treats that row as eligible; the upload does not fail closed on that error.
If complete vault sync is enabled, Krypt reads the encrypted-file inventory from the sanitized database. It builds an authenticated manifest for that inventory and adds only those referenced ciphertext files to the bundle. For exclusions the sanitizer successfully evaluates, the database and file set therefore describe the same selected scope: removed records do not remain as broken pointers, and their blobs are not added as unreferenced extras.
The Exclude from Sync preference is itself held inside encrypted metadata for the corresponding record. That avoids turning the local database's ordinary columns into a readable list of which filenames or note titles the owner considers especially sensitive. Like other client-side controls, it still depends on trusted Krypt software and a trustworthy unlocked device. Malware controlling the session can act with the user's authority.
Krypt's answer: separate local use from off-device recovery
Krypt is a zero-knowledge password manager and encrypted file vault that makes cloud storage optional. Its answer is to preserve a fully usable local vault while letting the owner create a narrower encrypted recovery object. A file marked local-only remains encrypted in the active vault and available while that device and vault are available; it is simply omitted from later sanitized Krypt cloud backups.
This model also preserves explicit provider ownership. Krypt uploads ciphertext to the cloud account the user chooses. The provider does not receive the vault master key in plaintext from Krypt. NIST SP 800-111 explains why storage-encryption design must match the storage location and threats being mitigated. Krypt's local encryption and selective backup policy address different layers: one restricts reading; the other limits which encrypted objects are replicated.
The control is deliberately narrower than a general information-flow policy. It does not stop a user from exporting a decrypted copy, attaching a file elsewhere, taking a screenshot, or importing the same source into another synced folder. It does not inspect third-party backup software that may capture device-level app data. It governs the backup artifacts Krypt creates through its own cloud-sync workflow.
What you can exclude—and what you cannot
Files can be excluded individually from their details or sync control. Folders can be excluded recursively; Krypt recomputes descendants that remain under the excluded tree at backup time. Secure notes have their own Exclude from Sync option in the editor. These supported records are removed when the sanitizer can read their encrypted exclusion metadata successfully.
Passwords and passkeys do not have per-record exclusion settings. If cloud sync is enabled for a real vault, do not claim that one selected login or passkey remains local because a nearby folder is excluded; folders do not contain credential records in that sense. If a credential must never participate in a cloud backup, place it in a different real vault whose cloud sync is not configured, or keep cloud sync off for the vault that contains it. Multiple real vaults remain separate encryption and cloud contexts.
The decoy vault is not another sync target. Krypt's cloud service requires an unlocked real-vault context and rejects the decoy identity. That boundary prevents a cloud account from becoming a source of decoy-vault state or an accidental relationship between the decoy and a configured provider. Do not describe the decoy as backed up, mergeable, or recoverable from Krypt cloud sync.
Exclusion is not retroactive deletion
Suppose a photo was included in Monday's complete bundle and marked Exclude from Sync on Tuesday. Wednesday's new sanitized backup can omit it. Monday's encrypted bundle may still exist as a retained snapshot, in Deleted Backups, in provider version history, on another device, or as a downloaded copy. The Tuesday preference cannot authenticate to every storage system and recall all earlier bytes.
This is why deletion and backup retention need separate decisions. The UK National Cyber Security Centre's ransomware-resistant cloud backup principles recommend version history, recoverability after corruption, soft deletion, and policies aligned to risk. Those resilience features intentionally keep older data available. Privacy cleanup and recovery resilience can pull in opposite directions, so deleting old generations without checking recovery coverage can solve one risk by creating another.
Krypt keeps a latest primary and limited snapshots per backup type, and its backup manager separates active and deleted cloud backups. Review those surfaces when retiring a previously synced item. Also examine any provider-native trash or version history. Keep at least one known-good, tested recovery path before permanently removing generations. CISA's StopRansomware Guide emphasizes isolated, encrypted backups and regular recovery testing because an inaccessible or untested backup is not meaningful protection.
Encryption reduces exposure; minimization reduces copies
Client-side ciphertext is still data. A provider can normally observe account identity, object existence, approximate size, timestamps, and access events even when it cannot read the protected content. A person who steals ciphertext may retain it for future offline attack. A provider account problem may delete or deny access to every stored generation. Selective sync lowers the quantity and sensitivity of replicated material, but it does not make the remaining backup invisible or indestructible.
The OWASP Cryptographic Storage Cheat Sheet begins architecture with the threat model and advises minimizing sensitive storage where possible. That principle explains the layered answer: encrypt what must be stored, omit what need not be copied, maintain recoverability, and keep the keys separate from the backup.
Selective-sync checklist
- Classify vault content by recovery need, disclosure sensitivity, size, and policy obligations.
- Decide whether database-only sync is enough before enabling complete encrypted file bundles.
- Mark individual files and secure notes local-only where appropriate; use folder exclusion for a whole current subtree.
- Confirm the sync status shown in Krypt after moving or reorganizing sensitive content, especially when an item leaves an excluded folder tree.
- Remember that passwords and passkeys cannot be excluded one by one; use a separate unsynced real vault when that boundary is required.
- Run Sync to Cloud and confirm completion. A local setting is not proof that a new sanitized backup reached the provider.
- Review old Krypt snapshots, Deleted Backups, provider history, and independent copies before claiming historical removal.
- Keep the matching Recovery Kit separately and test a representative restore without sacrificing the only working vault.
FAQ
Can Krypt sync passwords while keeping selected private files off the cloud?
Yes. Krypt cloud sync creates a sanitized encrypted database copy and omits files, folder trees, and secure notes whose Exclude from Sync metadata can be read successfully. Unreadable or corrupted exclusion metadata is treated as eligible rather than stopping the backup, so verify the resulting scope. Complete file-blob sync is off by default, and passwords and passkeys have no per-record exclusion control.
Does Exclude from Sync remove an item from backups already stored by my cloud provider?
No. The setting controls sanitized backups created after the exclusion is applied. An older primary backup, retained snapshot, deleted-backup area, provider version history, or independently copied archive may still contain the earlier encrypted record or file. Review and retire those generations separately without destroying your only recoverable backup.
What happens when I exclude a folder from Krypt cloud sync?
Krypt applies the setting to the folder's current descendants and recomputes the excluded descendant tree when preparing each backup. Items that remain under the excluded folder are omitted when their metadata can be read successfully. Review after moving or reorganizing content because an item moved outside that tree may become eligible for a later backup.
Can the Krypt decoy vault be synced to iCloud or Google Drive?
No. Krypt cloud operations require an unlocked real vault and reject the decoy-vault identity. Cloud sync is a Krypt Pro feature. The decoy remains local, and its contents are outside Krypt's cloud backup, restore, and merge workflows.
Technical references
The NIST Privacy Framework covers data minimization and selective disclosure. NIST SP 800-209 addresses storage isolation, protection, and restoration assurance, while NIST SP 800-111 explains storage-encryption choices. The CISA StopRansomware Guide and NCSC cloud-backup principles cover recoverable, tested, resilient generations. The OWASP Cryptographic Storage Cheat Sheet connects threat modeling, encryption placement, and minimizing sensitive storage.
Use Krypt to keep a local-first encrypted vault while choosing which supported files, folders, and secure notes belong in future cloud backups.
