ガイド

著者 Matt Connor 2026-10-12

VPSでUniFiコントローラーを運用する方法

Q: UniFi controller は automatic backup をどこに保存しますか？

ここで使用する container image では、バックアップは /config/data/backup/autobackup に保存されます。このパスは host 上の data path に data/backup/autobackup を加えた場所へ対応し、.unf ファイルとして version と timestamp を含む名前が付けられます。一部の新規 install では autobackup directory が存在せず、scheduled backup がエラーを報告しないまま何も書き込まないことがあります。schedule を設定した翌日にその directory の内容を確認し、空であれば自分で作成してください。.unf には site configuration と administrator account が含まれるため、ファイルを VPS の外部へコピーしてください。

UniFi Network ApplicationをVPSで運用する手順です。RAMの目安、MongoDB付きDocker構成、set-informによるLayer 3 adopt、非公開にするポートを解説します。

VPS 上の UniFi コントローラーが実際に行うこと

VPS 上の UniFi コントローラーは、管理対象のサイトが停止しても到達可能な管理サーバーです。ソフトウェアは Ubiquiti の UniFi Network Application で、MongoDB データベースを背後に持つ Java プログラムです。アクセスポイントとスイッチを設定し、統計情報を保存して、管理インターフェースを提供します。クライアントのトラフィックを転送するものではありません。

この点によって、配置すべき場所が決まります。管理対象のオフィス内のマシンにコントローラーを置くと、ネットワークと、そのネットワークを確認するためのツールを同時に失うことになります。安定したパブリックアドレスを持つ VPS に置けば、稼働と収集を継続でき、複数サイトのデバイスを 1 か所から adopt できます。必要なのは処理能力ではなく、稼働時間です。

コントローラーがオフラインでも、adopt 済みのアクセスポイントとスイッチは、すでに適用された設定でトラフィックの転送を続けます。ダッシュボードと統計情報に加え、コントローラーの稼働を必要とする機能も利用できなくなります。たとえば、ゲストポータルのログインや、コントローラーを RADIUS (remote authentication dial-in user service) サーバーとして使用している場合の RADIUS です。クライアントの接続は維持されます。

UniFi controller にはどの程度の RAM が必要ですか？

2 GB が最低ラインで、購入すべき容量は 4 GB です。1 台のサーバーでは Java と MongoDB がメモリを消費し、それぞれ独立してメモリを確保します。

Java ヒープの上限は MEM_LIMIT で決まり、コンテナイメージではデフォルトで 1024 MB に設定されています。もう一方が MongoDB です。MongoDB の WiredTiger ストレージエンジンは、1 GB を超える RAM の半分、または 256 MB のうち、大きい方をキャッシュ容量として確保します。2 GB の VPS では、約 512 MB のキャッシュ、1 GB のヒープ、JVM 自体の非ヒープメモリ、オペレーティングシステムがメモリを使用します。通常は動作しますが、負荷の高い日にはカーネルの OOM Killer がいずれかのプロセスを終了させます。原因不明の再起動が発生したら、dmesg -T | grep -i 'killed process' を実行して確認してください。利用できる RAM が 2 GB しかない場合は、swap ファイルを追加してください。

CPU とディスクの要件は高くありません。vCPU が 1 つまたは 2 つあれば、数十台のデバイスを処理できます。まず 20 GB のディスクを割り当てて、使用量を監視してください。データベースの容量は、接続するクライアント数と統計情報の保持期間に応じて増加します。UniFi controller だけなら 4 GB のサーバーの大部分は空いたままです。別のサービスも同居させる予定なら、先にそのサービスの要件に合わせてください。PhotoPrism と Immich では必要な RAM の最低容量が大きく異なり、どちらも UniFi controller より多くの RAM を要求するためです。

