Self-hosted файлові менеджери: порівняння 4 рішень

Що таке self-hosted файловий менеджер і чим він не є

Self-hosted файловий менеджер — це вебсторінка над деревом каталогів, яке вже існує на вашому VPS (virtual private server). Ви входите в систему, бачите /srv/files саме в тому вигляді, у якому вони зберігаються на диску, а також завантажуєте, перейменовуєте, завантажуєте на свій пристрій файли або передаєте комусь посилання. Нічого не копіюється в окрему систему, тому файл, який ви додали через браузер, через секунду вже показує ls.

У результатах пошуку це часто змішують із програмами для інших завдань. Засоби синхронізації зберігають копію кожного файла на кожному пристрої — саме для цього призначена self-hosted альтернатива Dropbox. Object storage взагалі не має дерева каталогів: він використовує buckets і API, тому розгортання MinIO для S3-сумісного object storage відповідає на інше питання. Панелі адміністрування сервера керують машиною, а не файлами. Саме про це йдеться в порівнянні Cockpit і Webmin.

Файловий менеджер потрібен, коли колезі треба отримати із сервера один архів розміром 300 MB або коли ви хочете виправити друкарську помилку в конфігураційному файлі з телефона. Завдання невелике, тому й інструменти мають бути простими.

Під час читання пам’ятайте про один факт. Це вебзастосунок із доступом на читання та запис до вашої файлової системи, який прослуховує порт. Кожен описаний нижче вибір фактично визначає, до якої частини диска цей процес може отримати доступ.

FileBrowser заархівовано: прочитайте це перед встановленням

FileBrowser, проєкт filebrowser/filebrowser, і досі є відповіддю в більшості інструкцій. Тепер його README починається з такого повідомлення:

File Browser буде заархівовано 2026-09-01. Останній запланований реліз уже випущено. Подальших релізів, виправлень помилок або security fixes не буде.

Код за ліцензією Apache 2.0 продовжує працювати. Випуск security fixes припиняється. Для цієї категорії це важливіше, ніж для більшості інших, оскільки основне призначення цього ПЗ — надавати доступ на запис до файлової системи через HTTP.

Мейнтейнери описали, як і надалі запускати цей сервіс. Цієї поради варто дотримуватися незалежно від вибраного інструмента: не відкривайте його безпосередньо в інтернет, розмістіть за reverse proxy, який завершує TLS (transport layer security) і виконує власну автентифікацію, залиште command runner вимкненим і запускайте сервіс без привілеїв у контейнері, змонтувавши в нього лише каталог, який потрібно опублікувати.

Один рядок у цьому README важливіший за решту. Сеанси є самодостатніми JWT (JSON web tokens), а не ідентифікаторами на стороні сервера, тому їх неможливо відкликати. Викрадений токен сеансу залишається чинним до завершення терміну його дії, а зміна пароля його не анулює. Якщо ви залишаєте FileBrowser, саме authentication layer перед ним виконує основну роботу.

FileBrowser Quantum: форк, який досі активно розвивається

Активна розробка перемістилася до форку FileBrowser Quantum (gtsteffaniak/filebrowser), який публікується як образ gtstef/filebrowser. У ньому конфігурацію перебудовано навколо одного config.yaml замість старої комбінації прапорців командного рядка та параметрів бази даних. Документований швидкий запуск:

docker run -d \
  -v $(pwd):/srv \
  -p 80:80 \
  gtstef/filebrowser:beta

Він надає поточний каталог за адресою http://localhost, а для першого входу використовуються admin / admin. Змініть ці дані, перш ніж контейнер стане доступним не лише з вашого комп’ютера.

Для постійного використання застосуйте Compose, змонтуйте каталог даних, а не окремий файл бази даних, і прив’яжіть порт до localhost:

services:
  filebrowser:
    image: gtstef/filebrowser:beta
    user: "1000:1000"
    volumes:
      - /srv/files:/folder
      - ./data:/home/filebrowser/data
    ports:
      - 127.0.0.1:8080:80
    restart: unless-stopped

