Індекс журналуDockup / польова нотатка
Note / self-host-anythingllm

Як розгорнути AnythingLLM на власному сервері у 2026 році: документи, embeddings і збереження даних

Розгорніть AnythingLLM на власному сервері з правильними портами, постійним сховищем, HTTPS, секретами, резервними копіями та перевірками оновлень. Дізнайтеся, як виправити ситуацію, коли mount сховища відсутній.

Контейнер AnythingLLM може працювати без помилок, хоча ключова для користувачів функція не працює. У випадку AnythingLLM прихована проблема зазвичай полягає у відсутньому mount сховища або в тому, що після індексації змінилася embedding-модель. У цьому посібнику критерієм приймання є така перевірка: завантажити документ, дочекатися embedding, поставити запитання, відповідь на яке залежить від цього документа, і перевірити процитований фрагмент джерела. Розгортання будується у зворотному напрямку — від цього результату.

AnythingLLM виконує в стеку конкретну роль: забезпечує чат із документами та пошук без власноруч зібраного pipeline. Тому виробниче питання полягає не в тому, чи відповідає порт 3001 один раз, а в тому, чи узгоджуються state, залежності та публічна адреса після перезапуску, оновлення й відновлення.

Порти, процеси та приватні сервіси

Корисна схема AnythingLLM має показувати публічний маршрут, приватний порт 3001, межу state та всі необхідні залежності. Позначте, які стрілки передають облікові дані, а які використовуються для звичайного трафіку користувачів. Мережевий контракт AnythingLLM включає embedding-провайдера, LLM-провайдера та достатній обсяг сховища для документів. Тримайте приватні endpoints у внутрішньому DNS, дозволяйте лише необхідні вихідні виклики та надайте AnythingLLM service credential з обмеженими правами.

Підтвердьте схему реальною дією: завантажте документ, дочекайтеся embedding, поставте запитання, відповідь на яке залежить від цього документа, і перевірте процитований фрагмент джерела. Найімовірніше, навантаження створюватимуть парсинг документів, пропускна здатність embedding, розмір vector store та контекст, який передається вибраній моделі; моніторте саме цей шлях, а не сприймайте всі HTTP-запити як рівнозначні.

Зробіть відновлення AnythingLLM вимірюваним

Складіть перелік усіх довговічних артефактів: документів, vector indexes, workspaces і налаштувань застосунку. Підключіть /app/server/storage до bootstrap, запишіть безпечні тестові дані та замініть контейнер, щоб довести, що цей шлях справді зберігається. Додайте конфігурацію, яка змінює спосіб інтерпретації збережених даних, а не лише найбільшу директорію.

Встановіть retention, копіюйте резервні копії за межі хоста та виконайте відновлення в чистому середовищі. Перевірку AnythingLLM можна вважати завершеною, коли документи, embeddings, членство у workspaces і налаштування провайдерів відновлюються разом і дають відповідь на те саме запитання, підтверджену джерелами. Якщо snapshots є частиною плану, скористайтеся порівнянням PITR і snapshots, щоб задокументувати, які дані може відновити кожен механізм.

Визначте межу довіри AnythingLLM

Після першого входу перевірте, що можуть робити анонімний відвідувач, звичайний користувач і адміністратор. Проблема AnythingLLM, якої слід уникати, — сприймати вхід до workspace як заміну ізоляції ключів провайдерів. Передбачена політика полягає в тому, щоб обмежити учасників конкретними workspaces, а облікові дані LLM, embedding і vector database зберігати на сервері.

Згенеруйте JWT_SECRET як довге випадкове значення; його ротація зазвичай робить сесії або токени недійсними, тому плануйте вплив на користувачів, а не називайте це міграцією шифрування. Розділяйте облікові записи залежностей і людей, за можливості забороняйте невикористовуваний egress і обмежуйте навантаження, пов’язане з парсингом документів, пропускною здатністю embedding, розміром vector store та контекстом, який передається вибраній моделі.

Що має пройти до появи реальних даних AnythingLLM

У записі про реліз AnythingLLM потрібні факти, а не формулювання «виглядає добре». Збережіть digest вибраного image, checksum конфігурації, публічне hostname та результат із timestamp для такої перевірки: завантажити документ, дочекатися embedding, поставити запитання, відповідь на яке залежить від цього документа, і перевірити процитований фрагмент джерела. Використовуйте тестові дані, не призначені для production, щоб перевірку можна було запускати після кожного розгортання.

Перевірте окремо дві події життєвого циклу. Заміна контейнера має зберігати нормальну роботу; чисте відновлення повинно показати, що документи, embeddings, членство у workspaces і налаштування провайдерів відновлюються разом і дають відповідь на те саме запитання, підтверджену джерелами. Поки тривають перевірки, вимірюйте парсинг документів, пропускну здатність embedding, розмір vector store та контекст, який передається вибраній моделі, і зберігайте результат як очікуваний envelope для цієї версії.