安価なプランでは見落としやすい、重要な CPU 機能が 1 つあります。

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 以降を x86_64 ハードウェアで実行するには、AVX (advanced vector extensions) が必要です。このコマンドが何も出力しない場合、mongod は起動時に終了し、コンテナは再起動を繰り返します。CPU に存在しない命令をバイナリが実行するためです。古い Intel Celeron や Pentium を搭載したホストが一般的な原因です。ハイパーバイザーがゲストから CPU フラグを隠している場合も同様です。MongoDB 4.4 は AVX なしで動作する最新のリリースです。このイメージは 3.6 までの古いバージョンにも対応していますが、MongoDB 4.4 は 2024 年 2 月にサポート終了となりました。MongoDB は 2025 年 12 月の CVE-2025-14847 向け修正で 4.4 のビルドも提供しましたが、次の脆弱性でも同じ対応が行われる保証はありません。さらに古いリリースは、より長期間更新から取り残されています。新しい CPU を搭載したホストへ移行することを推奨します。ARM VPS ではこの問題は発生しません。AVX は x86 の命令セットであり、どちらのイメージも arm64 ビルドを公開しているためです。2 つの構成で迷っている場合は、ARM と x86 の VPS プランの違いは価格以外にもあります。

Docker Compose で UniFi Network Application をインストールする

Docker を使う方法が最も問題が少なくて済みます。ディストリビューションが提供するバージョンに任せず、アプリケーションがサポートするバージョンに MongoDB を固定できるためです。まだ Docker がホストにない場合は、先に VPS に Docker をインストールするを実行してください。

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 の認証失敗が記録される一方、Web インターフェースが表示されないのが典型的な症状です。新規インストールであれば、スタックを停止し、~/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 年 8 月時点の現行アプリケーションリリースでした。インストール時にはイメージのリリース一覧を確認し、その時点の現行バージョンを固定してください。データベースのタグはさらに重要です。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 と表示されるはずです。restarting のまま停止している unifi-db は、前述の AVX の問題か、./db の権限問題が原因です。ログが落ち着いたら、2 つのリスナーを確認します。

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 で 1、2 分かかることがあります。あるいは、アプリケーションが起動していない可能性もあります。

管理インターフェースに外部公開せずアクセスする

上のファイルでは、ポート 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 にアクセスします。証明書は自己署名証明書のため、ブラウザーに警告が 1 回表示されます。管理者アカウントを作成し、サイト名を設定します。デバイスの採用は、ここではスキップしてください。

SSH トンネルは、管理者が 1 人だけの場合に適しています。チームで利用する場合は、VPS にプライベートアドレスを割り当て、インターフェースをそのアドレスにバインドしてください。自分の VPS 上の WireGuard VPN と Tailscale のサブネットルーターのどちらでも、利用者だけがルーティングできるアドレスを取得できます。WireGuard の場合は公開ポートを 10.8.0.1:8443:8443 に変更します。Tailscale の場合は、Tailscale が割り当てたアドレスに変更します。注意点があります。Docker は、まだ存在しないアドレスには公開できません。そのため、コンテナの起動前にトンネルインターフェースを起動する必要があります。起動していない場合、コンテナは bind エラーで失敗します。

リモートの UniFi デバイスが adopt されない理由

初期状態では、UniFi デバイスはローカルネットワーク上で UDP ポート 10001 にブロードキャストを送信し、controller を検出します。ブロードキャストは LAN の外へ出ないため、別の都市のオフィスにあるデバイスが VPS 上の controller を検出することはありません。これは Layer 3 adoption であり、多くの人がつまずく箇所です。デバイスにも controller にも問題はありません。デバイスに検索先を伝えていないだけです。

まず、controller から通知するアドレスを設定します。controller の Settings の System セクションに、override オプション付きの inform host 設定があります。これを VPS の公開 hostname または IP に設定します。設定しない場合、controller は自身のインターフェースで認識したアドレスを通知します。Docker bridge network 内では、172.18.0.3 のようなプライベートアドレスになります。デバイスはそのアドレスを受け取りますが、そこへルーティングできないため、再び検索を開始します。

次に、デバイスの接続先をそのアドレスに変更します。リモート LAN 上のデバイスへ SSH 接続します。工場出荷時のデバイスでは、ユーザー名 ubnt とパスワード ubnt を使用できます。

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

新しいデバイス firmware では、shell ではなくメニューが表示されます。同じ操作を単一のコマンドとして実行します。

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

これで、デバイスが controller に adopt 待ちとして表示されます。Adopt をクリックすると、状態が Adopting に変わります。ここで意外に思われやすい点があります。通常は set-inform をもう一度実行する必要があります。デバイスは provisioning のために再起動し、自身の設定に保存された inform URL に戻ります。controller による置き換えがまだ完了していないためです。状態が Adopting の間にコマンドを再度実行すると、引き継ぎが完了します。デバイス上で info と入力すると、現在保持している inform URL と状態を確認できます。