Конфігурація зберігається в /home/filebrowser/data/config.yaml, а база даних — у /home/filebrowser/data/filebrowser.sqlite. У версії 2.0.0 змінено формат бази даних і додано одноразову міграцію. Саме тому документація рекомендує монтувати каталог: під час монтування окремого файла міграції нікуди записати новий файл. Шляхи всередині config.yaml є шляхами контейнера, тому source у конфігурації читає /folder, а не /srv/files. Якщо переплутати ці шляхи, список файлів буде порожнім без повідомлення про помилку, оскільки каталогу справді немає.

Проєкт публікує latest і stable розміром приблизно 60 MB із вбудованим FFmpeg для ескізів відео, а також stable-slim розміром приблизно 15 MB лише з основними компонентами. Це дані зі сторінки встановлення за August 2026. Зафіксуйте вибраний tag. latest змінюється без попередження, а файловий менеджер, який змінює формат конфігурації під час роботи контейнера, може спричинити серйозні проблеми.

Для цього завдання це найпотужніший серед невеликих інструментів. Він обслуговує кілька джерел із правилами включення та виключення, тому один екземпляр може надавати доступ до /srv/media і /srv/docs з різним рівнем охоплення. Для спільних ресурсів можна задати час завершення дії, а доступ до них може бути анонімним або обмеженим користувачем. Автентифікація підтримує OIDC (OpenID Connect), LDAP (lightweight directory access protocol), пароль із двофакторною автентифікацією та режим proxy header. Саме цей режим дає змогу розмістити сервіс за single sign on (SSO) від self-hosted сервера Authentik, не підтримуючи окремий список користувачів.

Filestash: один інтерфейс для наявних сховищ

Filestash має іншу архітектуру. Це фронтенд, який підключається до бекенду, а список підтримуваних бекендів великий: FTP, SFTP (протокол передавання файлів через SSH), S3, SMB, WebDAV, IPFS і ще близько двадцяти варіантів. Він підходить, коли файли зберігаються не на сервері, де запущено інтерфейс.

mkdir -p /srv/filestash && cd /srv/filestash
curl -O https://downloads.filestash.app/latest/docker-compose.yml
docker compose up -d

Образ має назву machines/filestash:latest. Відкрийте http://your_domain:8334, і на першому екрані задайте пароль адміністратора. Зробіть це негайно, оскільки до цього моменту консоль адміністратора доступна всім, хто виявить цей порт.

Перш ніж будувати рішення на його основі, розберіться з моделлю ідентифікації. Filestash не зберігає базу користувачів у звичному розумінні. Облікові дані зберігаються у браузері в зашифрованих, автентифікованих cookie з атрибутом HTTP only. На стороні сервера нічого не зберігається, якщо не використовувати функцію спільного доступу. У такому разі Filestash зберігає постійну зашифровану версію облікових даних. "Користувачі" — це облікові записи сховищ: ідентичність визначається на бекенді, в обліковому записі SFTP або ключі S3, а не у Filestash.

Ця архітектура проста, але має свою ціну. На сторінці з тарифами безкоштовний self-hosted рівень зазначено як AGPL v3 (GNU Affero General Public License) для 3 користувачів, а SSO (SAML, OIDC і LDAP) разом із рольовим керуванням доступом доступні в платному self-hosted рівні від $50 на місяць станом на August 2026. Якщо ви планували "безкоштовно розмістити Filestash перед корпоративним SSO", перевірте цю сторінку до проєктування рішення на його основі.

SFTPGo: сервер протоколів із вебінтерфейсом

SFTPGo — найфункціональніше програмне забезпечення в цьому огляді, але його найчастіше рекомендують з неправильної причини. Воно підтримує SFTP, HTTP/S, FTP/S і WebDAV та працює з локальною файловою системою, зашифрованою локальною файловою системою, S3-сумісним об’єктним сховищем, Google Cloud Storage, Azure Blob Storage або іншим SFTP-сервером.