Також перевірте заборонену або некоректну умову: тимчасово забороніть тестовій identity доступ до embedding-провайдера, LLM-провайдера та достатнього сховища для документів. AnythingLLM має завершитися з помилкою, яку можна діагностувати, і не повинен перезаписувати працездатний state. Відновіть коректну умову, повторно запустіть тест із прикладом і додайте відповідні redacted logs. Ці артефакти нададуть майбутньому рішенню про rollback конкретні докази.

Створіть контейнер AnythingLLM, який можна замінити

Мінімальна команда корисна, коли показує, чим надалі керуватиме платформа.

docker run -d \
  --name anythingllm \
  --restart unless-stopped \
  -p 127.0.0.1:3001:3001 \
  -v anythingllm-data:/app/server/storage \
  -e JWT_SECRET=replace-with-a-long-random-value \
  mintplexlabs/anythingllm:latest

Тут порт 3001 залишається приватним на рівні хоста, а кожен необхідний шлях задано явно. Додайте перевірені параметри підключення до embedding-провайдера, LLM-провайдера та достатнього сховища для документів; для приватних сервісів використовуйте приватні імена. Перевірте запуск за допомогою logs і специфічної для застосунку перевірки: завантажте документ, дочекайтеся embedding, поставте запитання, відповідь на яке залежить від цього документа, і перевірте процитований фрагмент джерела. Після перевірки зафіксуйте версію image, щоб звичайна заміна не змінила поведінку непомітно.

Протестуйте AnythingLLM із зовнішнього боку сервера

Не використовуйте тимчасові та постійні публічні origins для AnythingLLM. Натомість використовуйте зовнішній HTTPS origin для доступу через браузер і API, спрямуйте вибране DNS-ім’я на маршрут платформи та проксируйте трафік лише на порт 3001.

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

Перевірки відмов AnythingLLM

Створіть dashboards для парсингу документів, пропускної здатності embedding, розміру vector store та контексту, який передається вибраній моделі. Графік CPU без контексту цього навантаження не пояснить, чому AnythingLLM працює повільно. Додайте synthetic або scheduled check, який намагається завантажити документ, дочекатися embedding, поставити запитання, відповідь на яке залежить від цього документа, і перевірити процитований фрагмент джерела, використовуючи безпечні тестові дані.

Перед оновленням врахуйте специфічний для цього застосунку ризик: зміна embedding-моделі може потребувати повторної індексації, а релізи застосунку можуть мігрувати metadata workspace і vector metadata. Відновіть свіжу резервну копію в ізольованому розгортанні, виконайте там міграції та порівняйте поведінку. Якщо mount сховища відсутній або embedding-модель змінилася після індексації, перевірте відповідну межу — public origin, storage або dependency — перш ніж змінювати непов’язані налаштування.

Що Dockup має автоматизувати для AnythingLLM

Для AnythingLLM Dockup може створити route і TLS certificate, зберегти mounts, доставити secrets і розмістити embedding-провайдера, LLM-провайдера та достатнє сховище для документів у приватній мережі, розгортаючи систему в Dockup або на підключених серверах.

Gate релізу все одно має бути конкретною транзакцією AnythingLLM: завантажити документ, дочекатися embedding, поставити запитання, відповідь на яке залежить від цього документа, і перевірити процитований фрагмент джерела. Також перевірте умову відновлення — документи, embeddings, членство у workspaces і налаштування провайдерів мають відновитися разом і дати відповідь на те саме запитання, підтверджену джерелами. Ці дві перевірки показують, чи працює розгортання і чи можна його відновити.

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

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

Маршрутизуйте контейнер AnythingLLM на порт 3001 через один HTTPS origin. Мережева вимога для залежностей — embedding-провайдер, LLM-провайдер і достатній обсяг сховища для документів. Не вважайте AnythingLLM готовим, доки не зможете завантажити документ, дочекатися embedding, поставити запитання, відповідь на яке залежить від цього документа, і перевірити процитований фрагмент джерела.

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

Зберігайте /app/server/storage і включіть документи, vector indexes, workspaces та налаштування застосунку до одного recovery manifest. Чисте відновлення AnythingLLM вважається успішним лише тоді, коли документи, embeddings, членство у workspaces і налаштування провайдерів відновлюються разом і дають відповідь на те саме запитання, підтверджену джерелами.

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

Використовуйте HTTPS для публічного origin AnythingLLM, а порт 3001 залишайте у внутрішньому маршруті. Правильно застосуйте налаштування AnythingLLM: використовуйте зовнішній HTTPS origin для доступу через браузер і API. Для AnythingLLM HTTPS захищає облікові дані або вміст користувачів під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

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

Відновіть поточний state AnythingLLM в ізольованому розгортанні, застосуйте кандидатну версію та повторіть acceptance transaction. Зверніть особливу увагу на те, що зміна embedding-моделі може потребувати повторної індексації, а релізи застосунку можуть мігрувати metadata workspace і vector metadata. Зберігайте попередній image AnythingLLM, доки не буде зрозуміло межі міграції даних і rollback.