デバイスが以前に別の controller で adopt されていた場合、set-inform だけでは完了しません。以前の controller の認証情報が残っているためです。まず、reset ボタンを使うか、古い認証情報で SSH 接続して set-default を実行し、工場出荷時の状態に戻します。

数台を超えるデバイスでは、代わりに DHCP を使用します。DHCP（dynamic host configuration protocol）の option 43 はベンダー固有の値を運び、UniFi デバイスは suboption 2 から inform URL を読み取ります。任意の Linux マシンで hex string を作成します。

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 byte の string で、実行すると 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d が出力されます。結果を hex value として router の DHCP option 43 フィールドに貼り付けます。そのネットワークで起動するすべてのデバイスが lease から controller のアドレスを取得するため、SSH は不要です。古いガイドでは suboption 1、つまり 0104 の後に IPv4 アドレスの 4 byte を hex で指定する方法も示されています。デバイスは現在もこの形式を受け付けます。

サイトで DNS を運用している場合は、3 つ目の方法もあります。UniFi デバイスは起動時に hostname unifi の名前解決を試みます。そのため、unifi を VPS のアドレスに向ける A record を作成すると、デバイスごとの作業なしで adopt できます。ただし、デバイスが実際に使用する resolver を管理している場合に限り有効です。

UniFi で開放するポートと、非公開にするポート

リモートサイトから adoption と日常的な管理を行うには、2 つのポートに到達できる必要があります。

TCP 8080 は inform チャネルです。adoption 済みのすべてのデバイスがこのポートへ接続します。内部のペイロードは、adoption 時に controller がデバイスへ渡した鍵で AES 暗号化されます。そのため、ここでは通常、平文の HTTP を使用します。
UDP 3478 は STUN（Session Traversal Utilities for NAT）です。デバイスが controller への経路を維持するために使用します。

一部の機能では、追加のポートが必要です。Ubiquiti のポートリファレンスでは、L2 または L3 ネットワークで adopted された UXG gateway から Traffic Flow ログを送信するために TCP 5671 が指定されています。サイトにこの controller へ報告する UXG があり、そのログが必要な場合は、そのサイトから TCP 5671 への通信も許可します。

VPS では、それ以外のポートをすべて閉じます。

TCP 8443 は admin interface です。これは決して公開してはいけません。controller が管理するすべてのサイトの設定を、1 つのパスワードで保護しています。
UDP 10001 と UDP 1900 は broadcast discovery 用です。broadcast はインターネットを越えないため、開放しても意味がありません。
TCP 8880 と TCP 8843 は guest portal のリダイレクト用です。guest portal を運用する場合だけ開放します。
TCP 6789 はモバイルの speed test 用、UDP 5514 は remote syslog 用です。使用する場合に追加します。
TCP 27117 は MongoDB です。上記の compose file では database のポートを一切公開していないため、内部の Docker network からのみ利用できます。この状態を維持します。

サイトに static public address がある場合は、そのアドレスだけを許可します。

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

VPS の firewall に関する ufw の基本では、これらのルールが前提とする default deny の設定を説明しています。

ここには、毎回利用者を混乱させる落とし穴があります。Docker の published port は ufw を回避します。ポートを公開すると、NAT と forwarding のルールが iptables に直接書き込まれます。この通信は、ufw が管理する INPUT chain ではなく、Docker 独自の chain でフィルタリングされます。そのため、ufw deny 8443 は ufw status では正しく見えても、ポートは全世界に対して開いたままです。確認は VPS 自身ではなく、必ず別のマシンから行います。

nc -vz vps.example.com 8443

拒否または timeout になれば、意図した状態です。接続できる場合は、ufw が何と表示していても、そのポートは公開されています。確実な対策は、すでに compose file に示している方法です。ポートを 127.0.0.1 または tunnel address に bind し、Docker が public interface に bind しないようにします。DOCKER-USER chain にルールを追加する方法もありますが、bind のほうが簡単です。ルールの順序を誤っても、この設定が無効になることはありません。

Ubiquiti 独自のインストーラーについて