Опубліковано бінарні файли, пакети для Debian і Ubuntu та образ контейнера. Актуальний рядок для APT-репозиторію та ключ підпису наведено на сторінці встановлення в документації SFTPGo. Варіант із контейнером — найшвидший спосіб запустити SFTPGo; замініть tag на потрібну версію:

docker run --name some-sftpgo -p 8080:8080 -p 2022:2022 -d "drakkan/sftpgo:tag"

SFTP працює на порту 2022, а вебінтерфейси — на порту 8080. Змонтуйте /srv/sftpgo як том. Інакше облікові записи та їхні файли зникнуть після повторного створення контейнера, оскільки домашні каталоги користувачів за замовчуванням розташовані в /srv/sftpgo/data/<username>.

Є два вебінтерфейси, і саме їхню відмінність у більшості описів залишають без пояснення. WebAdmin за адресою /web/admin призначений для адміністрування. У ньому створюють користувачів, групи, віртуальні папки та правила подій, а також налаштовують квоти, обмеження пропускної здатності й обмеження часу доступу. WebClient за адресою /web/client — це інтерфейс кінцевого користувача. У ньому можна переглядати файли, змінювати власні облікові дані, налаштовувати двофакторну автентифікацію та створювати спільні посилання.

Спільні посилання тут найкращі серед розглянутих варіантів. Користувач може створювати HTTP/S-посилання для спільного доступу до файлів і папок, обмежувати кількість завантажень і вивантажень, захищати спільний доступ паролем, обмежувати доступ за вихідною IP-адресою та встановлювати автоматичну дату завершення дії.

Чому ж потрібна обережність? Основна увага приділена моделі облікових записів і серверу протоколів, а не зручності перегляду файлів. Обирайте SFTPGo, якщо іншим людям потрібні повноцінні облікові записи з квотами, якщо завантаження надходять через SFTP або FTPS із системи, якою ви не керуєте, або якщо один bucket має відображатися в домашніх каталогах кількох користувачів. Віртуальні папки дають змогу реалізувати останній сценарій: папку на основі локального диска, S3, GCS, Azure Blob, SFTP або HTTP можна змонтувати в кількох облікових записах і встановити окрему квоту для кожного користувача спільної папки. Якщо вам потрібна лише вебсторінка для перегляду /srv/files, це надмірно складна система для такого завдання.

Варто врахувати ще два факти. Редакція Community поширюється за ліцензією AGPL-3.0-only з додатковими умовами, а паралельно існує комерційно ліцензована редакція Enterprise. Відкритий варіант підтримує вхід через OIDC і зіставляє користувачів постачальника ідентифікації з адміністраторами та користувачами SFTPGo в обох вебінтерфейсах. Клієнтський інтерфейс також можна глобально вимкнути за допомогою enable_web_client у конфігурації httpd або окремо для користувача, додавши HTTP до списку заборонених протоколів цього користувача. Так файловий менеджер може бути доступним одній людині, але не всім користувачам.

Cloud Commander: дві панелі та термінал для одного користувача

Cloud Commander — це ліцензований за MIT Node.js-менеджер у форматі двох панелей із вбудованим редактором, консоллю та терміналом. Встановіть його глобально за допомогою npm i cloudcmd -g або запустіть опублікований контейнер:

docker run -it --rm -v ~:/root -v /:/mnt/fs -w=/root -p 8000:8000 coderaiser/cloudcmd

Прочитайте цю команду перед запуском. -v /:/mnt/fs монтує всю файлову систему хоста в контейнер, а приклад ~/.cloudcmd.json передає "root": "/", "auth": false і "console": true. У результаті кожен, хто має доступ до порту 8000, отримує доступ до всього диска та командної консолі на сервері. Для ноутбука це прийнятне налаштування за замовчуванням, але для VPS — небезпечне.

