Ente or Immich for self-hosted photos?

Run Ente if you do not trust the place your photos are stored, and Immich if you do. That is the deciding axis, and everything else follows from it. Ente encrypts each photo on the phone before upload, so its server and the bucket behind it hold only ciphertext, and face recognition and search have to run on your own devices. Immich stores readable originals in a directory and does its machine learning on the server, so the server has to be a machine you control.

What the server can and cannot see#

Ente's own comparison page puts it in one line: photos are end-to-end encrypted on your device before upload, and Ente does not have the keys required to decrypt them. That is a vendor claim, but the architecture page explains the mechanism, and it holds up. Each file gets its own key. File keys are encrypted with the key of the album they belong to. Album keys are encrypted with a master key generated at signup, and the master key is stored on the server only after being encrypted with a key derived from your password through Argon2id. Album metadata such as names and folder paths is encrypted too.

Ente says the self-hosted server, called museum, keeps that model. Self-hosting means you run the machine that stores things you still cannot read without a client and a password.

Immich makes no such claim, and Ente's page says so accurately: Immich does not use end-to-end encryption for the photo library, and photos are stored on infrastructure you control. Anyone with access to the disk, the backup or the host can open them. On a box in your house that is a feature. On a rented VPS it is a trust decision you have made without noticing.

What each one asks of the server#

Ente describes museum as a lightweight Go binary that suits older hardware and low-end embedded devices, because most of the work happens on the clients. That is also where the cost went.

Immich's figures come from the opposite design: the immich-machine-learning container keeps its models resident, which is most of the 6 GB. Its Postgres window is narrow: Immich documents Postgres >= 14, < 20, VectorChord >= 0.3, < 2.0 and pgvector >= 0.7, < 0.9, and the server refuses to start if VectorChord is out of range. pgvecto.rs support ended at 3.0. If you run Immich's bundled Postgres image you never touch this; if you point it at a shared database server, this is the line that fails first.

Where the machine learning runs, and what that means for you#

Ente's machine learning page says face recognition and Magic Search run on your device, and that photos and ML data are never sent to Ente's servers. The mobile apps and the desktop apps for Mac, Windows and Linux index. The web app does not offer these features at all. Indexes are encrypted and synced, so one device can do the work for all of them, and for a large library Ente suggests enabling machine learning on the desktop app first because it indexes faster than a phone.

So with Immich the server does the indexing and the phone only uploads. With Ente, plan on a desktop left awake with the app open; a household with only phones has nowhere fast to index a decade of photos.

Immich's model is simpler to reason about: one server, one queue, one place to watch, and the RAM bill that Immich vs PhotoPrism spends so long on.

Object storage is the part people underestimate#

Ente stores photos, thumbnails and videos as objects in S3-compatible storage, and the quickstart bundles MinIO for that. Two details from Ente's object storage page catch people out. First, museum embeds the bucket endpoint into pre-signed URLs, so the phone talks to the bucket directly; the default localhost:3200 works on the server and nowhere else, and you must change it to a LAN address or a domain before any other device can upload. Second, the bucket names are fixed: b2-eu-cen for primary, wasabi-eu-central-2-v3 for secondary and scw-eu-fr-v3 for cold storage, whatever provider you use.

MinIO's community edition was archived in April 2026, as MinIO vs Garage explains. For a long-lived install, point museum at a maintained S3 store such as Garage or a hosted bucket. Because objects are encrypted before they leave the phone, a hosted bucket is a much smaller trust decision here than it would be for Immich.

The consequence: what you hold when the software is gone#

Ente's backup page lists what you need to decrypt anything: the encrypted file data from object storage, the file and collection keys from the Postgres database, and your master key, which comes from your password. All three. It names the common mistake: replicating the object storage carefully and neglecting the database, without which the encrypted data will not be usable. Museum's own museum.yaml and credentials.yaml belong in the backup too. And on the account side, the architecture page says that if both the password and the recovery key are lost, recovery is impossible: there is no backdoor.

So if Ente's keys or the software are lost, the files in the bucket are unreadable. A full disk of objects is not a photo library.

Immich's failure mode is gentler. Its backup documentation says originals live under UPLOAD_LOCATION, in upload/ by default or library/<userID> with the storage template on, as original, unmodified files. Thumbnails and encoded video are regenerable. If Immich is gone, the database is corrupt, or you simply stop wanting it, you still have a folder of JPEG, HEIC and video files that any viewer opens. You lose albums, faces and sharing, which live only in Postgres. You do not lose the photos.

Ente's own answer to its failure mode is sensible: for beginners the backup page recommends keeping a plaintext backup of your photos, exported through the CLI or the desktop app. With a scheduled plaintext export to a separate disk, Ente is as recoverable as Immich, at the cost of storing the library twice.

The two answers that circulate#

One camp says Ente is the private choice, so it is better. The other says Immich is already self-hosted, so it is already private and encryption adds nothing. Each is right about one machine.

If the server is a box in your house, on a disk you own, backed up to another disk you own, the second camp is right. End-to-end encryption protects you from the operator of the server, and you are the operator.

If the server is a rented VPS, or the storage is someone else's bucket, the first camp is right. Immich on a VPS means the provider's staff, their snapshots and anyone who compromises the host can read every photo. Ente in the same place exposes ciphertext.

Which one for your situation#

Where this answer stops applying#

This page compares self-hosted Ente with self-hosted Immich. It does not cover Ente's paid hosted service, where storage is included in the plan and Ente says it keeps three copies across three cloud providers in the EU. That is a different decision: hosted end-to-end encrypted storage against running your own server, which is closer to Replace Google Photos than to this page.

It also does not make a disk-encrypted Immich equivalent to Ente. Full-disk encryption protects a powered-off drive. It does nothing against someone with access to the running host, which is the threat end-to-end encryption exists for.

What to do next#

Decide where the server lives first. If it is yours and at home, install Immich, give it 8 GB and an SSD for Postgres, and read Backups that actually restore before the first import. If it is rented, install Ente, move its object storage off the bundled MinIO, and before you upload anything that matters, back up the Postgres volume, museum.yaml and credentials.yaml, write down the recovery key, and schedule a plaintext export. Then do a full restore into a scratch install, because a backup you have not restored is not a backup. Backing up a running database covers why the database dump matters more than the snapshot, and the rest of the category is in Photos and files.