Tuta (tutao/tutanota): the GPL-3.0 client behind an end-to-end encrypted mailbox

What the tutao/tutanota repository actually contains

Tuta Mail is an email service with end-to-end encryption for mail, contacts and calendar entries, and the README describes it as built for all your devices. The repository is the client side of that service. Top-level entries include src/, app-android/, app-ios/, desktop.js, webapp.js, android.js, libs/, test/, ipc-schema/ and tuta-sdk/. That layout tells you the scope: one TypeScript codebase compiled into several targets, plus a Rust workspace for shared cryptographic and SDK code. The README does not describe a self-hostable server, and the homepage it points to is the hosted product. If your goal is to run an encrypted mail server of your own, this is not that project. If your goal is to understand or change how the client encrypts, syncs and renders, this is exactly it. The licence is GPL-3.0, declared both in the README's repository metadata and in package.json, where the name field is tutanota and the version tracks the release tag, currently 360.260921.0.

One client, four targets, and a Rust core underneath

The build is not a single bundle. package.json exposes separate type-check projects for each app: mail:types runs tsc against tsconfig.json, calendar:types against tsconfig-calendar-app.json, drive:types against tsconfig-drive-app.json. Android and iOS have their own entry points, android.js and app-ios/, and the desktop client is started through start-desktop.sh, which the start script invokes. The UI layer is Mithril, listed among the repository topics. Cross-process calls are generated rather than hand-written: the generate-ipc script compiles buildSrc/licc and then runs node build/licc/cli.js ipc-schema, so the IPC surface between the web layer and the native shells is derived from ipc-schema/ and then reformatted by Prettier. Underneath sits a Cargo workspace whose members are tuta-sdk/rust/sdk, src/app-kit/mimimi, tuta-sdk/rust/uniffi-bindgen, tuta-sdk/rust/crypto-primitives and tuta-sdk/rust/util. The uniffi entry exists because, as the Cargo.toml comment notes, uniffi-bindgen has no CLI of its own yet, so the project wraps it as a separate crate. default-members is empty on purpose: the comment states that in most cases you do not want to build everything, so almost any cargo invocation needs --all or --package. That is a deliberate choice, and it means a naive cargo build in the repository root produces nothing useful.

Installing and building the Tuta client on Ubuntu or any Node machine

The README does not inline install steps. It redirects to doc/BUILDING.md for building and doc/HACKING.md for development, and those two files are the authoritative source. What can be confirmed from package.json is the shape of the workflow. Dependencies are installed with npm, and the preinstall and postinstall hooks run node buildSrc/preinstall.js and node buildSrc/postinstall.js automatically, so a plain install already does project-specific setup.

npm install

After that, the desktop client is the entry point the package exposes directly. The start script runs ./start-desktop.sh, and the repository also ships start-desktop.sh at the top level.

npm start

The README's download section points at the web client at app.tuta.com, the iOS App Store listing, the Play Store and F-Droid listings under de.tutao.tutanota, and a desktop download page. Building from source is for people who want to change the client, not for people who just want a mailbox.

Before sending a change, the project's own gate is a single command, which runs Prettier in check mode and ESLint over the tree.

npm run check

Expect that to fail on a fresh checkout if your editor reformatted anything, because style:check runs prettier -c across every .ts, .js, .json and .json5 file with a cache in cache/prettier. On the Rust side, note that rust-version is pinned to 1.84.0 in the workspace manifest, and the edition is 2021. A toolchain older than that will not build tuta-sdk.

Where the client model breaks down for outside contributors

The README contains a contribution policy that rules out a large class of modern workflow. It states that the project does not accept contributions or bug reports produced, in part or in full, with assistance of large language models, and that maintainers will close issues or delete comments without further explanation if they suspect any part is generated. It then adds that incomplete or automatically translated reports are still welcomed over LLM-assisted ones. Whatever you think of that rule, it changes the practical cost of participation: you cannot draft an issue with a coding assistant and file it. The same README says feature requests should go through Reddit or support mail rather than the GitHub issue tracker, so the tracker is not the front door it looks like.