Обмежте область доступу. Контейнер читає /root/.cloudcmd.json, який опублікована команда передає через монтування домашнього каталогу. Тому залиште монтування конфігурації та приберіть решту:

docker run -d --name cloudcmd \
  -v ~/.cloudcmd.json:/root/.cloudcmd.json \
  -v /srv/files:/srv/files \
  -w=/srv/files \
  -p 127.0.0.1:8000:8000 \
  coderaiser/cloudcmd

У цьому конфігураційному файлі встановіть "root" у значення /srv/files, "auth" — у значення true за допомогою "username" і "password", а "console" та "terminal" — у значення false, якщо вам справді не потрібен shell-доступ через браузер. Також доступні еквіваленти для командного рядка, зокрема --root, --auth, --username, --password і --prefix.

Чітко визначте його призначення. Є одна пара облікових даних, але немає окремих обмежень для користувачів, квот або посилань для спільного доступу. Це персональний інструмент, тому прив’яжіть його до localhost, як показано вище, і підключайтеся через тунель:

ssh -L 8000:127.0.0.1:8000 you@your-vps

Потім відкрийте http://127.0.0.1:8000 на власному комп’ютері. Файловий менеджер не буде доступний публічно, а єдиним компонентом, доступним з інтернету, залишиться вже захищений вами на VPS демон SSH.

Чому Nextcloud не підходить для цього завдання

Nextcloud — якісне програмне забезпечення, але для цього завдання воно не підходить. Це платформа для спільної роботи: PHP-застосунок, база даних, фонові завдання, клієнти синхронізації для настільних систем і магазин застосунків. Запуск Nextcloud, щоб отримати вебперегляд /srv/files, створює забагато компонентів для невеликого завдання, а також має конкретну невідповідність. Nextcloud зберігає метадані файлів у таблиці бази даних, а не читає каталог під час кожного запиту. Тому файли, записані через rsync або завдання cron, можуть залишатися невидимими в інтерфейсі, доки сканування не завершиться, разом із sudo -u www-data php occ files:scan --all. Файловий менеджер читає каталог під час завантаження сторінки, тому такої затримки немає.

Використовуйте Nextcloud для завдань, з якими він добре справляється: календарів, контактів, синхронізації та спільного доступу для користувачів, яким потрібен клієнт для настільної системи. У матеріалі Nextcloud на VPS з Docker, TLS і резервними копіями описано таке налаштування. Якщо Nextcloud уже запущено і вам потрібно лише переглядати наявний каталог, увімкніть застосунок External Storage і на цьому зупиніться. Другий вебзастосунок із правом запису на той самий диск — це ще один компонент, який потрібно оновлювати й виправляти.

Як запустити його, не відкриваючи доступ до всього сервера

Ніколи не вказуйте /. Процес може читати й записувати все, до чого має доступ його обліковий запис користувача. Тому викрадений маркер сеансу надає саме такий доступ до файлової системи. Надайте доступ до одного каталогу, /srv/files, і створіть його спеціально для цього.

Запускайте процес від імені non-root користувача та монтуйте лише каталоги, які він обслуговує. У Compose це означає user: "1000:1000" плюс одне bind-монтування для кожного каталогу. Для всього, куди процесу не потрібно записувати, використовуйте :ro:

    volumes:
      - /srv/files:/folder
      - /srv/media:/media:ro

Зазвичай після цієї зміни перегляд працює, а завантаження файлів завершується помилкою permission denied, оскільки user id усередині контейнера не є власником каталогу за його межами. Порівняйте ці значення: docker exec filebrowser id виводить користувача контейнера, а ls -ln /srv/files — числовий ідентифікатор власника на хості. Виправте це за допомогою sudo chown -R 1000:1000 /srv/files. Це та сама проблема з правами власності, яку вирішують PUID і PGID в Docker images.

