# Seafile + OnlyOffice + Docker (Готовый стек для self-hosted альтернативы Nextcloud) **URL:** \ **Category:** Фото\\Медиа сервисы\ **Tags:** pve, гайд, руководство, homelab\ **Created:** [28.Февраль.2026 15:44:48 UTC](https://forum.samohosting.ru/t/seafile-onlyoffice-docker-gotovyj-stek-dlya-self-hosted-alternativy-nextcloud/1952 "2026-02-28T15:44:48Z")\ **Posts on this page:** 6\ **Page:** 3
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [05.Июнь.2026 19:41:46 UTC](https://forum.samohosting.ru/t/seafile-onlyoffice-docker-gotovyj-stek-dlya-self-hosted-alternativy-nextcloud/1952/44 "2026-06-05T19:41:46Z")
> [@ala-a-din](#): > > Мне всё-таки интересно, в чем же всё-таки тот или иной продукт должен быть медленнее/быстрее чем NC? Для понимания. Я сделал выбор в пользу этого - работой доволен, функции вполняет. Я же выше писал, что 1. NC написан на PHP, который никогда не славился своей скоростью (у меня лет 10 опыта на нем, если что), а сейчас, в эпоху компилируемых языков проигрывает подчистую. Всякие кешилки только борются с симптомами, но не решают архитектурную проблему PHP. 2. Исходя из этого мы понимаем, что там довольно таки много легаси кода со старыми архитектурными решениями. 3. NC перегружен функционалом, который многим не нужен, что-то грузится по необходимости, что-то грузится каждый раз, но все равно NC это комбайн, который потребляет ресурсы в соответствии с определением. 4. В продолжение к перегруженному функционалу, там одна из лучших систем OIDC, которую я видел, даже если мы не видим какой-то модуль, но все равно под капотом выполняются полезные обработчики, альтернативы просто не обладают такой гибкостью и ядреным функционалом как NC и поэтому работают быстрее. Поэтому, люди пытаются найти замену в виде, например, такого стека 1. Фотографии - immich 2. Звонки и чат - не знаю, matrix может 3. Файлохранилище - Seafile, Cloudreve, OpenCloud, Phylum 4. Заметки - Anchor, Obsidian… 5. Календари, почта - не знаю, я пока не нашел для себя замену OpenCloud, Phylum и Cloudreve написаны на go, который на сегодняшний день является одним из самых быстрых не не требовательных к ресурсам языку программирования, вместо интерпретации кода при каждом открытии страницы тут происходит компиляция кода в бинарный файл под конкретную архитектуру, что значительно снижает накладные расходы Seafile судя по гуглу Seahub написан на Python/Django, который не быстрее PHP, но серверная чать и движок синхронизации написаны на C/C++, что тоже круто по скорости, на уровне Go, но Go лучше работает с потоками ---
**Author:** ![ala-a-din](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/a/977dab/32.png) [@ala-a-din](https://forum.samohosting.ru/u/ala-a-din)\ **Post date:** [08.Июнь.2026 16:08:11 UTC](https://forum.samohosting.ru/t/seafile-onlyoffice-docker-gotovyj-stek-dlya-self-hosted-alternativy-nextcloud/1952/45 "2026-06-08T16:08:11Z")
> [@LamerDeath](#): > > подойдёт LXC под эту сборку? Перенес стэк с VM в LXC, все завелось как и в VM, поэтому смело можно ставить в LXC. Единственный нюанс после переноса, в логах есть: 1. `create_uring failed: falling back to libaio` в MariaDB — возникает почти всегда, если машина крутится в LXC или на ядре, где для контейнеров ограничены системные вызовы `io_uring`. База сама автоматически и безболезненно переключилась на классический движок асинхронного ввода-вывода `libaio`. На стабильность это не влияет. 2. `WARNING Memory overcommit must be enabled!` в Redis — стандартное «ворчание» Redis на настройки ядра Linux хоста. На домашних инстансах ни на что не влияет. Если захочешь убрать, достаточно на самой **новой хост-машине** (не в контейнере) выполнить `sudo sysctl vm.overcommit_memory=1` В контейнере команду выполнить не даст, нужно делать на хосте, но в таком случае она будет действовать на все контейнеры. Цитата из Ai на этот счет: > Если коротко: **в 95% случаев в домашних лабораториях это никак не вредит системе** , но поведение оперативной памяти для разных типов машин изменится по-разному. > > Давай разберем подробно, что произойдет с твоими сервисами. > > ### 1. Как это скажется на LXC-контейнерах (Эффект прямой) > > Поскольку все LXC-контейнеры делят одно ядро с Proxmox, эта настройка **автоматически применится ко всем контейнерам** без исключения. > > - **Плюсы:** Если у тебя в других контейнерах крутятся базы данных (PostgreSQL, MySQL, MariaDB) или другие инстансы Redis, им тоже станет «дышать» легче. Они перестанут спотыкаться на операциях типа `fork()` при создании бэкапов. > > - **Минусы:** Снимается внутренний предохранитель ядра. Если какой-то процесс в любом контейнере решит бесконечно жрать память (например, из-за утечки памяти в скрипте), ядро Linux не откажет ему на старте, а будет выделять память до последнего. > > #### Почему это НЕ приведет к катастрофе? > > В Proxmox для каждого контейнера в разделе **Resources** жестко задан лимит оперативной памяти (Memory) и свопа (Swap). За этим следит механизм ядра под названием **cgroups**. > > Даже если внутри контейнера включен безлимитный оверкоммит, Proxmox жестко ударит контейнер по рукам, как только тот попытается выйти за рамки выделенных ему, например, 2 ГБ. За рамки своего контейнера прожорливый процесс не уйдет. > > ### 2. Как это скажется на виртуальных машинах (KVM) (Эффект изолированный) > > С полноценными виртуалками ситуация другая. У каждой VM есть свое собственное, полностью изолированное ядро Linux или Windows. > > - Глобальный параметр `vm.overcommit_memory=1` на хосте Proxmox означает лишь то, что хост всегда разрешит процессу `qemu` (который и есть твоя виртуалка) запрашивать память у гипервизора. > > - **Внутри самой VM ничего не изменится.** Если внутри виртуалки стоит стандартный режим `0`, то процессы внутри нее будут жить по старым правилам. Чтобы включить оверкоммит в VM, его нужно прописывать внутри нее отдельно (как мы пытались сделать в начале). > > ### Главный и единственный риск: Что будет, если физическая память ПРАВДА закончится? > > Если ты выделил контейнерам слишком много памяти (сделал оверпровижининг — например, на хосте 16 ГБ RAM, а контейнерам суммарно раздал 24 ГБ) и они одновременно решат ее занять, наступит критическая ситуация. > > Когда физическая память и swap на Proxmox закончатся физически, ядро больше не сможет выделять страницы памяти. В этот момент включится **OOM Killer** (Out Of Memory Killer) самого Proxmox. > > Ядро начнет экстренно завершать процессы, чтобы спаснить сам гипервизор от полного зависания. И вот тут логика выбора «жертвы» угадывается тяжело: > > 1. Он может «пристрелить» самый прожорливый процесс внутри любого LXC-контейнера (например, твой `mariadbd`). > > 2. В худшем случае он может решить, что виноват процесс `qemu` одной из виртуальных машин, и у тебя просто «потухнет» целая виртуалка. > > ### Как спать спокойно? (Чек-лист для Proxmox) > > Чтобы спать спокойно с включенным оверкоммитом, соблюдай три простых правила в Proxmox: > > 1. **Не раздавай память «впритык»:** Оставляй самому Proxmox хотя бы 1.5–2 ГБ свободной памяти под его нужды. > > 2. **Настраивай лимиты:** Никогда не оставляй контейнеры без ограничений по RAM в настройках Proxmox. > > 3. **Включи Swap на хосте:** Наличие хотя бы 4–8 ГБ свопа на SSD-диске хоста Proxmox дает ядру огромный запас времени, чтобы сбросить туда неактивную память и не активировать OOM Killer при резких скачках нагрузки. > > Если на хосте отображается, что RAM занята, например, на 70-80% в пиках — включай эту настройку смело, никаких проблем с другими контейнерами не будет. ---
**Author:** ![Pavel](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@Pavel](https://forum.samohosting.ru/u/Pavel)\ **Post date:** [10.Июнь.2026 06:40:31 UTC](https://forum.samohosting.ru/t/seafile-onlyoffice-docker-gotovyj-stek-dlya-self-hosted-alternativy-nextcloud/1952/46 "2026-06-10T06:40:31Z")
> [@ala-a-din](#): > > - onlyoffice.yml - `onlyoffice.yml. - а где этот файл?` ---
**Author:** ![ala-a-din](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/a/977dab/32.png) [@ala-a-din](https://forum.samohosting.ru/u/ala-a-din)\ **Post date:** [10.Июнь.2026 07:41:22 UTC](https://forum.samohosting.ru/t/seafile-onlyoffice-docker-gotovyj-stek-dlya-self-hosted-alternativy-nextcloud/1952/47 "2026-06-10T07:41:22Z")
Вот это поворот: > services: > onlyoffice: > image: ${ONLYOFFICE\_IMAGE} > restart: unless-stopped > container\_name: seafile-onlyoffice > ports: > > - “${ONLYOFFICE\_PORT}:80” > environment: > - JWT\_ENABLED=true > - JWT\_SECRET=${ONLYOFFICE\_JWT\_SECRET:?Variable is not set or empty} > - PROXY\_TRUSTED=true > - PROXY\_PROTOCOL=https > - PROXY\_HOST=[office.example.ru](http://office.example.ru) > - PROXY\_PORT=443 > volumes: > - ${ONLYOFFICE\_VOLUME}/logs:/var/log/onlyoffice > - ${ONLYOFFICE\_VOLUME}/data:/var/www/onlyoffice/Data > - ${ONLYOFFICE\_VOLUME}/lib:/var/lib/onlyoffice > networks: > - seafile-net > > networks: > seafile-net: > name: seafile-net @admin если есть возможность исправь 1й пост, у меня нет такой возможности уже. ---
**Author:** ![admin](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/admin/32/4_2.png) [@admin](https://forum.samohosting.ru/u/admin)\ **Post date:** [10.Июнь.2026 08:40:51 UTC](https://forum.samohosting.ru/t/seafile-onlyoffice-docker-gotovyj-stek-dlya-self-hosted-alternativy-nextcloud/1952/48 "2026-06-10T08:40:51Z")
добавлено в 1ый пост ---
**Author:** ![LamerDeath](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/lamerdeath/32/2102_2.png) [@LamerDeath](https://forum.samohosting.ru/u/LamerDeath)\ **Post date:** [31.Июль.2026 00:55:04 UTC](https://forum.samohosting.ru/t/seafile-onlyoffice-docker-gotovyj-stek-dlya-self-hosted-alternativy-nextcloud/1952/49 "2026-07-31T00:55:04Z")
> [@ala-a-din](#): > > > [@LamerDeath](#): > > > > Подозреваю что не сработала связка seafile → onlyoffice. > > Вы на домен все завязываете или на локалку? > > Когда вы хотите открыть документ должен произойти редирект на onlyoffice, и хотябы появиться его интерфейс, если этого не происходит значит где-то ошибка. > > Сама страница [https://office.yourdomain.ru](https://office.yourdomain.ru) или по IP открывается? всё не могу решить проблему с открыванием офисных документов в seahub\_settings.py всё прописано, страница [https://office.my.ru](https://office.my.ru) открывается но по прежнему “Онлайн-просмотр не применим к этому формату файла” ```auto cat /opt/seafile-data/seafile/conf/seahub_settings.py # -*- coding: utf-8 -*- SECRET_KEY = "***" TIME_ZONE = 'Asia/Tomsk' EMAIL_USE_SSL = True EMAIL_HOST = '' # smpt server EMAIL_HOST_USER = '' # username and domain EMAIL_HOST_PASSWORD = '' # password EMAIL_PORT = DEFAULT_FROM_EMAIL = EMAIL_HOST_USER SERVER_EMAIL = EMAIL_HOST_USER ENABLE_ONLYOFFICE = True ONLYOFFICE_APIJS_URL = 'https://office.my.ru/web-apps/apps/api/documents/api.js' ONLYOFFICE_JWT_SECRET = '***' ONLYOFFICE_FILE_EXTENSION = ('doc', 'docx', 'ppt', 'pptx', 'xls', 'xlsx', 'odt', 'fodt', 'odp', 'fodp', 'ods', 'fods', 'ppsx', 'pps', 'csv') ONLYOFFICE_EDIT_FILE_EXTENSION = ('docx', 'pptx', 'xls', 'csv') OFFICE_PREVIEW_MAX_SIZE = 30 * 1024 * 1024 ONLYOFFICE_FORCE_SAVE = True SERVICE_URL = 'https://drive.my.ru' FILE_SERVER_ROOT = 'https://drive.my.ru/seafhttp' ``` [Предыдущая страница](https://forum.samohosting.ru/t/seafile-onlyoffice-docker-gotovyj-stek-dlya-self-hosted-alternativy-nextcloud/1952.md?page=2)