What Cloudless Can and Cannot See

Backup software asks for a lot of trust.

It touches files people care about: work documents, source code, tax records, photos, exported passwords, client files, project archives, and old folders they may have forgotten about. A backup app should not ask for that trust with vague language.

So this post answers the direct question: what can Cloudless see, and what can it not see?

The short version is this: Cloudless is designed so your files are encrypted on your device before backup data leaves the device. Our server does not receive your passphrase, plaintext file contents, plaintext file names, or plaintext folder paths.

That does not mean Cloudless sees nothing at all. Some metadata is still needed to run the service, show backup status, manage versions, support billing, and help the app restore files. Security is better when those limits are stated plainly.

What Gets Encrypted On Your Device

Cloudless encrypts backup data locally before upload. The important part is where encryption happens. Your device prepares protected backup data first, then the app sends encrypted data to storage.

Before upload, Cloudless encrypts:

file contents
file names
folder paths
backup source directory paths

File contents are split into chunks, compressed, and encrypted before they are written to your chosen storage provider. File and path information is also encrypted before it leaves the device.

This matters because server-side encryption is not the same privacy model. If a service receives readable files and encrypts them later, the service had a chance to see those files. Cloudless is built around client-side encryption so readable backup data does not need to pass through our server.

What The Cloudless Server Never Receives

The Cloudless server does not receive your encryption passphrase.

It also does not receive:

plaintext file contents
plaintext file names
plaintext folder paths
the plaintext data encryption key
any key that can decrypt your file contents

Your passphrase is used locally to unlock encryption material. The server stores only protected key material that is not useful by itself. In plain terms, the server can help your account and devices coordinate backup records, but it should not be able to open your backed-up files.

This is the privacy boundary Cloudless is built around.

What Your Storage Provider Sees

Cloudless is a bring-your-own-storage backup app. You choose a supported storage provider, such as an S3-compatible bucket or another supported target, and Cloudless writes encrypted backup data there.

Your storage provider receives encrypted backup objects. It should not receive plaintext files, plaintext file names, or plaintext folder paths from Cloudless.

The storage provider may still see normal storage facts. For example, it may see that objects exist, roughly how large they are, when they were written, access logs, account identifiers, network information, and storage region information. Encryption protects the contents of backup data. It does not make all storage activity invisible.

That distinction is important. Cloudless is designed to keep your files unreadable to the backup service and storage provider. It is not designed to hide the fact that backup activity happened.

What Metadata Cloudless Can Still See

Cloudless still needs some information to operate the product.

Our server may store account and service information such as:

account email and display name
device identifiers and platform information
backup and restore operational state
billing and subscription state
service and security logs

Cloudless may also store backup metadata needed for the app to work, including:

file sizes
file modification timestamps
version counts
per-user chunk hashes used for deduplication
blind indexes used to look up encrypted filename records by exact match

Those last two points are more technical, but they are worth saying clearly.

Cloudless uses hashes to avoid storing duplicate chunks for the same user. Because those hashes are based on plaintext chunks before encryption, the server could in principle know that a user has backed up a chunk matching a known hash. These hashes are scoped per user.

Cloudless also uses a blind index for filename lookup. This lets the app find encrypted filename records by exact match without storing the readable file name on the server.

This is not the same as seeing your file contents or readable paths. It is still metadata, and metadata can matter. A serious backup product should be honest about that.

Why Support Cannot Recover A Lost Passphrase

If you lose the passphrase or recovery material needed to unlock your backups, Cloudless support cannot recover your files for you.

That can sound harsh, but it is part of the security design.

If support could reset your passphrase and decrypt old backups, then Cloudless would have some path into your data. That path could be abused, subpoenaed, stolen, or exposed through an infrastructure compromise.

Cloudless takes the other tradeoff. We do not keep the secret needed to decrypt your backups. That gives you stronger privacy, but it also means recovery material has to be treated as part of the backup.

Your backup plan should include:

a strong passphrase
a safe place for recovery material
access to your Cloudless account
access to your storage provider
a restore test before you rely on the setup

An encrypted backup that nobody can unlock is not a backup in practice. Please treat your passphrase with the same seriousness as the files you are protecting.

What Cloudless Is Not Claiming

Cloudless is not a magic shield against every data loss or security problem.

Client-side encryption helps protect backed-up file contents from being read by Cloudless, storage providers, or someone who only gets access to encrypted backup objects. It does not protect files while they are open on your unlocked device. It does not stop malware from reading local files before they are backed up. It does not protect a weak passphrase from being guessed. It does not bring back encrypted storage objects if an attacker or policy action deletes them and there is no retention.

Cloudless is also not a replacement for every backup habit during beta. If you are testing the product, use real but non-critical data and keep your existing backup strategy until you have completed restore tests and understand the tradeoffs.

Current Limitations

These are the limits users should understand today:

Cloudless cannot recover your backups if you lose required passphrase or recovery material.
Cloudless depends on your device security. If your device is compromised while files are readable locally, encryption after the fact cannot undo that.
Cloudless depends on your storage account remaining available and containing the encrypted backup objects.
Storage providers and Cloudless can still see some operational metadata.
Backup protection depends on version history, retention, and restore testing. A backup you have never restored from is still only an assumption.
During beta, Cloudless should be tested with real but non-critical folders before it is trusted as a primary backup layer.

These limits are not footnotes. They are part of the product model.

A Simple Way To Think About It

Cloudless should know enough to help the app back up and restore your files.

Cloudless should not know enough to read those files.

That is the line we are trying to hold. It is why encryption happens on your device, why the server does not receive your passphrase, why metadata is documented instead of ignored, and why lost passphrases cannot be fixed by support.

If you are evaluating Cloudless, ask the same questions you should ask any backup product:

What is encrypted before upload?
Who holds the keys?
What metadata remains visible?
What happens if I forget my passphrase?
Can I restore a file on a new device?
Have I tested restore myself?

Good backup software should make those answers easy to find.