Прив’яжіть опублікований порт до localhost через 127.0.0.1:8080:80, а не через 8080:80. Docker записує власні правила netfilter перед правилами ufw, тому звичайний опублікований порт залишається доступним з інтернету, навіть коли активний ufw deny 8080. Розмістіть reverse proxy перед застосунком для TLS. Через звичайний HTTP cookie сеансу передається мережею у відкритому вигляді, а цей cookie надає доступ до файлової системи. Якщо Compose для вас новий, у матеріалі Docker Compose на VPS описано структуру файлів, яку передбачають ці фрагменти.

Додайте рівень автентифікації, якщо вбудований захист застосунку обмежений. HTTP basic auth на proxy достатньо для окремого екземпляра одного користувача. Якщо користувачів більше одного, використовуйте OIDC або forward auth через identity provider, щоб відкликання одного облікового запису припиняло доступ до всіх сервісів.

Вимкніть додаткові функції. Будь-який file manager із shell, засобом виконання команд або терміналом у браузері надає віддалене виконання коду кожному, хто має чинний сеанс. У власних рекомендаціях FileBrowser радить залишати засіб виконання команд вимкненим, а приклад конфігурації Cloud Commander вмикає консоль. Приймайте це рішення свідомо, а не залишайте значення за замовчуванням.

Що виходить із ладу першим і які помилки ви побачите

listen tcp :80: bind: permission denied. Linux резервує порти нижче 1024 для привілейованих процесів. У задокументованій конфігурації FileBrowser Quantum використовується порт 80. Це працює всередині контейнера, але одразу перестає працювати, якщо запустити бінарний файл на хості від непривілейованого користувача. Вкажіть порт вище 1024 у config.yaml, а порт 443 залиште reverse proxy.

Завантаження не працює, але перегляд працює. Для перегляду каталогу потрібен r-x, а для запису до нього — w. Вебінтерфейс показує загальну помилку, тому спочатку перевірте файлову систему, а не журнали застосунку.

413 Request Entity Too Large. Цю помилку повертає nginx, а не файловий менеджер. Типове значення client_max_body_size — 1 MB, тому проксі відхиляє більший файл ще до того, як його побачить застосунок. Укажіть client_max_body_size 4096m; у блоці server або використайте 0, щоб вимкнути перевірку.

Завантажені файли мають неправильну групу. Нові файли належать користувачу, від імені якого працює процес, незалежно від налаштувань батьківського каталогу. Через це другий сервіс не може читати те саме дерево каталогів. Надайте обом сервісам спільну групу та встановіть біт setgid для каталогу за допомогою sudo chmod g+s /srv/files. Тоді нові файли успадковуватимуть групу каталогу.

На порту все працює, але за проксі — ні. Застосунок, доступний через підшлях, формує посилання на основі префікса, який потрібно йому явно передати. У Cloud Commander для цього є --prefix. Якщо такого параметра немає, виділіть для застосунку окремий субдомен і проксуюйте кореневий шлях.

Який self-hosted файловий менеджер варто використовувати?

• Один VPS, один або два каталоги, посилання для спільного доступу зі строком дії та, можливо, SSO у майбутньому: FileBrowser Quantum.
• Файли зберігаються в іншому місці — у S3 bucket, на SFTP-хості або NAS через SMB — і потрібне одне веб-представлення для всіх джерел: Filestash у межах обмежень безкоштовного тарифу.
• Іншим користувачам потрібні облікові записи, квоти та передавання файлів через SFTP або FTPS: SFTPGo. Вебклієнт у цьому разі є корисним додатковим компонентом, а не основною причиною вибору.
• Персональний інструмент із редактором і терміналом, доступний через SSH-тунель і ніколи не опублікований у мережі: Cloud Commander.
• Nextcloud уже працює, і потрібно відкрити доступ до наявного каталогу: застосунок External Storage — без встановлення нового програмного забезпечення.

