A self-hosted, read-only archive vs. more Google storage
A small law firm I work with kept getting the same email from Google: your 100 GB is almost full — upgrade or free up space. They help people win car-accident claims against insurance companies, so their Drive is a wall of big case PDFs — medical records, police reports, scene photos — plus short video clips. Gmail full of years of client correspondence. It only ever grows.
The choice Google offers when you hit the ceiling is a bad one for a small firm: pay for the next tier, every year, forever — or spend a billable afternoon spelunking for files that are safe to delete. One costs money you’ll keep spending; the other costs the most expensive hour they have. Neither is the work they’re in business to do.
The move: cold storage you own, not rent
I offered them a different shape entirely: stop renting room for data you never open, and move the cold half of it somewhere you own.
- Pull everything down. All of Drive and all of Gmail, via Google Takeout.
- Put it on a disk in their own office, served read-only over a subdomain of their own domain —
drive-archive.*for the files,mail-archive.*for the mail. Read-only is not a detail; it’s the whole point. This is a legal record. It has to be browsable and downloadable and impossible to edit or delete by accident — no junior associate ever nukes a five-year-old case file. - Back it up like it matters. The live archive, plus two Takeout copies on USB drives — one kept in the office, one at home. Three copies, two kinds of media, one off-site: the boring old 3-2-1 rule, actually satisfied.
- Verify before you delete. Only after they’d logged into the subdomains and confirmed they could see everything did they clear out the old mail and files from Google — keeping the last year or so live.
The result: the working set stays in Google, where it’s fast and shared and familiar. The long tail — the stuff they need maybe once a month to pull an old exhibit or a two-year-old email thread — lives on their own disk, at their own subdomain, and costs nothing to keep. The “almost full” email stopped. The plan stopped creeping.
Want to build this yourself? I put the whole setup on a one-page checklist — what to keep vs archive, the Takeout export, the read-only file + mail archive, TLS and your own subdomains, the 3-2-1 backups, and the exact tools. Grab the free PDF — one email, no spam.
Building the archive — and the feature the file server couldn’t show
To make tens of thousands of files browsable, you need a real file server. I self-host one. And the moment I opened it, I hit the exact question that started this whole project: which folders are actually big? The tool I’d run for years answers “4 KB” for every directory, no matter what’s inside — the feature request to actually sum a folder’s contents has sat open for years, parked on the reasonable grounds that walking the whole tree on every page load is expensive.
That’s the tax on a tool you don’t control: a sensible “no” is still a permanent “no.” Except this one’s open source — so “no” just means someone forks it. A community fork ships folder sizes out of the box (it keeps a live index, so the total is already computed). Switch to the fork. Should be an afternoon.
The migration nobody warns you about: the passwords don’t come with it
The fork uses its own database, different enough that there’s no import path. Fine — I’ll recreate the handful of staff accounts. Except recreating an account means setting a password, and I don’t know anyone’s password. They aren’t stored; their bcrypt hashes are, and bcrypt is one-way — you cannot read a hash back into the password that made it. The path every guide quietly assumes is: reset everyone and hand out new credentials. At a busy firm, that’s exactly the friction that makes people avoid the new thing.
That's the tax on a tool you don't control: a sensible "no" is still a permanent "no."
The bcrypt way out
Here’s the escape, and it only exists because the data is on my disk in a format I can open: both the old server and the fork hash with bcrypt, and a bcrypt hash is a fixed 60 characters. So I created each user fresh, then wrote their original hash back over the newly generated one — identical length, so it drops into the record cleanly — and on the next login the standard bcrypt check compares the typed password against the original hash and passes. Zero resets. Nobody noticed the server changed under them. That’s a sentence you can only write when you can reach into your own database. The cloud version of it ends in a support macro.
Two traps at the cutover
- The old app was a PWA. After the swap, the first login failed with a 404 — the browser’s cached service worker was still serving the old frontend, posting to a login route that no longer existed. A hard refresh loaded the new app. Every returning user needs that one-time refresh; say so up front.
- The per-user scope that pins a staffer to only their own folders wasn’t a command-line flag — it lives in the user record, so I set it there directly. Fiddly, but possible, because it’s my data.
The point: stop renting space for files you never open
That “you’re almost full” email was never really about storage. It was about who controls the long tail of your data — and how much you’ll pay, indefinitely, to keep it somewhere you don’t. The fix isn’t a bigger plan. It’s deciding what’s working set (keep it in the cloud, where convenient beats cheap) and what’s cold record (put it somewhere you own, where it can’t be deleted and can’t be up-charged). It’s the same managed-vs-self-hosted call every small business makes a dozen times — and the reason “is self-hosting less reliable?” almost never has the scary answer people expect, once the data is cold and read-only.
If your cloud bill grows every year whether or not your business did, some of what you’re paying for is a long tail of files you’ll open twice. Moving that off the meter — onto something you own, backed up properly, read-only so it’s safe — is often cheaper than the next plan tier and entirely yours. Tell me what’s filling up and I’ll give you a straight read on what’s worth keeping in the cloud and what belongs in an archive you control.