Ubiquiti は Network Application 用の Debian パッケージを公開しています。2026 年 10 月時点では、ヘルプセンターでこの方法を従来の方法と位置付け、自己ホスト環境では UniFi OS Server を新しい標準としています。このパッケージは動作しますが、現在の Ubuntu では MongoDB に関する問題が残ります。Ubuntu 22.04 と 24.04 には MongoDB サーバーパッケージが含まれていないため、MongoDB 独自のリポジトリを追加し、バージョンを手動で合わせる必要があります。前述のコンテナは、固定した 1 つのタグでこのバージョン調整を行います。そのため、ここではこの方法を採用します。

Ubiquiti の新しい自己ホスト型製品は UniFi OS Server です。UniFi アプリケーションを Podman コンテナで実行し、同社のハードウェアコンソールと同じ UniFi OS を提供します。2026 年 10 月時点で Ubiquiti が示している要件は、x86-64 CPU、Ubuntu 24.04 以降または Debian 13 以降、slirp4netns 1.2 以降を含む Podman 4.9.3 以降、2 GB 以上の RAM、10 GB の空きストレージです。Ubiquiti の Releases または Download ページにあるインストーラーのリンクは、バージョンごとに異なります。ダウンロードを右クリックしてリンクアドレスをコピーし、curl -O または wget で取得してください。リリースごとに URL が割り当てられるため、ガイドでは特定のバージョンを固定できますが、常に最新版を指すリンクは提示できません。インストーラーは uosserver という systemd サービスを設定します。このサービスは systemctl で停止・起動します。ベンダー独自のパッケージングを使用したい場合は、こちらを選択してください。自分でバージョンを固定し、サーバーを他の用途にも使える状態に保ちたい場合は、コンテナ構成を選択してください。

UniFi のバックアップの保存場所と、サーバー外へ取り出す方法

コントローラーは、Settings のバックアップセクションで設定したスケジュールと保持数に従って、独自のバックアップを作成します。ファイルはコンテナ内の /config/data/backup/autobackup に保存されます。ホスト上では ~/unifi/config/data/backup/autobackup に該当し、ファイル名は autobackup_10.5.67_20260813_1200_1755086400004.unf の形式になります。

実際にファイルが作成されていることを確認します。

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

スケジュールを設定してから 1 日経過してもディレクトリが空の場合、コンテナを新規に構築した環境でよくある問題です。アプリケーションは 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/

復元は 1 手順で実行できます。新規インストール時は、セットアップウィザードの最初のページでバックアップファイルからの復元を選択できます。稼働中のコントローラーでは、同じ設定ページから復元できます。復元先には、同じバージョンまたはそれより新しいバージョンを使用してください。復元先より新しいアプリケーションで作成されたバックアップは拒否されます。そのため、ファイルと一緒にバージョン番号も記録しておく必要があります。

コントローラーのアップグレードで発生する問題

アップグレードの前に、毎回手動でバックアップを作成し、ダウンロードしてください。その後、次を実行します。

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

最初に問題が発生するのは、データベースです。アプリケーションの変更と同じ編集で mongo タグを新しいメジャーバージョンに変更すると、起動しないコントローラーへの最短経路になります。MongoDB は、段階的なアップグレードを行わない限り、異なるメジャーバージョンのデータファイルを開けないためです。アプリケーションだけを先にアップグレードしてください。MongoDB は別途、1 メジャーバージョンずつ移行し、その際は新しいバックアップを用意してください。

次に問題になるのはメモリです。新しいリリースでは、より大きなヒープが必要です。アプリケーションが起動し、数分間動作してから終了する場合は、MEM_LIMIT と MEM_STARTUP を 1536 または 2048 に増やして再起動してください。ホスト上で dmesg -T | grep -i 'killed process' を実行すると、カーネルがプロセスを終了させたかどうかを確認できます。

忘れられがちなリスクが、デバイスのファームウェアです。コントローラー自身のアップグレード後、導入済みデバイスのファームウェアアップグレードが提示されます。同じセッション中に適用しないでください。デバイスのアップグレードとコントローラーのアップグレードが重なり、その間のリンクが切断されると、デバイスがプロビジョニングの途中で停止することがあります。その場合、別の建物にあるハードウェアへ SSH で接続し、set-inform を行う状態に戻る可能性があります。

アップグレード時間帯は、聞こえるほど深刻ではありません。コントローラーの再起動中もデバイスはネットワークトラフィックを転送し続けるため、ユーザーには何も起きていないように見えます。ただし、コントローラーが提供している場合は、ゲストポータルと RADIUS が停止します。どちらも利用されていない時間を選んでください。午前 3 時にコントローラーがひっそり停止しても、把握できるようにしておく価値があります。そのため、Uptime Kuma のステータスモニターからポート 8080 を監視し、停止を通知させてください。

