Ente
Self-hosted облако для фото со сквозным шифрованием (E2EE): сервер хранит только зашифрованные блобы, ключи - у вас. Приватная замена Google Photos с иным акцентом, чем Immich: не «галерея с ML на сервере», а «сервер не может прочитать ваши фото в принципе». Развернули на Fatmetal, замерили (сервер оказался в разы легче Immich), прошли E2EE-онбординг и честно разобрали, кому это подходит - и почему это не история про «одну кнопку».
Коротко: брать или нет
- Приватность важнее всего: нужно, чтобы даже владелец сервера не мог прочитать ваши фото (E2EE)
- Хотите легкий сервер: вся тяжелая работа на клиенте, серверу хватает 1-2 ГБ RAM
- Данные фото должны остаться в РФ, без зарубежных подписок (152-ФЗ) плюс слой шифрования сверху
- Нужен серверный поиск по лицам и объектам по открытым данным - тогда смотрите Immich
- Хотите «поставил и забыл»: внешний доступ требует раздельных поддоменов, первый вход - код из логов
- Есть риск забыть пароль: без ключа восстановления данные не вернуть никак
Проверено на self-hosted Ente (museum rolling latest, Photos v1.3.57), Ubuntu 24.04, docker compose, июль 2026. Ente развивается быстро - на новых версиях детали могут отличаться.
Что это и какую задачу решает
Ente - это личное облако для фото, построенное вокруг одной идеи: сквозное шифрование по умолчанию. Ваши снимки шифруются на устройстве до отправки, и сервер видит только зашифрованные блобы - ключи есть только у вас. Мобильные приложения (iOS, Android) авто-заливают фото с телефона, есть веб и десктоп. Плюс у Ente отдельный продукт - Ente Auth, E2EE-аутентификатор (замена Google Authenticator).
По задаче Ente заменяет Google Photos, Apple iCloud Photos, Amazon Photos - но для тех, кому мало «своего облака», нужен еще и нулевой доступ провайдера к контенту. Это другой акцент, чем у Immich: Immich - про богатую галерею с серверным ML (поиск по лицам и объектам на сервере), Ente - про приватность, где сервер принципиально не может прочитать ваши данные. Проект open-source (AGPL-3.0), около 27 тыс. звезд на GitHub.
Что у Ente под капотом
Ente self-host - это docker compose из пяти сервисов. museum - сервер API на Go (порт 8080). web - веб-приложения (Photos, Accounts, Albums, Auth - образ ghcr.io/ente/web). Postgres 15 - метаданные. MinIO - S3-совместимое объектное хранилище для зашифрованных блобов. socat - служебный проксик, чтобы museum достучался до MinIO. Ставится официальным скриптом quickstart, который генерирует конфиги с автосекретами.
Ключевая деталь: museum - сервер API, а не «умный» бэкенд. Вся крипта, генерация превью и ML-поиск выполняются на клиенте (на телефоне или в браузере), потому что сервер не имеет доступа к расшифрованным данным. Отсюда следствие, которое видно в замерах ниже: сервер сверхлегкий.
Как развернуть на Fatmetal Cloud Server
Взяли Fatmetal Cloud Server с чистой Ubuntu 24.04. Сервер легкий, так что даже тариф с запасом - оптимум CPU2-RAM4. Ставится через официальный quickstart.
Docker и compose 2.30+
Ente требует именно плагин
docker composeверсии не ниже 2.30.Запустить quickstart
sh -c "$(curl -fsSL .../server/quickstart.sh)"создает каталог сcompose.yamlиmuseum.yamlи автосекретами (пароли БД, ключи museum, доступ к MinIO). Дальшеdocker compose up -d.Домен и TLS - обязательно HTTPS
museum принимает только HTTPS. Официально нужны раздельные поддомены на сервисы (api, web, accounts, albums). Мы подняли Caddy на magic-DNS домене на двух портах: 443 на веб, 8443 на museum API, и указали веб-приложению этот API-origin.
Проверили не только запуск: зарегистрировали аккаунт, прошли E2EE-онбординг и вошли в галерею - продукт работает, интерфейс на русском.
Сколько реально ест (и почему так мало)
Главный сюрприз - Ente сервер сверхлегкий. Весь стек в простое занимает ~176 МБ RAM по контейнерам, а вся система - около 870 МБ из 8 ГБ. Сам museum - 27 МБ. Для сравнения: наш стенд Immich с серверным ML держал ~3 ГБ. Причина прямая: у Ente все шифрование и индексация на клиенте, серверу почти нечего считать.
| RAM всего в системе | ~870 / 7941 МБ |
| museum (API) | ~27 МБ |
| MinIO (S3) | ~74 МБ |
| Postgres | ~52 МБ |
| web | ~10 МБ |
| Диск (ОС + образы) | 4 / 96 ГБ |
Вывод по ресурсам: минимум 1 ГБ RAM, оптимум 2-4 ГБ. Узкое место у Ente - не CPU и не RAM, а объем хранилища под зашифрованные блобы (об этом дальше).
S3 - это ядро, а не опция
У Immich хранилище на S3 было рекомендацией для большой фототеки. У Ente объектное хранилище лежит в основе архитектуры: museum пишет зашифрованные блобы в S3-совместимый бакет. Self-host по умолчанию поднимает встроенный MinIO с тремя бакетами - Ente умеет держать реплику сразу в нескольких хранилищах для надежности.
Тариф выбираем по объему хранилища, не по CPU/RAM. Сервер Ente почти ничего не ест, поэтому берем тариф CPU2-RAM4-DISK50 по вычислениям, а под растущую фототеку подключаем быстрое S3 (не HDD). Встроенный MinIO хорош для старта и небольших библиотек; для серьезного объема endpoint в museum.yaml переключают на внешний S3.
Практический вывод тот же, что и у Immich, но здесь он еще жестче: платить надо за хранилище, а не за мощный сервер. Postgres при этом держим на локальном диске.
Как войти (и про ключ восстановления)
Регистрация - в веб-приложении: email и пароль. Дальше подтверждение почты кодом. Важная особенность self-host: без настроенного SMTP код подтверждения не уходит письмом, а пишется в логи сервера (docker compose logs museum, строка «Verification code»). Это штатное поведение, но означает, что первый вход требует доступа к серверу - для «одной кнопки» неудобно.
После пароля Ente показывает ключ восстановления - и это суть E2EE-модели. Если вы забудете пароль, данные можно восстановить только этим ключом. Потеряете и пароль, и ключ - фото не вернет никто, включая владельца сервера. Это цена настоящей приватности: нет кнопки «сбросить пароль», потому что сервер физически не имеет доступа к вашим ключам.
Ente или Immich - что выбрать
Это два разных ответа на вопрос «личное облако для фото». Коротко:
| Критерий | Ente | Immich |
|---|---|---|
| Модель | E2EE, сервер не видит фото | Сервер видит фото |
| Поиск по лицам/объектам | на клиенте (устройство) | на сервере (ML) |
| RAM сервера | ~0.2 ГБ | 6-8 ГБ (из-за ML) |
| Внешний доступ | сложнее (раздельные поддомены, HTTPS-only) | один домен |
| Восстановление пароля | только ключом (иначе никак) | обычный сброс |
Нужна максимальная приватность и легкий сервер - Ente. Нужен богатый серверный поиск и простой доступ - Immich (у нас есть отдельный разбор Immich). Это не «лучше/хуже», а разные модели угроз.
Где может сломаться
Внешний доступ - не одна кнопка
museum принимает только HTTPS, а веб хочет раздельные поддомены (api, web, accounts, albums). На одном домене приходится разводить сервисы по портам или поддоменам вручную. Публичный шаринг альбомов и passkey-аккаунты требуют своих поддоменов.
Причина. В self-host по умолчанию не настроен SMTP. Код подтверждения регистрации пишется в логи museum, а не отправляется письмом.
Решение. Взять код из docker compose logs museum (строка «Verification code»), либо настроить SMTP в museum.yaml, чтобы письма уходили клиенту.
Потеря ключа восстановления - потеря данных
E2EE не прощает: забыли пароль и потеряли ключ восстановления - данные не расшифровать. Сохраните ключ в надежном месте сразу при регистрации.
Когда это НЕ ваш выбор
Если вам нужен серверный поиск по лицам и объектам по открытым данным и богатая галерея на сервере - берите Immich. E2EE в Ente означает, что сервер не может индексировать ваши фото, и весь умный поиск считается на устройстве.
Если вы хотите развернуть «одной кнопкой» и раздать нетехническим пользователям - Ente потребует внимания: раздельные поддомены, HTTPS, а первый вход - код из логов. Для массового простого сценария это трение.
Если есть реальный риск забыть пароль и нет привычки хранить ключи - E2EE-модель опасна: восстановления «по email» здесь нет и быть не может.
Частые вопросы
Это бесплатно?
Да, self-host полностью бесплатный (AGPL-3.0). У вендора есть отдельное платное облако Ente Photos, но код открыт и сервер можно держать у себя без подписки.
Чем Ente отличается от Immich?
Ente шифрует все сквозным шифрованием - сервер не видит фото, поэтому он легкий, но поиск по лицам/объектам идет на клиенте. Immich мощнее по серверным фичам (ML на сервере), но сервер видит фото и требует 6-8 ГБ RAM.
Сколько нужно ресурсов?
Сервер сверхлегкий: минимум 1 ГБ RAM и 1 ядро, оптимум 2-4 ГБ. Основной расход - объем S3 под зашифрованные фото.
Зачем тут MinIO?
Ente пишет зашифрованные блобы в S3-совместимое хранилище - это ядро архитектуры. Self-host поднимает встроенный MinIO; для большого объема подключают внешнее быстрое S3.
Как получить код при регистрации?
Без настроенного SMTP код подтверждения пишется в логи museum (docker compose logs museum). Либо настройте SMTP, чтобы код уходил письмом.
Что будет, если забыть пароль?
Восстановить данные можно только ключом восстановления, который выдается при регистрации. Потеряете и пароль, и ключ - данные не вернуть. Это цена E2EE.
Данные точно останутся в РФ?
Да, если сервер в российском ЦОД (Fatmetal). Плюс к 152-ФЗ вы получаете слой E2EE - даже оператор ЦОД видит только шифртекст.
Итог
Ente - это privacy-first ответ на «личное облако для фото»: сквозное шифрование по умолчанию, сервер видит только шифртекст и потому сверхлегкий (~0.2 ГБ RAM против 6-8 у Immich). Взамен - другая цена: поиск по лицам и объектам считается на клиенте, внешний доступ сложнее (раздельные поддомены, только HTTPS, код входа из логов), а потеря ключа восстановления невосстановима. Для тех, кому приватность важнее серверных фич, и с РФ-фокусом (данные в РФ плюс шифрование) - сильный выбор. Кому нужен богатый серверный поиск и простой доступ - смотрите Immich.
Замеры сняты на Fatmetal Cloud Server (Ubuntu 24.04) в июле 2026, self-hosted Ente (museum rolling latest, Photos v1.3.57). Реальные IP, пароли и адреса серверов в публикацию не выносятся.