Ente: end-to-end encrypted photos, auth and locker in one monorepo

What Ente is actually for, and who ends up using it

Ente is a service and a codebase for storing data in the cloud without trusting the provider. The README states that the platform is fully open source and end-to-end encrypted, and that three apps have been built on top of it: Ente Photos, Ente Locker and Ente Auth. The monorepo contains the client apps for iOS, Android, F-Droid, Web, Linux, macOS and Windows, plus the server that powers them.

The audience splits cleanly. One group wants a photo library that is not Apple Photos or Google Photos, with the encryption handled before upload. Another group wants a 2FA app that is not the deprecated Authy, which is the framing the README itself uses for Ente Auth. A third, smaller group wants to run the server. The README addresses the first two directly and the third only in passing, with one line: you can clone the repository and choose to self-host. That sentence is the entire self-hosting pitch in the README, and it is worth noticing how much work it leaves undone.

One platform, three apps, and a shared encryption layer

The architecture implied by the repository layout is a shared platform with product apps on top. The top-level entries include server/, web/, mobile/, desktop/, cli/, rust/, infra/, architecture/ and docs/. The presence of an architecture/ directory and a separate rust/ directory suggests the cryptographic core is not written in Dart, the primary language of the repository, but in Rust and consumed by the Dart clients.

That split matters for anyone evaluating the security story. The README states that the source code and cryptography have been externally audited by Cure53, Symbolic Software and Fallible. It does not break down which components each firm examined, so a reader cannot tell from the README alone whether the audit covered the Rust crypto layer, the server, or only the client apps. That is a gap between what the README claims and what it documents.

On the product side, Ente Photos is described as having 3x data replication, face detection, semantic search, private sharing, collaborative albums, family plans, background uploads and import and export. Face detection and semantic search are the interesting cases for an end-to-end encrypted system, because both normally require the server to see plaintext. The README does not explain how they are reconciled with end-to-end encryption, and that omission is the single most important thing a technically minded reader would want resolved before trusting the design.

Installing Ente Photos on a phone and getting a first upload through

For most readers the install path is an app store, not a build. The README lists iOS, Google Play, F-Droid and Obtainium links for Ente Photos, and a desktop download link. The F-Droid package identifier is io.ente.photos.fdroid, and the Obtainium entry points at the GitHub repository with the app name Ente Photos. There is no command-line install in the README for the mobile apps, because there is nothing to install from a terminal.

If you are on Android and want the F-Droid build rather than the Play build, the package name is the thing to check, since the two are distinct identifiers:

# F-Droid build of Ente Photos
io.ente.photos.fdroid

For the web client, the README points at photos.ente.com. The desktop build is linked from ente.com/download/desktop. Once signed in, the README states that Ente Photos offers 10GB of free storage, and that the product is otherwise a paid service. Background uploads are listed as a feature, which is what you would enable on a phone to get the library populated without opening the app.

There is a repository-local path too. A cli/ directory sits at the top level, which implies a command-line client exists in the tree even though the README does not document it. If you want to script uploads or drive Ente from a terminal, that directory is where to look, and the README will not help you.

For Ente Auth the README gives the same shape of links: iOS, Google Play, F-Droid, an Obtainium redirect and a release query for tags matching auth-v4, plus auth.ente.com. The README states that Ente Auth is free and will remain free. Ente Locker is listed for iOS and Android only, with a note that it is free for up to 100 items and up to 1000 items for Ente Photos subscribers.

Where Ente is the wrong tool

Self-hosting is the obvious weak point. The README says you can clone the repository and choose to self-host, and stops there. It does not document a deployment procedure, environment variables, ports, database requirements or an upgrade path. The server/ and infra/ directories exist, and the .dockerignore at the top level hints that container builds are part of the workflow, but the README does not connect those pieces. Anyone planning to run Ente for an organisation should treat the README as a signpost, not a manual, and budget time to read the infrastructure code directly.

Ente Locker is also narrower than it first appears. The README lists it for iOS and Android only, with no web or desktop client mentioned, and caps the free tier at 100 items. If your use case is a cross-platform secrets store that you open on a laptop, the README does not describe that.

The encryption model is a second boundary. End-to-end encryption means the provider cannot recover your data, and by extension neither can a support process. The README does not describe account recovery, key escrow or what happens when a user loses their credentials. That is a property of the design rather than a defect, but it changes who the product suits: it is a poor fit for anyone who needs an administrator to be able to restore access to a locked account.

How Ente differs from Immich and from Bitwarden

The nearest comparison for Ente Photos is Immich, which is also a self-hostable photo library. The difference in approach is where encryption lives. Ente is built around end-to-end encryption as the platform's premise, with the README stating that the cryptography has been externally audited. Immich, by contrast, is organised around a self-hosted server that you operate yourself, which puts the trust boundary at your own infrastructure rather than at a cryptographic layer. If you already run a home server and want the server to hold plaintext so that it can index and process freely, Immich's model is the more natural fit. If you want the provider, whoever it is, to be unable to read your library, Ente's model is the one the README describes.

For Ente Auth the comparison is with any TOTP app that syncs, including Bitwarden's authenticator and the built-in password managers in major browsers. The README's own framing is that Ente Auth exists because there was no open source end-to-end encrypted authenticator app, and that it is a 2FA alternative to the deprecated Authy. The relevant difference is that Ente Auth is a standalone product with its own clients and release tags, not a feature bolted onto a password vault. Whether that separation is an advantage depends on whether you want your second factor stored in the same place as your passwords. Storing both in one vault is convenient and concentrates risk; keeping them apart is the reason to run a separate authenticator at all.

Licence, releases and what maintenance costs you

Ente is licensed under AGPL-3.0. For a self-hoster running the server privately, that is generally unremarkable. For anyone planning to offer Ente as a network service to others, the AGPL's source-availability condition is the part to read carefully, because it reaches users who interact with a modified version over a network. This is not legal advice, and the LICENSE file at the repository root is the authoritative text.

The release cadence visible in the repository is active. photos-v1.3.61 and locker-v1.0.8 were both tagged on 2026-08-11, and photos-v1.3.60 the day before, on 2026-08-10. The last push to the default branch was on 2026-08-11. The repository is not archived. Frequent point releases on the Photos app mean that if you build from source rather than installing from a store, you are tracking a moving target, and the README does not describe a supported upgrade procedure for a self-hosted server. That is the real maintenance cost: not the licence fee, but the absence of documented operational guidance in the README, which pushes the burden onto the reader to reconstruct from the server and infra directories.

On the hosted side the cost structure is stated plainly. Ente Photos is a paid service with 10GB free. Ente Auth is free. Ente Locker is free to 100 items, or 1000 with a Photos subscription. Those are product facts from the README, not commitments about future pricing.

Editorial conclusion

Adopt Ente if you want an end-to-end encrypted photo library or 2FA app whose clients and server are both in one AGPL-3.0 repository, and you are willing to read the server and infra directories yourself. Do not adopt it expecting the README to walk you through a self-hosted deployment, and do not treat the free 10GB Photos tier as a substitute for a backup you control. Before committing, verify three things against the current tree: that the client apps on your platform of choice are the ones you need, that the server directory contains a deployment path you can operate, and that the AGPL-3.0 obligations are acceptable for how you intend to use the code.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes