Як розгорнути Memos на власній інфраструктурі у 2026 році: нотатки, доступ до API та резервні копії

Розглядайте Memos як невелику систему, а не Docker image. Користувацька мета Memos зрозуміла: швидко створювати Markdown-нотатки з API; розгортання можна вважати прийнятним лише тоді, коли ви можете створити приватну нотатку та вкладення, отримати їх через API, відредагувати й переконатися, що вони збережуться після заміни контейнера.

Ця відмінність допомагає виявити проблему, з якою оператори стикаються після локального тестування: файл бази даних зберігається на шарі контейнера й зникає після його заміни. Вона також дає змогу скласти достатньо конкретний план резервного копіювання та оновлення, який можна протестувати.

Перетворіть локальну команду на сервіс, який можна перевіряти

Перший контейнер має бути простим для видалення та повторного створення. Зберігайте дані за межами шару для запису, прив’язуйте порт 5230 лише там, де до нього може дістатися proxy, і передавайте конфігурацію під час запуску.

docker run -d \
  --name memos \
  --restart unless-stopped \
  -p 127.0.0.1:5230:5230 \
  -v memos-data:/var/opt/memos \
  neosmemo/memos:stable --mode prod --port 5230

Після первинного тестування зафіксуйте версію image. Читайте найпершу помилку запуску, а не фінальне повідомлення про перезапуск, перевіряйте кожне монтування за допомогою docker inspect і стежте за логами, поки створюєте приватну нотатку та вкладення, отримуєте їх через API, редагуєте й переконуєтеся, що вони зберігаються після заміни контейнера. Така послідовність дає змогу відрізнити неправильну команду запуску image від проблеми із залежністю чи правами доступу.

Спочатку визначте критерії успіху для Memos

Розділіть чотири аспекти Memos: ingress, listener на порту 5230, постійний стан і допоміжні сервіси або локальні ресурси. Вимога локального середовища виконання — один постійний volume для вбудованої бази даних та assets. Перевірте цю межу перед публікацією, а потім ще раз після заміни контейнера.

Перед тим як вважати це розділення завершеним, виконайте перевірену транзакцію — створіть приватну нотатку та вкладення, отримайте їх через API, відредагуйте й переконайтеся, що вони зберігаються після заміни контейнера. Вимірюйте операції запису SQLite, обсяг вкладень, API-трафік і пошук у накопичених нотатках та зберігайте результати разом із записом про розгортання. Це дає і критерій приймання, і перший орієнтир для оцінки місткості.

Не надавайте Memos доступ до всього хоста

Для Memos цінною є не обов’язково головна сторінка. Основна помилка — залишити відкритою реєстрацію довше, ніж потрібно. Свідомо протидійте цьому: за потреби закрийте реєстрацію та захистіть приватні нотатки надійним обліковим записом і HTTPS.

У цій базовій конфігурації Memos не має обов’язкового bootstrap secret; натомість захистіть фактичний обліковий запис адміністратора або upstream authentication. Використовуйте непривілейованого користувача контейнера, якщо image це підтримує, і не монтуйте сторонні credentials. Застосовуйте обмеження швидкості або розміру на ingress там, де недовірені операції можуть споживати записи SQLite, збільшувати обсяг вкладень, API-трафік і навантаження від пошуку в накопичених нотатках.

TLS — це просто, а згенеровані URL — ні

Уникайте тимчасових і постійних public origins для Memos. Натомість використовуйте стабільний HTTPS origin для browser- та API-клієнтів, спрямуйте вибране DNS-ім’я на platform route і налаштуйте proxy лише на порт 5230.

Виконайте цю дію ззовні хоста: створіть приватну нотатку та вкладення, отримайте їх через API, відредагуйте й переконайтеся, що вони зберігаються після заміни контейнера. Якщо ingress не працює, у посібнику з усунення проблеми 502 Bad Gateway описано помилки, пов’язані з портом і listener. Якщо Memos отримує запит, але файл бази даних зберігається на шарі контейнера й зникає після заміни, тепер докази вказують на проблему за межами proxy.

Доведіть, що Memos переживає заміну контейнера

Docker image можна завантажити повторно, а базу даних Memos і завантажені ресурси — ні. Змонтуйте /var/opt/memos до bootstrap, запишіть нешкідливі тестові дані та замініть контейнер, щоб довести фактичну постійність цього шляху. Перевіряйте ефективне монтування, а не покладайтеся на назву Compose-файлу, і переконайтеся, що runtime user може записувати туди, де очікує Memos.

Визначте строк зберігання та зовнішнє сховище, а потім відпрацюйте відновлення, не торкаючись production. Перевірку пройдено лише тоді, коли повернулися користувачі, нотатки, теги та ресурси, а API отримує відому приватну нотатку. Для стану, що зберігається в базі даних, поєднуйте snapshots сховища з application-consistent exports, як описано в матеріалі відновлення до моменту часу проти snapshots.

П’ять перевірок, які надійніші за health контейнера

Не використовуйте трафік першого користувача як тест приймання Memos. Підготуйте нешкідливий тестовий стан і виконайте повну дію: «створіть приватну нотатку та вкладення, отримайте їх через API, відредагуйте й переконайтеся, що вони зберігаються після заміни контейнера». Зафіксуйте точний public URL, результат, reference image і інтервал логів, пов’язані з виконанням.

Замініть контейнер і повторіть перевірку, не перебудовуючи дані. Потім виконайте відновлення на порожньому хості; умова відновлення — повернення користувачів, нотаток, тегів і ресурсів, а також отримання відомої приватної нотатки через API. Під час кожного проходження спостерігайте за операціями запису SQLite, обсягом вкладень, API-трафіком і пошуком у накопичених нотатках та визначте alert для погіршення транзакції, а не для idle-метрик контейнера.

Одна фінальна перевірка має навмисно завершитися помилкою: надішліть нешкідливе введення, близьке до обмеження ресурсу або формату, пов’язаного з цією межею: файл бази даних зберігається на шарі контейнера й зникає після заміни. Переконайтеся, що повідомлення Memos вказує на відповідну межу, а не запускає видалення даних чи нескінченний перезапуск. Відновіть правильну умову й переконайтеся, що та сама тестова транзакція виконується успішно. Додайте цю коротку перевірку до release checklist.

Логи, які відповідають на наступне запитання

Використовуйте дію «створити приватну нотатку та вкладення, отримати їх через API, відредагувати й переконатися, що вони зберігаються після заміни контейнера» як smoke test Memos після кожного розгортання. Супровідні метрики — операції запису SQLite, обсяг вкладень, API-трафік і пошук у накопичених нотатках; налаштуйте alert, коли ці ресурси наближаються до рівня, що погіршує користувацьку дію.

Основний ризик під час змін полягає в тому, що міграції бази даних Memos потрібно репетирувати на копії, оскільки весь стан сервісу міститься в одному компактному шляху. Безпечний release починається з snapshot, який можна відновити, і перевіряє будь-яку незворотну зміну стану до перемикання трафіку. Якщо файл бази даних зберігається на шарі контейнера й зникає після заміни, не видаляйте несправний контейнер, доки не прочитаєте його конфігурацію та першу помилку.

Використовуйте Dockup для platform layer

Dockup усуває ручну роботу з reverse proxy та життєвим циклом навколо Memos. Під час замін сервіс отримує стабільний HTTPS route до 5230, інжектовану конфігурацію та постійне сховище. Підключений сервер клієнта працює за тією самою моделлю, що й compute у Dockup.

Після запуску виконайте application contract: використовуйте стабільний HTTPS origin для browser- та API-клієнтів, підтвердьте локальну вимогу — один постійний volume для вбудованої бази даних та assets — і виконайте таку перевірку: створіть приватну нотатку та вкладення, отримайте їх через API, відредагуйте й переконайтеся, що вони зберігаються після заміни контейнера. Це зберігає практичність one-click experience, не спрощуючи деталі, від яких залежать можливість відновлення та безпека Memos.

Поширені запитання

Що потрібно Memos для production-розгортання?

Спрямуйте контейнер Memos на порту 5230 через один HTTPS origin. Вимога локального середовища виконання — один постійний volume для вбудованої бази даних та assets. Не вважайте Memos готовим, доки не зможете створити приватну нотатку та вкладення, отримати їх через API, відредагувати й переконатися, що вони зберігаються після заміни контейнера.

Які дані Memos потрібно включити до резервної копії?

Зберігайте /var/opt/memos і включайте базу даних Memos та завантажені ресурси до одного recovery manifest. Відновлення Memos можна вважати успішним лише тоді, коли повернулися користувачі, нотатки, теги та ресурси, а API отримує відому приватну нотатку.

Чи потрібен Memos HTTPS за reverse proxy?

Використовуйте HTTPS для public origin Memos, а порт 5230 залишайте у внутрішньому route. Правильно застосуйте налаштування Memos: використовуйте стабільний HTTPS origin для browser- та API-клієнтів. Для Memos HTTPS захищає credentials або користувацький контент під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Memos?

Відновіть поточний стан Memos в ізольованому розгортанні, застосуйте candidate version і повторіть транзакцію приймання. Зверніть особливу увагу: міграції бази даних Memos потрібно репетирувати на копії, оскільки весь стан сервісу міститься в одному компактному шляху. Зберігайте попередній Memos image, доки не зрозумієте межі міграції даних і rollback.