TinyCld packages mail, calendar, contacts, file storage, a collaborative .docx editor, and spreadsheets into a single AGPL-3.0-licensed Docker container, with a native iOS client already on the App Store. The pitch is direct: one container, one codebase, everything you need to stop paying Google for Workspace. Whether that pitch survives contact with reality depends less on whether the spreadsheet renders correctly and more on whether self-hosted IMAP can get mail delivered past Gmail’s spam filters in 2026.
What ships in the box
According to the TinyCld GitHub organization, the suite covers six primitives: mail (IMAP+SMTP), calendar (CalDAV), contacts (CardDAV), file drive (WebDAV), a CRDT-based collaborative .docx editor, and spreadsheets with pivot table support. The document editor and spreadsheet are both labeled beta. The whole stack runs in one Docker container. No microservices, no message bus, no external auth provider. Every protocol and service lives inside TinyCld itself.
The architecture is opinionated in a way that will feel familiar to anyone who has deployed a single-binary Go service. The server is Go backed by PocketBase, and the client stack is Expo (React Native) with Expo Router, TypeScript, Tailwind v4, and TanStack DB for reactive data binding. The stated goal is to keep the operational surface small: one process, one database, one container to update.
Each application (mail, calendar, drive, contacts, docs, sheets) is a separate git repo under the @tinycld npm workspace scope. They share an @tinycld/app shell and an @tinycld/core runtime. A @tinycld/bootstrap scaffolder generates new packages with screens, database collections, migrations, tests, and a Go server stub pre-wired, which suggests TinyCld is positioning itself as both a suite and a framework for extending it.
The iOS client: privacy by default
The iOS app is 43.3 MB, requires iOS 15.1 or later, and is listed as free under the AGPL. The seller is Nathan Stitt. There are no ratings on the App Store listing as of the research date, which points to very early adoption.
The privacy pitch is concrete rather than aspirational. The app blocks tracking pixels in email and proxies external images through the server so senders cannot see the recipient’s IP address or infer open timestamps. The project states that no analytics, no tracking, and no data mining occur, and that when self-hosted nothing leaves your server. For a privacy-focused audience, this is the right set of promises. For a skeptical one, the question is whether the implementation holds up under audit, which the AGPL license at least permits.
The email problem
This is where the optimism hits the wall.
Running your own IMAP and SMTP server in 2026 is not a configuration problem. It is a deliverability problem. Gmail, Outlook, and Yahoo collectively handle the majority of inbound mail for most users’ recipients, and their spam filtering has become aggressively hostile to small mail operators. SPF, DKIM, and DMARC are table stakes, and even correctly configured domains with clean IP reputations routinely land in spam folders at the major providers. The DMARC landscape has tightened further since Google and Yahoo enforced new sender requirements in early 2024, requiring SPF or DKIM alignment for bulk senders and one-click unsubscribe headers.
The TinyCld documentation splits into two tracks, Operate and Build. The Operate track covers server setup, domain configuration, user management, and backups. But the research brief contains no information about SPF, DKIM, or DMARC configuration guidance, no mention of email deliverability testing, and no benchmarks comparing outbound delivery rates against hosted providers.
This is not a TinyCld-specific problem. It is the same problem that sinks every self-hosted Workspace alternative. Nextcloud, CryptPad, and Collabora all avoid it by not bundling a mail server at all, which is the architecturally honest choice but leaves users cobbling together separate solutions for the one service that matters most.
Integration versus modularity
Nextcloud’s approach is a platform with an app ecosystem: install the core, then add mail, calendar, contacts, and office plugins as needed. CryptPad focuses on end-to-end encrypted collaborative editing without trying to replace mail. Collabora provides a LibreOffice-based online editor that integrates into Nextcloud, ownCloud, or standalone deployments.
TinyCld takes the opposite path. Everything is bundled, built by the same team, and wired together in a single codebase. The Google Takeout import tool (@tinycld/google-takeout-import) offers one-shot migration from Google Workspace, which confirms the target user: someone leaving Google who wants one command to replace the whole stack.
The tradeoff is straightforward. A bundled suite gives you tighter integration between components and a single upgrade path. It also gives you a single point of failure and no escape hatch if the mail server turns out to be unreliable. Nextcloud’s modular approach lets you swap out a broken mail plugin for a third-party alternative without touching your file storage. TinyCld’s monorepo architecture does not offer that flexibility, at least not without forking.
The platform play
Beyond the suite itself, TinyCld exposes a set of platform primitives that suggest the project has ambitions beyond replacing Google Workspace for individual users. According to the GitHub README, the platform layer provides authentication with OAuth-ready sessions, multi-organization support with per-org roles, live reactive queries via TanStack DB on PocketBase, optimistic mutations with rollback, transactional email, in-app notifications, native push through Expo Push, append-only audit logging, and light/dark theming. All of this ships before a developer writes their first screen.
The documentation backs this up with the Build track, which covers package development, workspace layout, and the scaffolding CLI. Packages are assembled with npx @tinycld/bootstrap --assemble-only --with <pkg> and new ones are scaffolded with --new <slug>. This is a platform-as-framework pitch: TinyCld is not just a productivity suite but a foundation for building self-hosted applications that inherit its auth, data, and notification infrastructure.
Whether that pitch lands depends on whether enough developers adopt the @tinycld package convention to build an ecosystem, or whether the framework remains a one-team project. The npm workspace architecture makes extension technically straightforward. The social dynamics of ecosystem building are harder to scaffold.
What to test before committing
For any self-hoster evaluating TinyCld, the feature checklist is less important than three operational tests.
First, email deliverability. Send test messages from your TinyCld instance to Gmail, Outlook, and Yahoo addresses on a domain you control. Check spam folders. Run the messages through a deliverability diagnostic like mail-tester.com. If they land in spam, the rest of the suite does not matter.
Second, mobile sync reliability. The iOS app uses CalDAV, CardDAV, and WebDAV, all open standards with proven client libraries. Test calendar and contact sync over flaky cellular connections, not just on a clean Wi-Fi network. Sync edge cases are where open-standards implementations tend to diverge from the polished integrations Google and Apple ship.
Third, upgrade path. TinyCld is a young project with no available information about contributor count, funding, or release cadence. Single-container deployments are easy to start and easy to abandon if the project goes dormant. Before putting institutional data into it, verify that backups and exports work without the container running, so you are not locked into a specific version of PocketBase if the project stalls.
TinyCld’s architectural choices are defensible. A single-container, single-codebase productivity suite with a native mobile client and open standards throughout is a coherent response to Google Workspace. The coherent response is not the same as a working one. The project’s value will be determined by the part it says the least about: whether the mail gets delivered.
Frequently Asked Questions
Can I deploy just TinyCld’s calendar and contacts without the mail server?
The npx @tinycld/bootstrap --assemble-only --with <pkg> flag lets operators select specific packages during assembly, skipping components they do not want. Each @tinycld/* module is a separately-installable sibling repo under the npm workspace scope, so you could run calendar and contacts over CalDAV/CardDAV while routing mail through a hosted provider like Fastmail or Migadu, avoiding the self-hosted deliverability problem entirely.
How does writing a TinyCld extension differ from building a Nextcloud app?
Nextcloud apps are PHP plugins that hook into the core’s event and template system. TinyCld’s --new <slug> scaffolder generates a full package with its own database collections, migrations, tests, and a Go server stub, so extensions carry server-side logic rather than just frontend code. The tradeoff is that contributors need both Go and TypeScript proficiency, narrowing the pool compared to PHP’s wider install base.
What AGPL obligations apply if I customize TinyCld for my organization?
AGPL-3.0’s network-use clause requires that anyone who accesses your modified instance over a network, including employees through the browser or iOS app, must be offered the complete source code including your customizations. This triggers even if you never distribute the software externally. Organizations adding proprietary @tinycld packages or modifying the Go server would need to publish that source to all users of the instance, which may conflict with internal-tool confidentiality policies.
What is the data escape hatch if TinyCld development stalls?
PocketBase stores its data in SQLite, so calendar, contacts, and file metadata live in a standard database file you can query and export without the container running. CalDAV and CardDAV data migrates to any compatible server (Baikal, DAViCal, Radicale) using standard export tools. The harder extraction path is the CRDT-based collaborative documents, whose sync format is specific to TinyCld’s implementation and may lack a clean migration path to another editor if the project stops receiving updates.
Does the single-container model compound deliverability risk for multi-tenant deployments?
TinyCld’s platform layer supports multi-organization deployments with per-org roles and append-only audit logging. But the single-container architecture means all tenants share one outbound IP for SMTP. If any tenant triggers spam complaints, the shared IP reputation degrades for every organization on that instance. Dedicated mail providers like Postmark or Mailgun address this with IP pooling and per-tenant reputation isolation, capabilities a single Go process with PocketBase does not replicate.