Незалежно від вибору, спосіб розгортання важливіший за сам продукт. Один каталог, користувач без прав root, порт, прив’язаний до localhost, і автентифікація перед застосунком. Файловий менеджер, налаштований так, є зручним інструментом. Те саме програмне забезпечення, спрямоване на / і захищене спільним паролем, перетворюється на віддалену оболонку зі зручним інтерфейсом.

FAQ

Чи безпечно використовувати FileBrowser у 2026 році?

У README проєкту filebrowser/filebrowser зазначено, що File Browser буде заархівовано 2026-09-01. Подальших релізів, виправлень помилок і security fixes не буде. Код і надалі працює, але невиправлене програмне забезпечення з правом запису у файлову систему з часом створює дедалі більший ризик. Якщо ви продовжуєте його використовувати, дотримуйтеся рекомендацій самого проєкту: не відкривайте сервіс безпосередньо в інтернет, використовуйте reverse proxy з TLS і власною автентифікацією, залиште command runner вимкненим і запускайте сервіс у непривілейованому контейнері, змонтувавши лише каталог, який він обслуговує. Також врахуйте, що його сесії — це самодостатні JWT, а не ідентифікатори на стороні сервера. Тому їх неможливо відкликати, а зміна пароля не робить уже виданий токен недійсним. Для нової інсталяції використовуйте форк FileBrowser Quantum, опублікований як образ gtstef/filebrowser, розробка якого триває.

Чи може self-hosted файловий менеджер використовувати наявний SSO?

FileBrowser Quantum підтримує OIDC, LDAP і режим proxy header. Тому його можна розмістити за наявним identity provider без окремого списку користувачів. Інтеграція SFTPGo з OpenID Connect доступна у збірці з відкритим кодом. Вона зіставляє користувачів identity provider з адміністраторами та користувачами SFTPGo в інтерфейсах WebAdmin і WebClient. У Filestash є важливе обмеження: на сторінці тарифів SSO (SAML, OIDC і LDAP) належить до платного self-hosted рівня вартістю $50 на місяць станом на August 2026, тоді як безкоштовний рівень має статус AGPL v3 і підтримує до 3 користувачів. Якщо застосунок взагалі не підтримує SSO, можна використати forward authentication на reverse proxy. Це захищає сторінку входу, але не змінює внутрішні дозволи самого застосунку.

У якого з цих рішень є посилання на спільний доступ, що зазнають строку дії?

У SFTPGo найповніша реалізація. Користувач створює HTTP/S-посилання у WebClient і може обмежити кількість завантажень і вивантажень, установити пароль, обмежити доступ за IP-адресою джерела та задати автоматичну дату завершення дії. FileBrowser Quantum підтримує спільні ресурси зі строком дії. Доступ може бути анонімним або обмеженим для певного користувача. Також для кожного ресурсу можна окремо налаштувати дозволи на перегляд, редагування та вивантаження. У Filestash також є функція спільного доступу. Це єдиний випадок, коли сервер зберігає постійну зашифровану копію облікових даних для доступу до сховища, оскільки посилання має працювати після завершення сесії браузера. У Cloud Commander посилань на спільний доступ немає.

Чи безпечно вказувати файловому менеджеру /, якщо я єдиний користувач?

Ні. Ризик пов’язаний не з тим, чи довіряєте ви собі. Процес має права на читання і запис усього, до чого має доступ його обліковий запис. Тому будь-який шлях до цієї сесії, викрадений cookie, невиправлена помилка в обробнику вивантажень або повторно використаний пароль надає доступ до /etc, ваших SSH-ключів і каталогів даних усіх сервісів. Обмежте монтування одним каталогом: /srv/files замість /. Найбільший ризик це створює для Cloud Commander, оскільки його опублікована команда Docker монтує кореневий каталог хоста в /mnt/fs, а приклад конфігурації задає "root": "/" зі значенням "auth": false. Змініть обидва параметри, перш ніж цей контейнер почне приймати з’єднання не лише з localhost.