Unclouding, One Tool at a Time
There’s a specific moment that keeps repeating: I’m using some cloud service to do something genuinely simple — send a file, sync a folder, stash a secret — and I notice I’m trusting a third party with data that never needed to leave my own machines in the first place.
Not because the service is untrustworthy. Most of them are fine. But “fine” is doing a lot of work in that sentence — fine until a pricing change, fine until an outage, fine until a ToS update quietly changes what “your data” means. The convenience is real. So is the dependency.
The fix isn’t some grand migration off The Cloud as an ideology. It’s smaller and more specific than that: for each thing I actually needed, build the smallest tool that does that one thing, running on hardware I control.
Three shapes of the same problem
wisp started as “I need to send someone a file without it living in an inbox forever.” The commercial answer is Zipline, WeTransfer, a dozen file-drop services — all of them fine, all of them a third party in the loop for something that’s really just two people and a file. wisp is async, encrypted, single-retrieval — upload, get a link, whoever opens it gets the file once, and then it’s gone. No account needed on either end.
flit started from the opposite constraint: sometimes the two devices are both mine, both already on the same network or reachable through my own anchor, and there’s no reason to route the file through anyone’s server at all. flit is P2P — a sender and receiver find each other over a lightweight signaling server I run, then talk directly, encrypted end-to-end. The signaling server never sees the file, only enough to introduce two peers. Most recently it grew watch mode — point it at a folder, and anything dropped in gets pushed automatically to a trusted device, no manual send per file. The homelab-backup use case a cloud sync tool would normally own.
keep is the one that took the longest to admit I needed. Every self-hosted project accumulates a .env file, and every .env file was living on my machines by being hand-copied — no rotation story, no access log, no record of which box has which secret. The commercial answer is Vault or Doppler, both of which are correct tools aimed at a much bigger problem than “I have twelve side projects and a homelab.” keep adapts the same multi-recipient encryption pattern age/sops use for static files into a small always-on service: push a secret once, every authorized machine can pull it decrypted, the server itself never holds a key that would let it read anything.
The actual pattern
None of these are trying to be a smaller AWS. Each one exists because a specific cloud convenience turned out to have a specific, buildable, self-hosted shape once I looked closely enough at what it was actually doing under the hood. A file drop is upload-once/download-once. A folder sync between two known devices doesn’t need a relay that can read the contents. A secrets store needs encryption and an access log, not a policy engine.
The interesting part isn’t “self-hosting is better” — sometimes it plainly isn’t, and the convenient cloud version stays the right call. The interesting part is how often the self-hosted version turns out to be a weekend of focused work rather than the sprawling project it sounds like from the outside, once the scope is kept honest and narrow.
Three tools in, the pattern holds: find the one thing being paid for in trust rather than money, and see how small the actual problem is once you strip the platform away.