[cuu508]

> And yes, the connection string is used to create a restricted 'read-only' user for the backup process.

OK, in that case, I think marketing it as "Zero-knowledge" and "end-to-end encryption" is misleading. Oops Backup sees the data, and the client has to trust Oops Backup to handle the data with care.

An example of actual end-to-end encryption would be a cron job doing "pg_dump ... | gpg --encrypt ... | s3cmd put ..." (with some more arguments of course). The database backup is compressed and encrypted on the database host itself, and sent directly to S3.

[kovacivan]

Fair point, and you're technically correct.

"End-to-End" usually implies the encryption happens on the client's infrastructure before it ever touches ours. Since Oops Backup handles the "dump" process via a connection string, we do technically see the data in transit before it is encrypted and moved to storage.

And I should have been more precise. The "Zero-Knowledge" refers to the at-rest storage. Once the backup is encrypted on our end, we don't hold the keys to decrypt it in the storage bucket.

Your pg_dump | gpg | s3 example is exactly what someone should do if they want true E2EE. Oops Backup exists for the indie dev or hobbyist who doesn't want to manage their own backup scripts, GPG keys, and cron jobs, and is willing to trust a managed service with the in-flight transition in exchange for a 2-minute setup.

I'll update the landing page copy to ensure we aren't misrepresenting the architecture. I appreciate the call-out—it’s an important distinction.

[kovacivan]

Wait, you are the Healthchecks.io founder? Big fan of your work!

You’re 100% right on the terminology. The pg_dump | gpg flow is definitely the correct way to achieve true E2EE.

The trade-off I made with Oops Backup was purely about eliminating the agent or script management. For many of the indie devs I'm targeting, setting up and maintaining that cron job/script is the hurdle that prevents them from having backups at all.

By handling the connection string on our end, we provide a 2-minute set and forget experience, even though it means we have access in-flight before the data is encrypted at rest.

Honestly, I built this because I was tired of managing custom backup scripts for my own side projects and just wanted a easy safety net.

I’m updating the site to remove the 'End-to-End' claim. I definitely don't want to mislead anyone on the architecture. It’s 'Zero-Knowledge' for the stored data only.

Thanks for the catch and for keeping the bar high.