Встановлення за допомогою Docker Compose

Docker Compose — це спосіб запускати Kept на одній машині: сам Kept і Postgres 18 з pgvector. Caddy для HTTPS і Ollama для локального ШІ постачаються у другому файлі (Caddy і Ollama). Вам потрібен Docker з плагіном Compose. Протестовано на машині з 1 ГБ оперативної пам’яті та одним ядром процесора; Kept і його база даних споживають близько 200–400 МБ (що було протестовано).

Чотири кроки, без копіювання репозиторію і без створення паролів:

mkdir kept && cd kept
curl -fsSLO https://raw.githubusercontent.com/keptinventory/kept/v1.14.7/compose.yaml
docker compose run --rm init
docker compose up -d

compose.yaml працює самостійно, тому його також можна вставити в Portainer, Dockge та подібні засоби (див. без терміналу).

Що запускається

Service	Запускається
`db`	Postgres, і залишається працювати
`kept`	Kept на порту 8080, і залишається працювати
`bootstrap`	один раз при кожному запуску, потім завершується: логіни бази даних і розширення
`migrate`	один раз при кожному запуску, потім завершується: міграції бази даних
`init`	лише коли ви запускаєте його (`docker compose run --rm init`): записує `.env`

Caddy і Ollama

compose.yaml запускає лише Kept. compose.full.yaml — це той самий файл плюс Caddy для HTTPS (профіль https), Ollama для локального ШІ (профіль ollama) та розділене розгортання вебу і воркера, закоментоване. Він також працює самостійно. Щоб використати його замість цього:

curl -fsSLO https://raw.githubusercontent.com/keptinventory/kept/v1.14.7/compose.full.yaml
docker compose -f compose.full.yaml run --rm init
echo COMPOSE_FILE=compose.full.yaml >> .env
docker compose up -d

З COMPOSE_FILE у .env звичайний docker compose читає compose.full.yaml, тож кожна команда в цій документації працює як написано. Сервіси Kept, мережа і томи однакові в обох файлах: встановлення може переключитися будь-коли і зберегти свої дані.

1. Запишіть `.env`

docker compose run --rm init

init запитує адресу, за якою ви відкриєте Kept, наприклад http://kept.home.arpa:8080 або https://kept.example.org. Посилання, QR-коди на друкованих етикетках і перевірка same-site будуються з неї, тому вона має точно збігатися з тим, що показує браузер, і не повинна змінюватися: використовуйте назву замість IP-адреси. Домашній маршрутизатор може колись видати цій машині нову адресу, і тоді етикетки, які ви надрукували, вказуватимуть нікуди. Задайте назву в DNS маршрутизатора або у файлі hosts кожного пристрою. IP-адреса все одно працює, якщо ви її підтвердите.

