SSD Nodes Learn Hosting plans →
Руководства Matt ConnorАвтор: Matt Connor

Как развернуть UniFi Controller на VPS

Узнайте, как запустить UniFi Network Application на VPS. Мы разберем требования к RAM, настройку Docker с MongoDB, использование команды set-inform и список портов для защиты.

Что на самом деле делает UniFi controller на VPS

UniFi controller на VPS — это сервер управления, который остается доступным, даже если управляемые им площадки отключаются. Программное обеспечение представляет собой UniFi Network Application от Ubiquiti: Java-приложение, работающее в связке с базой данных MongoDB. Оно настраивает ваши точки доступа и коммутаторы, хранит их статистику и предоставляет интерфейс администратора. Оно не обрабатывает клиентский трафик.

Последний пункт определяет место размещения сервера. Если разместить контроллер на машине внутри офиса, которым он управляет, вы одновременно потеряете и сеть, и инструмент для её мониторинга. Если разместить его на VPS со стабильным публичным IP-адресом, он продолжит работу, продолжит сбор данных и сможет управлять устройствами на нескольких площадках из одного места. Ему требуется время безотказной работы, а не высокая вычислительная мощность.

Когда контроллер находится в офлайне, подключенные точки доступа и коммутаторы продолжают передавать трафик с уже загруженной в них конфигурацией. Вы теряете доступ к панели управления и статистике, а также к функциям, требующим активного контроллера: например, к гостевому порталу или RADIUS (remote authentication dial-in user service), если контроллер выступает в роли вашего RADIUS-сервера. Клиентские соединения при этом не разрываются.

Сколько оперативной памяти требуется для UniFi controller?

Два ГБ — это минимальный порог, а 4 ГБ — рекомендуемый объем. В одном пакете работают два потребителя памяти: Java и MongoDB, и они распределяют ресурсы независимо друг от друга.

Размер кучи Java ограничен параметром MEM_LIMIT, который в образе контейнера по умолчанию установлен на 1024 МБ. Вторая половина приходится на MongoDB. Ее движок хранения WiredTiger выделяет под кэш половину объема оперативной памяти, превышающего 1 ГБ, или 256 МБ (выбирается большее значение). На VPS с 2 ГБ памяти это примерно 512 МБ кэша плюс 1 ГБ кучи, плюс некучевая память JVM и ресурсы операционной системы. Это работает до пиковых нагрузок, после чего OOM-killer (out-of-memory killer) ядра завершает один из двух процессов. После любого необъяснимого перезапуска выполните dmesg -T | grep -i 'killed process', чтобы проверить, не это ли стало причиной. Если у вас всего 2 ГБ, добавьте файл подкачки (swap).

Требования к процессору и диску невысоки. Один или два vCPU справляются с несколькими десятками устройств. Начните с 20 ГБ дискового пространства и следите за ним, так как база данных растет пропорционально количеству клиентов и глубине хранения статистики. Сам по себе контроллер оставляет большую часть ресурсов сервера с 4 ГБ памяти свободными, поэтому, если вы планируете разместить на нем другие сервисы, рассчитывайте объем памяти исходя из их потребностей, так как PhotoPrism и Immich имеют совершенно иные минимальные требования к ОЗУ и каждый из них потребляет больше ресурсов, чем контроллер.

Важна одна особенность процессора, которую легко упустить в дешевых тарифных планах:

grep -m1 -o avx /proc/cpuinfo