正直な代替案：Ubiquiti のホステッドコンソール

Ubiquiti は同じ役割をサービスとして提供しています。2026年10月時点で、Ubiquiti の US ストアでは Official UniFi Hosting として月額 $29 から販売しており、Ubiquiti が運用するサーバー上で最大 1,000 台の UniFi Network デバイスを管理できます。直前にインストールしたセルフホスト型アプリケーションは無料で、サブスクリプションもありません。

1つのサイトを管理しており、パッチ適用より料金の支払いを選ぶ場合は、ホステッドコンソールを選びます。複数のサイトを管理する場合、または自分で管理するネットワーク内にコントローラーを置き、運用中の他のサービスと同じサーバーを共有したい場合は、VPS を選びます。小規模な環境では料金差は実際にありますが、比較すべき点はそれだけではありません。ホステッドコンソールの可用性は他者の運用に依存し、VPS は、ディスクが満杯になる夜も含めて自分で管理します。どちらの場合でもサーバーを有効活用するなら、次に読むべき項目は VPS でほかに実行できるサービスです。

FAQ

UniFi デバイスが VPS 上の controller を adopt できないのはなぜですか？

デバイスは UDP port 10001 でブロードキャストして controller を検出します。ブロードキャストはローカルネットワークの外へ出ないため、リモートサイトのデバイスはインターネット上の controller を検出できません。controller の system settings で inform host override を VPS の hostname に設定し、ssh ubnt@<device-ip> に続けて set-inform http://vps.example.com:8080/inform を実行してデバイスの接続先を指定します。デバイスが Adopting 状態の場合は、その状態のまま set-inform を再度実行します。別の controller が先に adopt していた場合は、以前の controller の認証情報が残っているため、先に factory default へリセットします。

self-hosted UniFi controller にはどの程度の RAM が必要ですか？

2 GB が実用上の下限で、4 GB なら余裕があります。アプリケーションは Java と MongoDB で構成され、両者は個別にメモリを使用します。デフォルトでは、container image が Java heap を 1024 MB に制限し、MongoDB の WiredTiger cache は 1 GB を超える RAM の半分を使用します。x86_64 では、grep -m1 -o avx /proc/cpuinfo で CPU が AVX を公開していることも確認してください。MongoDB 5.0 以降は AVX がないと起動せず、database container がループして再起動します。

port 8443 をインターネットに公開すべきですか？

いいえ。port 8443 は admin interface であり、controller が管理するすべての site の設定を保持しています。Docker Engine 28.0.0 以降では 127.0.0.1 で公開し、ssh -L 8443:127.0.0.1:8443 you@vps.example.com でアクセスするか、WireGuard または Tailscale の address に bind してください。adoption と管理には、site から TCP 8080 と UDP 3478 へ到達できる必要があります。UXG gateway が Traffic Flow log を controller に送信する場合は、TCP 5671 も必要です。site の public address が固定されている場合は、それらの address に制限できます。Docker の published port は ufw による filtering の対象外であるため、ufw status を信頼せず、外部のマシンからテストしてください。

VPS の controller が停止すると、ネットワークも停止しますか？

いいえ。adopt 済みの access point と switch は、controller がすでに配布した設定を使って traffic の forwarding を続けます。そのため、client の接続と Wi-Fi は維持されます。停止するのは管理機能です。dashboard と statistics collection を利用できなくなり、guest portal authentication や、controller が RADIUS server の場合の RADIUS など、controller が提供するリアルタイム機能も停止します。

UniFi controller は automatic backup をどこに保存しますか？

ここで使用する container image では、バックアップは /config/data/backup/autobackup に保存されます。このパスは host 上の data path に data/backup/autobackup を加えた場所へ対応し、.unf ファイルとして version と timestamp を含む名前が付けられます。一部の新規 install では autobackup directory が存在せず、scheduled backup がエラーを報告しないまま何も書き込まないことがあります。schedule を設定した翌日にその directory の内容を確認し、空であれば自分で作成してください。.unf には site configuration と administrator account が含まれるため、ファイルを VPS の外部へコピーしてください。

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