Потім він записує .env поруч із compose.yaml з цією адресою (KEPT_PUBLIC_URL), портом (KEPT_HTTP_PORT, з адреси http://), зображенням і кодом налаштування (KEPT_SETUP_CODE), і показує код. .env не містить пароля і доступний для читання лише вам. Запустіть init знову, щоб змінити адресу: він оновить ці рядки і збереже все інше, що ви додали. Без терміналу вкажіть адресу в командному рядку: docker compose run --rm init --url http://kept.home.arpa:8080.

Все інше необов’язкове; compose.env.example і довідка з конфігурації пояснюють, що робить кожна змінна.

2. Запустіть

docker compose up -d

Compose запускає базу даних і чекає, поки вона стане здоровою. Потім:

bootstrap (одноразовий, kept bootstrap) створює чотири логіни бази даних Kept і розширення pg_trgm, unaccent та vector. При першому запуску він генерує пароль кожного логіна у том; при кожному запуску він установлює пароль кожного логіна на це значення, тож Postgres і Kept завжди узгоджені.
migrate (одноразовий, kept migrate) застосовує міграції бази даних один раз, під блокуванням.
Kept запускається на порту 8080 (KEPT_HTTP_PORT змінює порт хоста).

3. Завершіть налаштування

Відкрийте адресу, введіть код налаштування, який показав init, і створіть перший обліковий запис: він стає адміністратором інстанції. Kept також друкує код у своєму журналі при першому запуску:

docker compose logs kept | grep "KEPT SETUP CODE"

Загублений код видається знову за допомогою:

docker compose run --rm migrate admin setup-code

Неправильні коди тимчасово блокують, для кожної адреси і для всієї інстанції. Якщо Kept працює за проксі, якому він не довіряє, усі використовують адресу проксі; див. зворотні проксі.

4. Збережіть ключі

При першому запуску, якщо KEPT_SECRET_KEY і KEPT_AUTH_SECRET не встановлені, Kept генерує обидва в том kept-config і пише в журнал один рядок із зазначенням де. Секретний ключ шифрує кожне секретне значення (ключі ШІ, паролі, які ви зберігаєте в Kept): резервна копія відновлює все, крім цих значень, якщо ви також не маєте ключа.

Виведіть ключі і збережіть їх десь поза цим сервером, наприклад у менеджері паролів:

docker compose exec kept kept admin recovery-kit

Admin → Status просить підтвердити набір відновлення, і Kept вимагає цього до першого секретного значення, ключа ШІ або налаштування резервної копії. Див. набір відновлення.

5. Далі

Розмістіть Kept на HTTPS: камера, встановлення застосунку, push-сповіщення та геолокація працюють лише через HTTPS.
Налаштуйте резервні копії.
Пошта: встановіть KEPT_SMTP_URL (smtp:// або smtps://, з обліковими даними) і KEPT_SMTP_FROM для скидання паролів, запрошень і нагадувань електронною поштою. Без них нагадування доходять до людей лише в застосунку, а Admin → Status повідомляє, що пошту не налаштовано.

Що створює Compose

Volume	Містить	Робити резервну копію?
`kept-db`	база даних Postgres	через резервну копію Kept, ніколи не копіюючи том під час роботи
`kept-data`	завантажені файли (з `KEPT_STORAGE=local`, типово)	через резервну копію Kept
`kept-config`	згенеровані `KEPT_SECRET_KEY` і `KEPT_AUTH_SECRET`, а також паролі логінів `kept_app`, `kept_auth` та `kept_system`	збережіть набір відновлення; паролі створюються знову, якщо втрачені
`kept-owner`	пароль логіна `kept_owner`	ні; він створюється знову, якщо втрачений
`caddy-data`, `caddy-config`	сертифікати Caddy (профіль `https` з `compose.full.yaml`)	ні; Caddy отримає нові

Суперкористувач бази даних не має пароля, який комусь потрібен: до нього можна дістатися лише зсередини контейнера бази даних, як docker compose exec db psql -U postgres, і завантажувачем, який має спільну мережу цього контейнера. Через мережу кожному логіну потрібен його пароль. Ніколи не публікуйте порт сервісу db (без ports: у нього): Kept дістається до нього через мережу compose.

Контейнери Kept працюють від не-root користувача (uid 10001) з файловою системою кореня лише для читання, з усіма Linux- можливостями знятими та no-new-privileges. Сервіс migrate має логін власника бази даних; сервінговий контейнер ніколи його не бачить (том kept-owner туди не монтується), доки ви не дасте йому його для нічної резервної копії (резервні копії). init — єдиний виняток із правила не-root: він працює від root, без мережі і лише з можливостями, які створюють .env у вашій теці і віддають його вам, і завершується.

Без терміналу

Portainer, Dockge та подібні засоби беруть compose.yaml (або compose.full.yaml) як є. Вони не запускають init, тож встановіть замість цього дві змінні в їхньому редакторі середовища: KEPT_PUBLIC_URL (адресу, як вище) і KEPT_SETUP_CODE (шість символів з 0–9 і A–Z без I, L, O та U, наприклад KPT-2X9; або залиште порожнім і прочитайте код з журналу Kept). Зафіксуйте KEPT_IMAGE на релізі, якщо засіб цього не робить.

Встановлення, створене до 1.13.0

Встановлення, зроблене з копії репозиторію, має п’ять рядків KEPT_DB_*_PASSWORD у .env. З цим compose.yaml вони використовуються точно як задані, і нічого не генерується: оновіть checkout (або завантажте новий compose.yaml поруч зі старим .env) і запустіть docker compose up -d. Видалити ці рядки пізніше або записати .env знову за допомогою init також безпечно: наступний запуск згенерує нові паролі і встановить їх у Postgres. Порожній KEPT_IMAGE раніше використовувався для збірки checkout; тепер він запускає реліз, який називає compose.yaml, тож встановіть KEPT_IMAGE=kept:local, якщо збираєте власний.

Веб і воркер самостійно

Один контейнер обслуговує вебзастосунок і виконує фонові завдання (KEPT_ROLE=all, типово). Щоб розділити їх, запустіть другий сервіс Kept з KEPT_ROLE=worker поруч із тим, що має KEPT_ROLE=web. Воркер не обслуговує HTTP; перевірка здоров’я зображення враховує KEPT_ROLE і перевіряє цикл завдань воркера замість цього, тож жодному не потрібне перевизначення (у compose.full.yaml два сервіси закоментовані). Воркер виконує нічну резервну копію, тож саме він потребує логіна власника і монтування цільової теки.