MongoDB версии 5.0 и выше требует поддержки AVX (advanced vector extensions) на архитектуре x86_64. Если эта команда ничего не выводит, процесс mongod завершается при запуске, а контейнер уходит в бесконечный цикл перезагрузок, так как бинарный файл пытается выполнить инструкцию, отсутствующую в процессоре. Обычно это происходит на старых процессорах Intel Celeron и Pentium, а также на гипервизорах, которые скрывают флаги процессора от гостевой системы. MongoDB 4.4 — последний релиз, работающий без AVX; образ также поддерживает более старые версии вплоть до 3.6, но поддержка 4.4 прекратилась в феврале 2024 года. MongoDB выпустила сборку 4.4 в декабре 2025 года для исправления CVE-2025-14847, но нет гарантий, что это повторится для следующей уязвимости, а более старые релизы отстают еще сильнее. Лучшее решение — переход на хост с более новым процессором. На ARM VPS этот вопрос не возникает, так как AVX — это набор инструкций x86, а оба образа имеют сборки для arm64. Если вы выбираете между этими вариантами, различия между ARM и x86 VPS не ограничиваются ценой.

Установка UniFi Network Application с помощью Docker Compose

Docker — это путь с наименьшим количеством неожиданностей, так как он позволяет зафиксировать версию MongoDB, поддерживаемую приложением, вместо использования той, что предоставляет ваш дистрибутив. Если Docker еще не установлен, сначала установите Docker на VPS.

mkdir -p ~/unifi/config ~/unifi/db
cd ~/unifi

MongoDB требует наличия пользователя, прежде чем приложение сможет авторизоваться. Официальный образ MongoDB при первом запуске выполняет любой скрипт, найденный в /docker-entrypoint-initdb.d. Сохраните его как ~/unifi/init-mongo.sh:

#!/bin/bash
if which mongosh > /dev/null 2>&1; then
  mongo_init_bin='mongosh'
else
  mongo_init_bin='mongo'
