Ente Photos

Last reviewed Aug 26, 2026 · 760 words

Ente is the only mainstream self-hostable photo backup where the server cannot read your photos, and that one design choice explains both its Hard difficulty rating and every feature Immich has that Ente does not. Before installing anything, decide whether you want a photo server that is blind by design; if you do, Ente is excellent, and if you don't, you will spend a weekend building something that then refuses to do server-side search.

End-to-end encryption makes the server storage, not brains

Every photo is encrypted on your phone or laptop with keys derived from your password through Argon2 before it is uploaded. The server, a Go service the project calls museum, stores ciphertext and metadata it cannot open. That means face recognition, semantic search and duplicate detection all run on the device, not the server, and a lost password without the recovery key means lost photos with no admin reset possible. It also means a compromised server, a nosy VPS provider or a stolen disk yields nothing. If that trade sounds right, keep reading; if it sounds like a burden, Immich does the same backup job with a server that can see and index everything.

The stack: museum, Postgres, and an S3 endpoint your phone can reach

Self-hosting is three pieces. Museum handles accounts, sync and billing logic on port 8080; PostgreSQL holds metadata; and an S3-compatible object store holds the encrypted files. The official quickstart runs MinIO for the last part and a web app on port 3000, and it gets a working system up in about 10 minutes on a 1 GB box.

The gotcha that earns the Hard rating is how uploads work: clients get presigned URLs from museum and write directly to the object store. So the S3 endpoint must be reachable, with a valid certificate, from every phone that will ever upload, not just from the museum container on the same Docker network. A MinIO answering only on localhost:3200 works in the quickstart and fails the moment you leave the house. Give the object store its own public hostname behind your reverse proxy, set that as the endpoint in museum's config, and test an upload from mobile data before you migrate 50,000 photos.

Pointing the apps at your server

The mobile and desktop apps talk to ente.io by default. On the login screen, tap the Ente logo 7 times and a field appears for a custom endpoint; enter your museum URL. The web app takes it from an environment variable at build or run time. After that the experience is identical to Ente's hosted service: automatic camera roll backup, albums, shared links, family sharing with a common storage pool, and on-device ML that runs the first time you open the library.

Immich or Ente, honestly

Ente wins for people whose threat model includes the server itself. Immich wins for the rest, for large libraries where server-side indexing pays off, and for anyone who wants a smooth exit from Google Photos with the least effort; the Immich migration walkthrough is the easier road. A quietly common pattern is to run Immich at home and pay Ente for an encrypted off-site copy, which is the one photo backup arrangement I would call properly safe.

Backups when the server is blind

Back up the Postgres dump and the object store together; either alone is useless. The encrypted objects are safe to replicate to any untrusted destination, which is a real advantage: a nightly MinIO mirror to a cheap S3 bucket costs almost nothing and leaks nothing. Keep each user's recovery key printed somewhere physical, because there is no other way back into an account.

What I'd do

Only self-host Ente if the "server cannot see my photos" property matters to you specifically. If it does: the quickstart on a 2 GB VM, MinIO moved behind a public hostname with TLS on day one, an upload tested over mobile data, Postgres plus objects mirrored off-site, recovery keys on paper. If it doesn't, install Immich and enjoy the search. Either way, put photos on the list of things you restore-test, not just back up.