One hour is short. One hour is on purpose. Here's exactly how the deletion job works, why it isn't optional, and what we encrypt in the meantime.
The single most important promise Arawa PDF makes is the one-hour file-deletion policy. Every uploaded document, and every output we generate from it, is permanently removed from our infrastructure within one hour of processing. No backup keeps a copy. No "keep my files" toggle overrides it. Even Premium accounts get the same retention.
This post explains exactly how that works, and why we made the call.
Every file lives in our object store with an expiry timestamp attached at upload time. A background sweeper runs every few minutes, asking the storage layer for any object whose expiry has passed. It deletes them, and writes a single log line confirming the count. The sweeper is the same code path for everyone, no matter how you use Arawa PDF.
We don't queue files for "soft delete" first. Deletion is permanent on the first pass. The object's encryption key is also rotated out of memory, so even a stale reference can't recover the content.
Database entries that pointed to those files (job metadata, output URLs) are dropped on the same schedule. The only thing that survives is anonymised audit data — counts, durations, error categories — which we use to keep the system healthy.
While a file is on our servers (the up-to-one-hour window), three things protect it:
• Transport: every upload and download is over HTTPS with modern TLS. We do not accept plaintext HTTP at any layer.
• At-rest encryption: our object store encrypts objects with server-side keys. A stolen disk image cannot be read without the key infrastructure.
• Access control: the file's URL is signed and short-lived. Even if a download link leaks, it stops working quickly. Workers fetch by internal reference, not via the public URL.
These are table stakes, not differentiators. The differentiator is that the entire window is one hour, not days or weeks.
A few tools claim "zero-retention" by processing everything client-side. That's great when it works — and Arawa PDF's editor, signature placement, and PDF comparison tools do run client-side for exactly this reason. But the heavy lifting (OCR, repair, format conversions, AI summarisation, anything that needs Ghostscript or LibreOffice or Tesseract) can't realistically happen in a browser tab.
The one-hour window exists to give those server-side tools room to finish, plus a reasonable buffer so that a flaky network on your end (or a tab closed too early) doesn't ruin a 90-second job. We considered 30 minutes — too tight for big files on slow connections. We considered 24 hours — much longer than necessary. One hour covers 99% of real-world jobs with margin to spare.
Every "keep my files" feature we've ever seen turns into a vulnerability. Forgotten files pile up. Engineers add code paths they don't fully understand. Eventually someone misconfigures a retention window and now sensitive documents sit indefinitely on infrastructure no one is auditing.
We'd rather not have that escape valve. If you need a document long-term, you're meant to download it before one hour elapse and store it where you'd store any other private file. That's a slightly inconvenient design choice. It is also a deliberately limiting one — limits are how you make sure nothing slips.
If you upload a contract, take 90 minutes to sign it, and come back: it's still there. If you upload a stack of scans, OCR them, download the output, and come back six hours later: the originals and the output are both gone.
If you accidentally delete the local copy of your file and the one-hour window has lapsed, we can't recover it. There is no "contact support to restore" path. There's nothing to restore from.
That's the trade-off. We think it's the right one.