fi
"${mongo_init_bin}" <<EOF
use ${MONGO_AUTHSOURCE}
db.auth("${MONGO_INITDB_ROOT_USERNAME}", "${MONGO_INITDB_ROOT_PASSWORD}")
db.createUser({
  user: "${MONGO_USER}",
  pwd: "${MONGO_PASS}",
  roles: [
    "clusterMonitor",
    { db: "${MONGO_DBNAME}", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_stat", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_audit", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_restore", role: "dbOwner" }
  ]
})
EOF

Этот скрипт выполняется только тогда, когда каталог базы данных пуст. Если запустить стек один раз с неверным паролем, пользователь будет создан с неверными данными, и последующее редактирование файла compose ничего не изменит, так как скрипт больше не запустится. Симптомом является то, что контейнер приложения сообщает об ошибках аутентификации MongoDB, а веб-интерфейс не появляется. При чистой установке решение заключается в остановке стека, удалении ~/unifi/db и повторном запуске.

Затем создайте ~/unifi/compose.yaml:

services:
  unifi-db:
    image: docker.io/mongo:8.0
    container_name: unifi-db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=change-this-root-password
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
      - ./db:/data/db
      - ./init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
    restart: unless-stopped

  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:10.5.67-ls141
    container_name: unifi-network-application
    depends_on:
      - unifi-db
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
      - MEM_LIMIT=1024
      - MEM_STARTUP=1024
    volumes:
      - ./config:/config
    ports:
      - "8080:8080"
      - "3478:3478/udp"
      - "127.0.0.1:8443:8443"
    restart: unless-stopped

Теги обоих образов зафиксированы намеренно. 10.5.67-ls141 был актуальным релизом приложения в августе 2026 года, поэтому проверьте список релизов образа и зафиксируйте версию, актуальную на момент вашей установки. Тег базы данных важнее. MongoDB не обновляет файлы данных между мажорными версиями автоматически, поэтому mongo:latest однажды загрузит новую мажорную версию, откажется открывать найденные файлы и уйдет в бесконечный цикл перезагрузки. Фиксируйте мажорную версию и обновляйте её осознанно. UniFi Network 8.1 и более поздние версии поддерживают MongoDB от 3.6 до 7.0, а в 9.0 добавлена поддержка MongoDB 8.0.

PUID и PGID должны соответствовать реальному пользователю на хосте, иначе файлы в ./config окажутся во владении идентификатора, который не сможет записывать в них данные. Выполните id, чтобы узнать свои значения. как работают PUID и PGID в образах контейнеров описывает, как выглядит несоответствие прав.

Запустите стек и наблюдайте:

docker compose up -d
docker compose ps
docker compose logs -f unifi-network-application

docker compose ps должен показать оба контейнера со статусом running. Если unifi-db завис в состоянии restarting, это либо упомянутая выше проблема с AVX, либо проблема с правами доступа к ./db. Как только вывод лога стабилизируется, проверьте два слушателя:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8443/
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/inform

Любой HTTP-код ответа означает, что слушатель привязан к порту и отвечает. Connection refused означает, что приложение все еще запускается (на небольшом VPS при первом запуске это занимает минуту или две) или что оно не запустилось вовсе.

Доступ к интерфейсу администратора без открытия доступа извне

Порт 8443 опубликован на 127.0.0.1 в файле выше, поэтому в Docker Engine 28.0.0 и более новых версиях никто за пределами VPS не сможет получить доступ к интерфейсу администратора. В более старых релизах другие хосты в том же сегменте L2, например машины в одном сетевом коммутаторе, могут получить доступ к портам, опубликованным на localhost, поэтому выполните docker version и сначала обновитесь, если сервер сообщает о более старой версии. Перенаправьте порт через SSH, чтобы запустить мастер настройки:

ssh -L 8443:127.0.0.1:8443 you@vps.example.com

Оставьте эту сессию открытой и перейдите по адресу https://127.0.0.1:8443. Сертификат является самоподписанным, поэтому браузер выдаст предупреждение один раз. Создайте учетную запись администратора, укажите название сайта и пока пропустите добавление устройств.

SSH-туннель подходит для одного администратора. Для работы в команде назначьте VPS частный адрес и привяжите интерфейс к нему. WireGuard VPN на вашем собственном VPS и subnet router в Tailscale предоставляют адрес, маршрутизация к которому доступна только вашим сотрудникам. Измените опубликованный порт на 10.8.0.1:8443:8443 для WireGuard или на адрес, назначенный Tailscale. Важный нюанс: Docker не может опубликовать порт на адресе, который еще не существует, поэтому интерфейс туннеля должен быть поднят до запуска контейнера, иначе контейнер завершится с ошибкой привязки (bind error).

Почему удаленное устройство UniFi не проходит процедуру адаптации

Сразу после распаковки устройство UniFi находит контроллер с помощью широковещательной рассылки в локальной сети через UDP-порт 10001. Широковещательный трафик не покидает пределы локальной сети, поэтому устройство в офисе другого города не сможет обнаружить контроллер на VPS. Это называется адаптацией на уровне Layer 3, и именно здесь у большинства возникают трудности. С устройством и контроллером всё в порядке, просто устройству не сообщили, где искать контроллер.

Сначала укажите контроллеру, какой адрес передавать устройствам. В настройках контроллера, в разделе System, есть параметр inform host с опцией переопределения (override). Установите его на публичное доменное имя или IP-адрес вашего VPS. Без этого контроллер передает адрес, который видит на своем интерфейсе, а внутри Docker bridge сети это будет частный адрес, например 172.18.0.3. Устройство получает этот адрес, не может построить к нему маршрут и продолжает поиск.

Затем укажите устройству этот адрес. Подключитесь по SSH к устройству в удаленной сети. Устройство с заводскими настройками принимает имя пользователя ubnt и пароль ubnt:

ssh ubnt@192.168.1.20
set-inform http://vps.example.com:8080/inform

В новых версиях прошивки вместо командной оболочки открывается меню. Выполните ту же команду целиком:

ssh ubnt@192.168.1.20 mca-cli-op set-inform http://vps.example.com:8080/inform

Теперь устройство появится в контроллере как готовое к адаптации. Нажмите Adopt, статус изменится на Adopting. Вот момент, который удивляет всех: обычно команду set-inform нужно выполнить второй раз. Устройство перезагружается для применения настроек (provisioning) и возвращается к inform URL, сохраненному в его собственной конфигурации, которую контроллер еще не успел заменить. Повторный ввод команды, пока статус отображается как Adopting, завершает передачу управления. Введите info на устройстве, чтобы увидеть текущий inform URL и состояние.

Если устройство ранее было адаптировано к другому контроллеру, одной команды set-inform будет недостаточно, так как в нем сохранены учетные данные старого контроллера. Сначала выполните сброс до заводских настроек: кнопкой сброса или командой set-default через SSH, используя старые учетные данные.

Если устройств много, используйте DHCP. Опция 43 протокола DHCP (dynamic host configuration protocol) содержит специфическое для производителя значение, и устройства UniFi считывают inform URL из под-опции 2. Сформируйте шестнадцатеричную строку на любом Linux-сервере:

URL="http://vps.example.com:8080/inform"
HEX=$(printf '%s' "$URL" | od -An -tx1 | tr -d ' \n')
printf '02%02x%s\n' "${#URL}" "$HEX"

Для http://192.168.3.10:8080/inform, строки из 31 байта, это выведет 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. Вставьте полученный результат в поле опции 43 DHCP на вашем маршрутизаторе как шестнадцатеричное значение. Каждое устройство, загружающееся в этой сети, получит адрес контроллера из аренды (lease) без необходимости подключения по SSH. В старых руководствах указана под-опция 1, 0104, за которой следуют четыре байта IPv4-адреса в шестнадцатеричном виде; устройства до сих пор принимают этот формат.

Существует третий способ, если вы управляете DNS в этой сети. При загрузке устройство UniFi пытается разрешить имя хоста unifi. Поэтому создание A-записи для unifi, указывающей на адрес вашего VPS, позволит адаптировать устройства без настройки каждого из них по отдельности. Этот метод работает только в том случае, если вы контролируете DNS-резолвер, который фактически используют устройства.

Какие порты UniFi нужно открыть, а какие оставить закрытыми

Два порта должны быть доступны из удаленного сайта для принятия устройств (adoption) и повседневного управления.

  • TCP 8080 — это канал связи (inform channel), к которому подключается каждое принятое устройство. Данные внутри зашифрованы алгоритмом AES с использованием ключа, который контроллер передал устройству при принятии, поэтому обычный HTTP здесь является стандартной настройкой.
  • UDP 3478 — это STUN (session traversal utilities for NAT), который устройства используют для поддержания обратного пути к контроллеру.

Некоторые функции требуют большего. В справочнике портов Ubiquiti указан TCP 5671 для логирования трафика (Traffic Flow) с шлюзов UXG, принятых в сетях L2 или L3. Если на сайте есть UXG, передающий данные этому контроллеру, и вам нужны эти логи, откройте порт 5671 для этого сайта.

Все остальное на VPS должно оставаться закрытым.

  • TCP 8443 — это интерфейс администратора. Он ни в коем случае не должен быть публично доступен. Он содержит конфигурацию всех сайтов, управляемых контроллером, защищенную одним паролем.
  • UDP 10001 и UDP 1900 — это широковещательное обнаружение (broadcast discovery). Широковещательные пакеты не передаются через интернет, поэтому их открытие не дает никакого результата.
  • TCP 8880 и TCP 8843 — это редиректы гостевого портала. Открывайте их только в том случае, если вы используете гостевой портал.
  • TCP 6789 используется для мобильного теста скорости, а UDP 5514 — для удаленного syslog. Открывайте их по мере необходимости.
  • TCP 27117 — это MongoDB. В приведенном выше файле compose база данных не публикует порты, поэтому она существует только во внутренней сети Docker. Оставьте эту настройку без изменений.

Если ваши сайты имеют статические публичные адреса, разрешите доступ только для них:

sudo ufw allow OpenSSH
sudo ufw allow proto tcp from 203.0.113.4 to any port 8080
sudo ufw allow proto udp from 203.0.113.4 to any port 3478
sudo ufw enable
sudo ufw status verbose

В статье основы ufw для межсетевого экрана VPS описана настройка политики запрета по умолчанию, на которой базируются эти правила.

Здесь есть ловушка, в которую постоянно попадают пользователи. Опубликованные порты Docker обходят ufw. Публикация порта записывает правила NAT и пересылки напрямую в iptables, и этот трафик фильтруется в собственной цепочке Docker, а не в цепочке INPUT, которой управляет ufw. Поэтому ufw deny 8443 выглядит корректно в ufw status, в то время как порт остается открытым для всего мира. Проверяйте доступность с другой машины, никогда не делайте этого с самого VPS:

nc -vz vps.example.com 8443

Отказ в соединении или таймаут — это ожидаемый результат. Если соединение устанавливается, значит порт открыт для всех, независимо от настроек ufw. Надежное решение уже применено в файле compose: публикуйте порт на 127.0.0.1 или на адресе туннеля, чтобы Docker никогда не привязывал его к публичному интерфейсу. Правило в цепочке DOCKER-USER также будет работать, но привязка к адресу проще, и ошибка в порядке следования правил не сможет ее отменить.

Как насчет официальных установщиков Ubiquiti?

Ubiquiti выпускает Debian-пакет для Network Application. По состоянию на октябрь 2026 года в справочном центре этот метод помечен как устаревший, а UniFi OS Server назван новым стандартом для самостоятельного хостинга. Пакет работает, но в актуальных версиях Ubuntu возникает проблема с MongoDB, которую дистрибутив больше не решает: в Ubuntu 22.04 и 24.04 нет пакета сервера MongoDB, поэтому приходится вручную добавлять репозиторий MongoDB и подбирать совместимые версии. Контейнер, описанный выше, выполняет это сопоставление в рамках одного зафиксированного тега, поэтому здесь выбран именно этот путь.

Более современный продукт Ubiquiti для самостоятельного хостинга — это UniFi OS Server. Он запускает приложения UniFi в контейнерах Podman и предоставляет ту же UniFi OS, что и аппаратные консоли компании. По состоянию на октябрь 2026 года Ubiquiti требует процессор x86-64, Ubuntu 24.04 или новее (либо Debian 13 или новее), Podman 4.9.3 или новее с slirp4netns 1.2 или новее, не менее 2 ГБ оперативной памяти и 10 ГБ свободного места на диске. Ссылка на установщик на странице релизов или загрузок Ubiquiti привязана к конкретной версии: нажмите правой кнопкой мыши на файл, скопируйте адрес ссылки и загрузите его с помощью curl -O или wget. Каждый релиз имеет собственный URL, поэтому руководство может зафиксировать одну версию, но не может предоставить ссылку, которая всегда будет указывать на самую свежую. Установщик создает systemd-сервис с именем uosserver, управление которым осуществляется через systemctl. Выбирайте этот вариант, если вам нужна официальная упаковка от производителя. Выбирайте контейнерный стек, если хотите самостоятельно фиксировать версии и сохранить сервер свободным для других задач.

Где хранятся резервные копии UniFi и как их выгрузить с сервера

Контроллер создает резервные копии по расписанию, которое вы задаете в разделе Settings, в подразделе backup; там же указывается количество хранимых копий. Файлы сохраняются в /config/data/backup/autobackup внутри контейнера, что соответствует ~/unifi/config/data/backup/autobackup на хостовой системе, и имеют имена вида autobackup_10.5.67_20260813_1200_1755086400004.unf.

Проверьте, что файлы действительно создаются:

ls -l ~/unifi/config/data/backup/autobackup

Если через день после настройки расписания каталог остается пустым, это известная проблема при чистой установке контейнера. Приложение ожидает, что каталог autobackup уже существует, и не создает его самостоятельно, из-за чего задание по расписанию завершается без записи данных. Создайте этот каталог вручную от имени того же пользователя, под которым работает контейнер, а затем дождитесь следующего цикла выполнения:

mkdir -p ~/unifi/config/data/backup/autobackup
docker compose restart unifi-network-application

Файл .unf содержит конфигурацию сайта и учетные записи администраторов, поэтому относитесь к нему как к криптографическому ключу. Копируйте файлы на подконтрольную вам машину и обеспечьте их конфиденциальность:

rsync -av you@vps.example.com:~/unifi/config/data/backup/autobackup/ ~/unifi-backups/

Восстановление выполняется в один шаг. На первой странице мастера настройки при новой установке предлагается восстановить данные из файла резервной копии; в работающем контроллере это можно сделать на той же странице настроек. Восстановление возможно только в ту же или более новую версию приложения. Резервная копия, созданная в более новой версии приложения, чем та, в которую вы пытаетесь выполнить восстановление, будет отклонена. Именно поэтому важно записывать номер версии вместе с файлом резервной копии.

Что может сломаться при обновлении контроллера

Перед каждым обновлением создавайте резервную копию вручную и скачивайте её. Затем:

docker compose pull
docker compose up -d
docker compose logs -f unifi-network-application

База данных — это первое, что выходит из строя. Изменение тега mongo на новую мажорную версию в той же правке, что и само приложение, — самый быстрый способ получить нерабочий контроллер. MongoDB не откроет файлы данных от другой мажорной версии без поэтапного обновления. Обновляйте приложение отдельно. Переносите MongoDB отдельно, по одной мажорной версии за раз, имея под рукой свежую резервную копию.

Память — следующий критический фактор. Более крупный релиз требует большего размера кучи (heap). Если приложение запускается, работает несколько минут и завершается, увеличьте MEM_LIMIT и MEM_STARTUP до 1536 или 2048 и перезапустите сервис. Команда dmesg -T | grep -i 'killed process' на хосте подтвердит, завершает ли процесс ядро системы.

Прошивка устройств — это риск, о котором часто забывают. После обновления контроллер предлагает обновить прошивки для подключенных устройств. Не соглашайтесь на это в рамках одной сессии. Если обновление устройства и контроллера наложатся друг на друга и связь между ними прервётся, устройство может остаться в состоянии частичной настройки. Тогда вам придётся использовать set-inform по SSH на оборудовании, находящемся в другом здании.

Само окно обновления проходит спокойнее, чем кажется. Устройства продолжают передавать трафик во время перезагрузки контроллера, поэтому пользователи ничего не заметят. Перестают работать только гостевой портал и RADIUS, если контроллер их обслуживает, поэтому выбирайте время, когда ими никто не пользуется. Стоит знать, если контроллер тихо отключился в 3 часа ночи, поэтому настройте мониторинг статуса в Uptime Kuma на порт 8080, чтобы получать уведомления.

Честная альтернатива: облачная консоль Ubiquiti

Ubiquiti предлагает аналогичное решение в виде сервиса. По состоянию на октябрь 2026 года в американском магазине Ubiquiti доступна услуга Official UniFi Hosting по цене от 29 долларов в месяц. Она позволяет управлять до 1000 устройств UniFi Network на сервере, который обслуживает сама компания Ubiquiti. Самостоятельно развернутое приложение, которое вы только что установили, является бесплатным и не требует подписки.

Выбирайте облачную консоль, если вы управляете одним объектом и предпочитаете платить за сервис, а не заниматься обновлением ПО. Выбирайте VPS, если вы управляете несколькими объектами или хотите, чтобы контроллер находился внутри контролируемой вами сети и работал на одном сервере с другими вашими сервисами. Разница в стоимости при небольших масштабах существенна, но это не единственный фактор: облачная консоль означает, что за время безотказной работы отвечает кто-то другой, а в случае с VPS ответственность лежит на вас, включая ситуации, когда на диске заканчивается место. Если сервер в любом случае будет полезен, что еще можно запустить на VPS — это список, который стоит изучить далее.

FAQ

Почему мое устройство UniFi не подключается к контроллеру на VPS?

Устройства обнаруживают контроллеры через широковещательные рассылки по UDP порту 10001. Широковещательный трафик не покидает пределы локальной сети, поэтому устройство в удаленном офисе не может найти контроллер в публичном интернете. Укажите адрес вашего VPS в настройках контроллера (параметр inform host override), а затем направьте на него устройство с помощью команды ssh ubnt@<device-ip>, за которой следует set-inform http://vps.example.com:8080/inform. Если устройство зависло в состоянии Adopting, выполните set-inform повторно, пока оно находится в этом статусе. Если устройство ранее было привязано к другому контроллеру, сначала выполните сброс до заводских настроек, так как в нем сохранены учетные данные старого контроллера.

Сколько оперативной памяти нужно для self-hosted контроллера UniFi?

Два ГБ — это минимальный рабочий объем, 4 ГБ — комфортный. Приложение состоит из Java и MongoDB, которые используют память по-разному: образ контейнера по умолчанию ограничивает Java heap до 1024 МБ, а кэш WiredTiger в MongoDB занимает половину объема RAM сверх 1 ГБ. На архитектуре x86_64 также убедитесь, что процессор поддерживает AVX с помощью grep -m1 -o avx /proc/cpuinfo, так как MongoDB 5.0 и более поздние версии не запустятся без этой инструкции, из-за чего контейнер базы данных будет постоянно перезагружаться.

Стоит ли открывать порт 8443 в интернет?

Нет. Порт 8443 — это интерфейс администратора, содержащий конфигурацию всех сайтов, которыми управляет контроллер. Опубликуйте его на 127.0.0.1 с помощью Docker Engine 28.0.0 или новее и подключайтесь через ssh -L 8443:127.0.0.1:8443 you@vps.example.com, либо привяжите его к адресу WireGuard или Tailscale. Для процесса адаптации и управления вашим сайтам необходим доступ к TCP 8080 и UDP 3478, а также к TCP 5671, если шлюз UXG отправляет логи Traffic Flow на контроллер. Вы можете ограничить доступ к этим портам, разрешив его только для публичных IP-адресов ваших сайтов, если они статические. Помните, что порт, опубликованный через Docker, не фильтруется утилитой ufw, поэтому проверяйте доступность с внешнего устройства, а не полагайтесь на ufw status.

Перестанет ли работать сеть, если контроллер на VPS отключится?

Нет. Адаптированные точки доступа и коммутаторы продолжают передавать трафик, используя конфигурацию, которую контроллер уже загрузил в них. Клиенты остаются подключенными, Wi-Fi продолжает работать. Прекращается только управление. Вы теряете доступ к панели мониторинга и сбору статистики, а также к функциям, которые предоставляет контроллер в реальном времени, например, к авторизации в гостевом портале или RADIUS, если контроллер выступает в роли RADIUS-сервера.

Где контроллер UniFi хранит автоматические резервные копии?

В используемом здесь образе контейнера они сохраняются в /config/data/backup/autobackup, который отображается на путь к вашим данным плюс data/backup/autobackup на хосте, в виде файлов .unf, названных по версии и метке времени. При некоторых чистых установках каталог autobackup не создается, и запланированное резервное копирование не записывает данные, не сообщая об ошибке. Поэтому проверьте содержимое этого каталога через день после настройки расписания и создайте его вручную, если он пуст. Копируйте файлы с VPS, так как .unf содержит конфигурацию сайта и учетные записи администраторов.

#unifi#ubiquiti#network-management#docker#self-hosting