The rug pull
I wrote TinyCld because Google, in their infinite wisdom, decided to
cancel my twenty-year-old free Google Apps suite for "commercial usage."
Which, to be fair, it totally was - and I obviously can't shouldn't complain
about twenty-plus years of free service.
But still. Those weren't the terms I signed up under, and nothing is more irritating than a good old-fashioned rug pull. Your mail, your calendar, two decades of contacts and files: all sitting on someone else's platform, on someone else's terms, subject to change whenever it suits them. So I asked the question every engineer eventually asks: how hard could it be, right?
What TinyCld is
On the surface it's the suite you already know: mail, calendar, contacts, drive, text, and calc, running on hardware you control. It speaks the standard internet protocols so all your existing native clients keep working and nothing locks you in. Your data lives where you put it, and the terms don't change out from under you.
But the part I'm more excited about is underneath. TinyCld is also a platform, with all the batteries you'd need to write realtime web and native apps already wired together: auth, organizations, a synced database, realtime queries, file storage, a native shell. The same foundation that runs mail and calendar is the one you'd build your own app on.
What I'm really chasing
Six apps in the box is where it starts, not where it ends. Under the hood, every feature is just a package: a self-contained folder that registers its own screens, data, background hooks, settings, and help. The suite you run is whatever set of packages you installed. Want only mail and contacts? It boots as a lean shell with those two and nothing else. Want a CRM, a habit tracker, an invoicing tool, a wiki? Drop the package in and it's there.
What I want is for that set of packages to keep growing, mostly written by people who aren't me. Nothing privileges the ones I ship, so a package you write is every bit as native as the built-in apps. It gets the same database, sync, auth, and native app the rest of the suite runs on. Packages can even notice each other at runtime without a hard dependency, so the calendar can show a package's events and drive can preview its files, and none of it breaks when that package isn't installed.
I want self-hosting to stop being the option you settle for. You get the suite, then you bolt on exactly the tools your team needs, without waiting on a vendor's roadmap or paying per seat for features you'll never open. A package takes about ten minutes to scaffold, so "I wish it did X" turns into "now it does X" in an afternoon.
I've got a long list of add-ons I want to build, and I'd love yours. The best thing that can happen to this project right now isn't more code from me. It's other people building the packages they wish existed.
About the AI
Yes, I used AI to write a lot of this. (Really, around 200k lines of code from one author is a pretty good tell.) Some people will hate on that, and that's fine; I get it. But I read every commit, and a lot of what's in there is me fighting the thing into shape - fixing its bugs, pulling features back when it got carried away. I drove it. I didn't walk away and let it run. Turns out 25+ years managing software projects does have a lot of value when it comes to managing little AI agents as well.
There's a bet behind that, too. I figure most package authors will be reaching for AI agents the same way I did, so I've tried to make TinyCld easy for them to work with. That's why we publish an llms.txt and keep a test that one-shots a full TODO app. If an agent can build a working package in one pass, so can you.
Standing on the shoulders of giants
People have asked about security, and they're right to. It's the first thing you should ask of anything you'd hand your mail and your files to. My answer to that is that most of what protects your data, I didn't write, and I'm very thankful for that.
The parts where a bug would be the worst: database, login, file storage, the IMAP/SMTP and CalDAV/CardDAV stacks, HTML sanitization, password hashing, is not code I dreamed up late at night. They're established open-source libraries with far more people relying on them, and breaking them, than TinyCld will ever have. PocketBase handles auth, data, and realtime. SQLite, which is about as well-tested as software gets, stores every byte. The mail and calendar protocols run on Emersion's Go libraries, and untrusted HTML gets scrubbed by bluemonday before it ever hits the screen.
Same logic for email itself: don't run your own mail server. TinyCld can handle the raw SMTP if you insist, but I'd talk you out of it. Email is its own special misery, in both directions - SPF, DKIM, DMARC, reverse DNS, IP reputation, and the quiet day a big provider starts dropping your messages in spam for reasons nobody will explain. Point TinyCld at Postmark (or whatever email service you already trust) and let the people who do this for a living handle it. Your data still lives on your box; only the delivery is theirs.
Standing on those is also the only reason one person could put a whole suite together at all. It means the floor under your data is the same one a lot of other projects already trust, not something you have to take my word for. The full list is on the credits page.
Where it's at
The stack is Expo (React Native and web) on the frontend, PocketBase and Go on the back. I run TinyCld day to day at my own small company, and it hasn't really been used anywhere else yet. So it's early. That's also the best time to get in and push it somewhere.
I'm very interested in any feedback you can offer - and if you've got an idea for a package, I want to hear it.