The second limitation is structural. The encryption guarantees live in a system where the server is operated by Tuta, and the server code is not part of this repository. Reading the client tells you what the client does, not what the service does with metadata it can see. Anyone evaluating the security properties from this repository alone is looking at half the picture, and the README does not claim otherwise.

The third is the build surface. Five Cargo workspace members, three TypeScript app configs, generated IPC code, XcodeGen specs for iOS, and a preinstall hook mean the barrier to a first successful build is real. A single-file patch to a Mithril component is easy to reason about; changing anything that crosses the IPC schema means regenerating bindings and re-running the style pass.

Tutanota versus Proton Mail: two different open-source boundaries

The most common comparison people search for is Tutanota against ProtonMail, and the repositories differ in a way that matters more than feature lists. Proton publishes server-side components alongside its clients, so a reader can inspect how mail is stored and what the backend does. Tuta's repository is the client, the Rust SDK and the crypto primitives; the service that holds your mailbox is operated by the company. That is a real difference in what an outside reviewer can verify. It also changes what you can do: with the Proton stack there is a path, however involved, toward running your own instance; with tutao/tutanota the README points at the hosted product and its app store listings, and there is no self-hosting story in the repository documentation. If your requirement is independence from a vendor's operations, this repository does not give it to you. If your requirement is an auditable client with a cryptographic library you can call from Rust, the tuta-sdk workspace is the more interesting half.

Maintenance, release cadence and what GPL-3.0 means here

The last push to the default branch was on 2026-09-21, and the release tags for that same day cover the main client, iOS and desktop builds at version 360.260921.0. Version numbers in package.json and Cargo.toml are kept in lockstep with the tag through buildSrc/bump-version.js, which the bump-version script runs. That is a single-version-number scheme across TypeScript and Rust, and it makes it easy to tell whether a checkout matches a shipped build.

On licensing: the repository declares GPL-3.0 in both README metadata and package.json, and the Rust workspace uses license-file pointing at LICENSE.txt. If you fork the client and distribute binaries, the GPL's source-availability obligations attach to your fork. That is a statement about what the licence text says, not legal advice, and the details of combining GPL client code with app store distribution terms are worth checking with someone qualified. The README does not discuss licensing exceptions or additional terms, so nothing in the published documentation suggests a dual-licence arrangement. There is also a SECURITY.md at the top level for reporting vulnerabilities, which is the correct channel rather than a public issue.

What to verify before you commit to a fork

Start with doc/BUILDING.md and doc/HACKING.md, because the README delegates everything practical to them and the top-level scripts only make sense once you have read those. Then confirm your toolchain: Node is pinned through .nvmrc, and Rust is pinned at 1.84.0 with edition 2021. Run npm run check before opening anything, since the style gate runs Prettier in check mode over the whole tree with a cache directory you will want to keep out of your diffs. For the Rust side, remember that default-members is empty, so you must name a package or pass --all; a bare cargo build is not a smoke test. Finally, read the contribution policy in full before writing an issue, because the rule about generated text is enforced by closing threads rather than by discussion. None of these are reasons to avoid the repository. They are the difference between an afternoon of exploration and a week of fighting the build.

Editorial conclusion

Adopt it if you want to read or modify the client that talks to Tuta's servers, or to reuse the Rust crypto primitives in tuta-sdk; do not adopt it expecting to run your own encrypted mail service, because the server is not in this repository and the README points only at the hosted service. Before committing, read doc/BUILDING.md and doc/HACKING.md, check the contribution policy in the README, which refuses LLM-assisted reports, and confirm which workspace members Cargo.toml declares, since default-members is empty and a bare cargo build does nothing.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. tutao/tutanota on GitHub