দ্বারা Matt Connor 2026-10-12

VPS-এ UniFi controller চালানোর সম্পূর্ণ নির্দেশিকা

Q: UniFi controller তার automatic backup কোথায় সংরক্ষণ করে?

এখানে ব্যবহৃত container image-এ backup-গুলো /config/data/backup/autobackup-এ সংরক্ষিত হয়। Host-এ এটি আপনার data path-এর সঙ্গে data/backup/autobackup-এ map করা থাকে। Backup-গুলো .unf file হিসেবে থাকে, এবং file-এর নামের মধ্যে version ও timestamp থাকে। কিছু fresh install-এ autobackup directory থাকে না। তখন scheduled backup কোনো error না দেখিয়েই কিছু লেখে না। Schedule সেট করার এক দিন পর ওই directory list করুন। খালি থাকলে নিজে directory তৈরি করুন। File-গুলো VPS-এর বাইরে copy করুন। কারণ একটি .unf-এর মধ্যে site configuration এবং administrator account থাকে।

VPS-এ UniFi Network Application চালাতে কত RAM লাগবে, MongoDB-সহ Docker কীভাবে ব্যবহার করবেন, set-inform দিয়ে Layer 3 adoption করবেন এবং কোন ports private রাখবেন জানুন।

একটি VPS-এ থাকা UniFi controller আসলে কী করে

একটি VPS-এ থাকা UniFi controller হলো এমন একটি management server, যা এটি পরিচালনা করা site-গুলো বন্ধ হয়ে গেলেও reachable থাকে। এই software হলো Ubiquiti-এর UniFi Network Application: এর পেছনে MongoDB database-সহ একটি Java program। এটি আপনার access point ও switch configure করে, তাদের statistics সংরক্ষণ করে এবং admin interface সরবরাহ করে। এটি client traffic বহন করে না।

এই শেষ বিষয়টিই নির্ধারণ করে controller কোথায় রাখা উচিত। যে office এটি পরিচালনা করে, সেই office-এর ভেতরের কোনো machine-এ controller রাখলে একই সময়ে network এবং network দেখার tool—দুটিই হারাবেন। স্থিতিশীল public address-সহ VPS-এ রাখলে এটি চালু থাকে, statistics সংগ্রহ করতে থাকে এবং এক জায়গা থেকে একাধিক site-এর device adopt করতে পারে। এর জন্য horsepower নয়, uptime প্রয়োজন।

controller offline থাকলেও adopted access point ও switch-গুলো তাদের কাছে আগে থেকে পাঠানো configuration অনুযায়ী traffic forward করতে থাকে। আপনি dashboard ও statistics হারাবেন। এ ছাড়া controller সচল থাকা প্রয়োজন এমন feature-ও কাজ করবে না, যেমন guest portal login বা controller আপনার RADIUS server হলে RADIUS (remote authentication dial-in user service)। তবে client-গুলো connected থাকবে।

একটি UniFi controller-এর কত RAM প্রয়োজন?

2 GB হলো সর্বনিম্ন সীমা, আর কেনার সময় 4 GB নেওয়াই ভালো। একই সার্ভারে RAM ব্যবহারকারী দুটি উপাদান আছে: Java এবং MongoDB। তারা একে অপরের থেকে স্বাধীনভাবে মেমরি নির্ধারণ করে।

Java heap-এর সর্বোচ্চ সীমা MEM_LIMIT দ্বারা নির্ধারিত হয়। Container image-এ এর default মান 1024 MB। MongoDB হলো অন্য অংশ। এর WiredTiger storage engine 1 GB-এর বেশি RAM-এর অর্ধেক, অথবা 256 MB—যেটি বড়—সেই পরিমাণ cache নির্ধারণ করে। 2 GB VPS-এ এটি প্রায় 512 MB cache, 1 GB heap, JVM-এর নিজস্ব non-heap memory এবং operating system-এর memory নিয়ে গঠিত। ব্যস্ত দিনে পৌঁছানো পর্যন্ত এটি কাজ করে। এরপর kernel-এর out-of-memory killer দুটি process-এর একটিকে বন্ধ করে দেয়। কোনো ব্যাখ্যাহীন restart-এর পরে dmesg -T | grep -i 'killed process' চালিয়ে দেখুন ঘটনাটি এমন কি না। আপনার কাছে 2 GB থাকলে একটি swap file যোগ করুন।

CPU এবং disk-এর চাহিদা কম। এক বা দুইটি vCPU কয়েক ডজন device সামলাতে পারে। শুরুতে 20 GB disk দিন এবং ব্যবহার পর্যবেক্ষণ করুন। কারণ আপনি যত client দেখেন এবং যতদিন statistics সংরক্ষণ করেন, database তত বড় হয়। শুধু controller চালালে 4 GB-এর বেশিরভাগ box অব্যবহৃত থাকে। তাই এর সঙ্গে অন্য কোনো service চালানোর পরিকল্পনা থাকলে আগে সেই service-এর চাহিদা অনুযায়ী আকার নির্ধারণ করুন। কারণ PhotoPrism এবং Immich-এর RAM-এর সর্বনিম্ন চাহিদা এক নয়, এবং যেকোনো একটির চাহিদা controller-এর চেয়ে বেশি।

একটি CPU feature গুরুত্বপূর্ণ, কিন্তু সস্তা plan-এ এটি সহজেই নজর এড়ায়:

grep -m1 -o avx /proc/cpuinfo

x86_64 hardware-এ MongoDB 5.0 এবং পরবর্তী সংস্করণগুলোর AVX (advanced vector extensions) প্রয়োজন। ওই command কোনো output না দিলে startup-এর সময় mongod বন্ধ হয়ে যায় এবং container বারবার restart হতে থাকে। কারণ binary এমন একটি instruction চালায়, যা CPU-তে নেই। পুরোনো Intel Celeron এবং Pentium host সাধারণত এর কারণ। Hypervisor guest-এর কাছ থেকে CPU flag লুকিয়ে রাখলেও একই সমস্যা হয়। MongoDB 4.4 হলো AVX ছাড়া চলতে সক্ষম সর্বশেষ release। Image-টি 3.6 পর্যন্ত আরও পুরোনো সংস্করণও গ্রহণ করে। তবে 4.4-এর end of life হয়েছে February 2024-এ। CVE-2025-14847-এর জন্য MongoDB December 2025-এ 4.4 build প্রকাশ করেছিল। কিন্তু পরবর্তী vulnerability-এর ক্ষেত্রেও একই সুবিধা পাওয়া যাবে—এমন নিশ্চয়তা নেই। পুরোনো release-গুলো আরও পিছিয়ে আছে। নতুন CPU-সহ host-এ স্থানান্তর করাই ভালো সমাধান। ARM VPS-এ এই প্রশ্ন ওঠে না, কারণ AVX হলো x86 instruction set। উভয় image-ই arm64 build প্রকাশ করে। দুটির মধ্যে বেছে নেওয়ার সময় ARM এবং x86 VPS plan-এর পার্থক্য শুধু দামের চেয়ে বেশি বিষয় অন্তর্ভুক্ত করে।

Docker Compose ব্যবহার করে UniFi Network Application ইনস্টল করুন

Docker ব্যবহার করলে অনিশ্চয়তা সবচেয়ে কম থাকে, কারণ distribution যে MongoDB version সরবরাহ করে সেটি নেওয়ার পরিবর্তে application-সমর্থিত একটি version নির্দিষ্ট করে রাখা যায়। সার্ভারে Docker না থাকলে আগে VPS-এ Docker ইনস্টল করুন।

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

Application লগ ইন করতে পারার আগে MongoDB-তে একজন user থাকতে হবে। Official MongoDB image প্রথমবার চালুর সময় /docker-entrypoint-initdb.d-এ পাওয়া যেকোনো script চালায়। এটি ~/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

এই script শুধু তখনই চলে, যখন database directory খালি থাকে। ভুল password দিয়ে প্রথমবার stack চালালে user-টি ভুল password-সহ তৈরি হয়। পরে compose file সম্পাদনা করলেও কিছু পরিবর্তন হয় না, কারণ script আর চালানো হয় না। এর লক্ষণ হলো application container-এ MongoDB authentication failure লগ হয়, কিন্তু web interface কখনও দেখা যায় না। নতুন install-এর ক্ষেত্রে stack বন্ধ করে ~/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

উভয় image tag ইচ্ছাকৃতভাবে নির্দিষ্ট করা হয়েছে। 10.5.67-ls141 ছিল August 2026-এ বর্তমান application release। তাই install করার সময় image-এর release list পরীক্ষা করে তখনকার বর্তমান version নির্দিষ্ট করুন। Database tag আরও গুরুত্বপূর্ণ। MongoDB নিজে থেকে major version-এর মধ্যে data file upgrade করে না। তাই mongo:latest একদিন নতুন major version টেনে আনবে, পাওয়া file খুলতে অস্বীকার করবে এবং বারবার restart হবে। Major version নির্দিষ্ট করে রাখুন এবং পরিকল্পনা অনুযায়ী পরিবর্তন করুন। UniFi Network 8.1 এবং পরবর্তী version MongoDB 3.6 থেকে 7.0 পর্যন্ত সমর্থন করে। 9.0 MongoDB 8.0-এর সমর্থন যোগ করেছে।

PUID এবং PGID-কে host-এর কোনো বাস্তব user-এর সঙ্গে মিলতে হবে। নইলে ./config-এর file এমন একটি identity-এর মালিকানাধীন হবে, যে সেগুলোতে লিখতে পারে না। আপনার মান পেতে id চালান। container image-এ PUID এবং PGID কীভাবে কাজ করে mismatch-এর লক্ষণ ব্যাখ্যা করে।

এটি চালু করে লগ পর্যবেক্ষণ করুন:

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

docker compose ps-এ উভয় container-এর অবস্থা running হিসেবে দেখা উচিত। unifi-db যদি restarting-এ আটকে থাকে, তবে কারণ হয় উপরের AVX সমস্যা, নয়তো ./db-এ permission সমস্যা। লগ স্থির হওয়ার পরে দুইটি listener পরীক্ষা করুন:

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 status code পাওয়া মানে listener bind হয়েছে এবং উত্তর দিচ্ছে। Connection refused মানে application এখনও start হচ্ছে। প্রথমবার চালু হলে ছোট VPS-এ এতে এক বা দুই মিনিট লাগতে পারে। অথবা application আদৌ start হয়নি।

অ্যাডমিন ইন্টারফেস প্রকাশ না করে এতে প্রবেশ করুন

উপরের ফাইলে 127.0.0.1-এ 8443 port প্রকাশ করা হয়েছে। তাই Docker Engine 28.0.0 বা পরবর্তী সংস্করণে VPS-এর বাইরের কোনো উৎস অ্যাডমিন ইন্টারফেসে পৌঁছাতে পারবে না। পুরোনো release-এ একই L2 segment-এর অন্য host, যেমন একই network switch-এ থাকা machine, localhost-এ প্রকাশ করা port-এ পৌঁছাতে পারে। তাই `docker version` চালান এবং server-এ এর চেয়ে পুরোনো কোনো সংস্করণ থাকলে আগে upgrade করুন। Setup wizard চালাতে SSH-এর মাধ্যমে port forward করুন:

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

ওই session চালু রাখুন এবং https://127.0.0.1:8443-এ browse করুন। Certificate-টি self-signed, তাই browser একবার warning দেখাবে। Administrator account তৈরি করুন, site-এর নাম দিন এবং আপাতত device adoption এড়িয়ে যান।

একজন administrator-এর জন্য SSH tunnel যথেষ্ট। একটি team-এর জন্য VPS-কে একটি private address দিন এবং interface-টি সেই address-এ bind করুন। আপনার নিজের VPS-এ WireGuard VPN এবং Tailscale subnet router—উভয়ই এমন একটি address দেয়, যেখানে শুধু আপনার team-এর লোকজন route করতে পারে। WireGuard-এর ক্ষেত্রে published port `10.8.0.1:8443:8443`-এ পরিবর্তন করুন, অথবা Tailscale যে address দেয় সেটি ব্যবহার করুন। একটি বিষয় মনে রাখুন: যে address এখনো বিদ্যমান নয়, Docker তাতে publish করতে পারে না। তাই container start হওয়ার আগে tunnel interface চালু হতে হবে। তা না হলে bind error-এর কারণে container ব্যর্থ হবে।

কেন দূরবর্তী UniFi ডিভাইস adopt হবে না

ডিফল্ট অবস্থায় UniFi ডিভাইস স্থানীয় নেটওয়ার্কে UDP port 10001-এ broadcast করে তার controller খুঁজে পায়। Broadcast LAN-এর বাইরে যায় না। তাই অন্য শহরের কোনো office-এ থাকা ডিভাইস VPS-এ থাকা controller আবিষ্কার করতে পারবে না। এটি Layer 3 adoption। এখানেই অধিকাংশ ব্যবহারকারী আটকে যান। ডিভাইসটি ঠিক আছে এবং controller-ও ঠিক আছে। কিন্তু কোথায় খুঁজতে হবে, তা ডিভাইসটিকে কেউ জানায়নি।

প্রথমে controller-কে জানান, কোন address বিতরণ করতে হবে। Controller-এর Settings-এর System section-এ override option-সহ inform host setting আছে। এখানে আপনার VPS-এর public hostname অথবা IP নির্ধারণ করুন। এটি না করলে controller তার নিজের interface-এ দেখা address প্রচার করে। Docker bridge network-এর ভেতরে এটি 172.18.0.3-এর মতো একটি private address হতে পারে। ডিভাইসটি সেই address পায়, সেখানে route করতে পারে না এবং আবার খোঁজা শুরু করে।

এরপর ডিভাইসটিকে ওই address ব্যবহার করতে নির্দেশ দিন। Remote LAN-এ থাকা ডিভাইসে SSH করুন। Factory default অবস্থার ডিভাইসটি ubnt username এবং ubnt password গ্রহণ করে:

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

নতুন device firmware আপনাকে shell-এর বদলে একটি menu দেখায়। একই কাজ single command হিসেবে চালান:

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

এখন ডিভাইসটি controller-এ adoption-এর জন্য প্রস্তুত হিসেবে দেখা যাবে। Adopt-এ click করুন। State Adopting-এ পরিবর্তিত হবে। এখানে একটি বিষয় অনেকের কাছে অপ্রত্যাশিত: সাধারণত set-inform দ্বিতীয়বার চালাতে হয়। ডিভাইসটি provisioning-এর জন্য restart হয় এবং নিজের configuration-এ সংরক্ষিত inform URL ব্যবহার করে। Controller সেটি প্রতিস্থাপন করা শেষ করেনি। State Adopting দেখানোর সময় আবার command চালালে handover সম্পূর্ণ হয়। ডিভাইসটিতে info লিখে বর্তমানে সংরক্ষিত inform URL এবং state দেখুন।

ডিভাইসটি আগে অন্য controller দ্বারা adopted হয়ে থাকলে শুধু set-inform চালালে কাজ সম্পূর্ণ হবে না। কারণ ডিভাইসটিতে এখনও আগের controller-এর credentials সংরক্ষিত থাকে। প্রথমে reset button ব্যবহার করে অথবা পুরোনো credentials দিয়ে SSH-এর মাধ্যমে set-default চালিয়ে সেটিকে factory default অবস্থায় ফিরিয়ে আনুন।

অল্প কয়েকটির বেশি ডিভাইস থাকলে DHCP ব্যবহার করুন। DHCP (dynamic host configuration protocol)-এর option 43 একটি vendor-specific value বহন করে। UniFi ডিভাইসগুলো suboption 2 থেকে inform URL পড়ে। যেকোনো Linux box-এ 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 field-এ paste করুন। এরপর ওই network-এ boot করা প্রতিটি ডিভাইস SSH ছাড়াই DHCP lease থেকে controller address শিখবে। পুরোনো guide-গুলোতে suboption 1 দেখানো হয়। সেখানে 0104-এর পরে IPv4 address-এর চারটি byte hex আকারে দিতে হয়। ডিভাইসগুলো এখনও ওই format গ্রহণ করে।

আপনি site-এ DNS চালালে তৃতীয় একটি পদ্ধতিও আছে। UniFi ডিভাইস boot হওয়ার সময় unifi hostname resolve করার চেষ্টা করে। তাই unifi-এর জন্য আপনার VPS address-এ নির্দেশ করা একটি A record থাকলে কোনো ডিভাইসে আলাদাভাবে কাজ না করেই adoption করা যায়। তবে এটি তখনই কার্যকর, যখন ডিভাইসগুলো বাস্তবে যে resolver ব্যবহার করে সেটি আপনার নিয়ন্ত্রণে থাকে।

কোন UniFi port খোলা রাখবেন এবং কোনগুলো ব্যক্তিগত রাখবেন

Adoption এবং প্রতিদিনের management-এর জন্য একটি remote site থেকে 2টি port-এ পৌঁছানো সম্ভব হতে হবে।

TCP 8080 হলো inform channel, এবং adopted প্রতিটি device এতে connect করে। এর ভেতরের payload adoption-এর সময় controller device-কে দেওয়া key দিয়ে AES encrypted থাকে। তাই এখানে plain HTTP ব্যবহার করাই স্বাভাবিক setting।
UDP 3478 হলো STUN (session traversal utilities for NAT)। Device-গুলো controller-এ ফেরার path বজায় রাখতে এটি ব্যবহার করে।

কিছু feature-এর জন্য আরও port দরকার। Ubiquiti-এর port reference অনুযায়ী L2 বা L3 network-এ adopted UXG gateway থেকে Traffic Flow logging-এর জন্য TCP 5671 লাগে। তাই কোনো site-এর UXG যদি এই controller-এ report করে এবং আপনি ওই log চান, সেই site-এর জন্য 5671-ও খুলুন।

VPS-এ অন্য সব port বন্ধ রাখুন।

TCP 8443 হলো admin interface। এটি কখনো public করা যাবে না। Controller যে প্রতিটি site পরিচালনা করে, সেগুলোর configuration একটি password-এর সুরক্ষায় এখানে থাকে।
UDP 10001 এবং UDP 1900 হলো broadcast discovery-এর port। Broadcast internet অতিক্রম করে না, তাই এগুলো খুলে কোনো লাভ নেই।
TCP 8880 এবং TCP 8843 হলো guest portal redirect-এর port। শুধু guest portal চালালে এগুলো খুলুন।
TCP 6789 হলো mobile speed test-এর port এবং UDP 5514 হলো remote syslog-এর port। ব্যবহার করলে এগুলো যোগ করুন।
TCP 27117 হলো MongoDB। উপরের compose file-এ database কোনো port publish করে না, তাই এটি শুধু internal Docker network-এ থাকে। এভাবেই রাখুন।

আপনার site-গুলোর 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-এর মৌলিক বিষয়-এ ওই rule-গুলোর প্রয়োজনীয় default deny setup ব্যাখ্যা করা হয়েছে।

এখানে এমন একটি সমস্যা আছে, যা প্রতিবারই অনেককে বিভ্রান্ত করে। Docker-এর published port ufw-কে পাশ কাটায়। কোনো port publish করলে Docker সরাসরি iptables-এ NAT এবং forwarding rule লিখে। সেই traffic ufw পরিচালিত INPUT chain-এ নয়, Docker-এর নিজস্ব chain-এ filter হয়। তাই ufw deny 8443-এ ufw status সঠিক দেখালেও port সবার জন্য খোলা থাকতে পারে। অন্য একটি machine থেকে পরীক্ষা করুন, VPS নিজে থেকে কখনো নয়:

nc -vz vps.example.com 8443

Connection refusal বা timeout-ই প্রত্যাশিত ফল। Connection হলে ufw যা-ই বলুক, port public। নির্ভরযোগ্য সমাধানটি compose file-এ ইতিমধ্যে আছে: port-টি 127.0.0.1 বা কোনো tunnel address-এ publish করুন, যাতে Docker কখনো এটিকে public interface-এ bind না করে। DOCKER-USER chain-এ rule দিয়েও কাজ হবে, কিন্তু bind করা সহজ এবং rule ordering-এর ভুলে এটি অকার্যকর হবে না।

Ubiquiti-এর নিজস্ব installer সম্পর্কে কী জানা দরকার?

Ubiquiti Network Application-এর জন্য একটি Debian package প্রকাশ করে। তবে October 2026 অনুযায়ী তাদের help center এই পদ্ধতিকে legacy হিসেবে চিহ্নিত করে এবং self-hosting-এর জন্য UniFi OS Server-কে নতুন standard হিসেবে দেখায়। Package-টি কাজ করে, কিন্তু বর্তমান Ubuntu-তে এটি এমন একটি MongoDB প্রশ্ন তৈরি করে যার উত্তর distribution আর দেয় না: Ubuntu 22.04 এবং 24.04 কোনো MongoDB server package সরবরাহ করে না। তাই আপনাকে MongoDB-এর নিজস্ব repository যোগ করতে হবে এবং version হাতে মিলিয়ে নিতে হবে। উপরের container একটি pinned tag-এ এই version matching করে। এই কারণেই এখানে সেটিই ব্যবহার করা হয়েছে।

Ubiquiti-এর নতুন self-hosted product হলো UniFi OS Server। এটি Podman container-এ UniFi application চালায় এবং তাদের hardware console-এ থাকা একই UniFi OS সরবরাহ করে। October 2026 অনুযায়ী Ubiquiti একটি x86-64 CPU, Ubuntu 24.04 বা পরবর্তী version অথবা Debian 13 বা পরবর্তী version, slirp4netns 1.2 বা পরবর্তী version-সহ Podman 4.9.3 বা পরবর্তী version, কমপক্ষে 2 GB RAM এবং 10 GB খালি storage চায়। Ubiquiti-এর Releases বা Download page-এ থাকা installer link version-specific। Download-এর ওপর right click করে link address copy করুন, তারপর curl -O অথবা wget দিয়ে সেটি download করুন। প্রতিটি release-এর আলাদা URL থাকে। তাই কোনো guide একটি version pin করতে পারে, কিন্তু এমন link দিতে পারে না যা সবসময় latest version-এ নির্দেশ করে। Installer uosserver নামে একটি systemd service সেট আপ করে। এটি systemctl দিয়ে stop ও start করা যায়। আপনি যদি vendor-এর নিজস্ব packaging ব্যবহার করতে চান, এটি বেছে নিন। নিজে version pin করতে এবং server-টি অন্য কাজের জন্য খালি রাখতে চাইলে container stack বেছে নিন।

UniFi backup কোথায় থাকে এবং কীভাবে সার্ভারের বাইরে নেওয়া যায়

Controller আপনার Settings-এ নির্ধারিত সময়সূচি অনুযায়ী backup section-এ নিজস্ব backup তৈরি করে। একই জায়গায় কতগুলো backup রাখতে হবে, সেটিও নির্ধারণ করা যায়। ফাইলগুলো container-এর /config/data/backup/autobackup-এ তৈরি হয়, যা host-এ ~/unifi/config/data/backup/autobackup হিসেবে মাউন্ট করা আছে। ফাইলের নাম সাধারণত autobackup_10.5.67_20260813_1200_1755086400004.unf-এর মতো হয়।

ফাইলগুলো সত্যিই তৈরি হচ্ছে কি না পরীক্ষা করুন:

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

সময়সূচি নির্ধারণের এক দিন পরেও directory খালি থাকা fresh container install-এর একটি পরিচিত সমস্যা। Application-এর autobackup directory থাকা প্রত্যাশিত, কিন্তু এটি নিজে directory তৈরি করে না। ফলে scheduled job নীরবে কোনো ফাইল লিখতে পারে না। Container যে user হিসেবে চলছে, সেই user হিসেবেই directory তৈরি করুন। এরপর পরবর্তী run পর্যন্ত অপেক্ষা করুন:

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

একটি .unf file-এ site configuration এবং administrator account থাকে। তাই এটিকে cryptographic key-এর মতো সংবেদনশীল হিসেবে বিবেচনা করুন। কপি এমন একটি machine-এ নিয়ে রাখুন যা আপনার নিয়ন্ত্রণে আছে, এবং ফাইলগুলো private রাখুন:

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

Restore করার পদ্ধতি সরাসরি। নতুন install-এর setup wizard-এর প্রথম page-এ backup file থেকে restore করার option থাকে। Running controller-ও একই settings page থেকে restore গ্রহণ করে। একই version অথবা আরও নতুন version-এ restore করুন। যে application version backup তৈরি করেছে, সেটি restore করার target version-এর চেয়ে নতুন হলে backup প্রত্যাখ্যান করা হয়। তাই file-এর সঙ্গে version number-ও সংরক্ষণ করুন।

কন্ট্রোলার আপগ্রেডে কী কী নষ্ট হতে পারে

প্রতিটি আপগ্রেডের আগে ম্যানুয়াল backup নিন এবং সেটি download করুন। এরপর:

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

প্রথমে database-এই সমস্যা দেখা দেয়। অ্যাপ্লিকেশনের সঙ্গে একই edit-এ mongo tag-টি নতুন major version-এ পরিবর্তন করলে controller আর start না হওয়ার সম্ভাবনা সবচেয়ে বেশি। কারণ staged upgrade ছাড়া MongoDB ভিন্ন major version-এর data file খুলবে না। আগে শুধু অ্যাপ্লিকেশন আপগ্রেড করুন। MongoDB আলাদাভাবে, একবারে একটি major version করে সরান। হাতে একটি নতুন backup রাখুন।

পরের সমস্যা হলো memory। বড় release-এর জন্য বড় heap প্রয়োজন। অ্যাপ্লিকেশন start হয়ে কয়েক মিনিট চলার পর বন্ধ হয়ে গেলে MEM_LIMIT এবং MEM_STARTUP-এর মান 1536 বা 2048 করে restart করুন। Host-এ dmesg -T | grep -i 'killed process' চালালে kernel নিজে প্রক্রিয়াটি বন্ধ করেছে কি না নিশ্চিত হওয়া যায়।

Device firmware এমন একটি ঝুঁকি, যা অনেকে ভুলে যান। Controller নিজে আপগ্রেড হওয়ার পর adopted device-গুলোর জন্য firmware upgrade প্রস্তাব করে। একই session-এ সেগুলো গ্রহণ করবেন না। Device upgrade এবং controller upgrade একই সময়ে চললে এবং তাদের মধ্যকার link বিচ্ছিন্ন হলে device-এর provisioning অসম্পূর্ণ অবস্থায় আটকে যেতে পারে। তখন অন্য ভবনের hardware-এ SSH করে আবার set-inform চালানোর পরিস্থিতি তৈরি হবে।

Upgrade window যতটা কঠিন মনে হয়, বাস্তবে তা ততটা নয়। Controller restart হওয়ার সময় device-গুলো traffic forwarding চালিয়ে যায়, তাই ব্যবহারকারীরা কিছু টের পান না। তবে controller guest portal এবং RADIUS সরবরাহ করলে সেগুলো বন্ধ থাকে। তাই এমন সময় বেছে নিন, যখন কোনোটিই ব্যবহৃত হচ্ছে না। ভোর 3টায় নীরবে বন্ধ হয়ে যাওয়া controller-এর বিষয়টি জানা দরকার। তাই port 8080-এ একটি Uptime Kuma status monitor নির্দেশ করুন এবং সেটিকে আপনাকে জানাতে দিন।

সৎ বিকল্প: Ubiquiti-এর hosted console

Ubiquiti একই কাজ একটি service হিসেবে বিক্রি করে। October 2026 অনুযায়ী, Ubiquiti-এর US store এটিকে Official UniFi Hosting নামে বিক্রি করছে। এর দাম মাসে $29 থেকে শুরু হয়। এটি Ubiquiti পরিচালিত একটি server-এ সর্বোচ্চ 1,000টি UniFi Network device পরিচালনা করে। আপনি এইমাত্র যে self-hosted application ইনস্টল করেছেন, সেটি বিনামূল্যে এবং এতে কোনো subscription নেই।

আপনি যদি একটি site পরিচালনা করেন এবং patch করার বদলে অর্থ দিতে চান, তাহলে hosted console বেছে নিন। আপনি যদি একাধিক site পরিচালনা করেন, অথবা আপনার নিয়ন্ত্রণাধীন network-এর ভেতরে controller রাখতে চান এবং আপনার চালানো অন্যান্য service-এর সঙ্গে একই box ব্যবহার করতে চান, তাহলে VPS বেছে নিন। ছোট পরিসরে খরচের পার্থক্য বাস্তব, কিন্তু বিবেচনার একমাত্র বিষয় এটি নয়: hosted console-এর uptime অন্য পক্ষের ওপর নির্ভরশীল, আর আপনার VPS আপনার নিজের—যে রাতেও তার disk পূর্ণ হয়ে যেতে পারে। যেকোনো ক্ষেত্রেই যদি box-টি নিজের খরচ তুলে আনে, তাহলে VPS-এ আর কী চালানো যায়—পরবর্তী পাঠ্য হিসেবে সেটিই পড়ুন।

FAQ

আমার UniFi ডিভাইস VPS-এ চলা controller-এ adopt হচ্ছে না কেন?

ডিভাইসগুলো UDP port 10001-এ broadcast পাঠিয়ে controller খুঁজে পায়। Broadcast কখনও local network-এর বাইরে যায় না। তাই remote site-এর কোনো ডিভাইস public internet-এ থাকা 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 করে থাকে, প্রথমে সেটিকে factory default-এ reset করুন। কারণ ডিভাইসটিতে এখনও পুরোনো controller-এর credentials সংরক্ষিত থাকে।

self-hosted UniFi controller-এর কত RAM প্রয়োজন?

2 GB হলো কাজ চালানোর সর্বনিম্ন পরিমাণ। 4 GB হলে স্বাচ্ছন্দ্যে চালানো যায়। এই application Java এবং MongoDB ব্যবহার করে। দুটিই আলাদাভাবে memory নির্ধারণ করে। 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 এবং পরবর্তী সংস্করণ এটি ছাড়া start হবে না। তখন database container বারবার restart হবে।

আমার কি port 8443 internet-এ প্রকাশ করা উচিত?

না। Port 8443 হলো admin interface। Controller যে প্রতিটি site পরিচালনা করে, সেগুলোর configuration এখানে থাকে। Docker Engine 28.0.0 বা পরবর্তী সংস্করণ ব্যবহার করলে 127.0.0.1-এ এটি publish করুন এবং ssh -L 8443:127.0.0.1:8443 you@vps.example.com দিয়ে access করুন। বিকল্পভাবে, এটিকে WireGuard বা Tailscale address-এ bind করুন। Adoption ও management-এর জন্য আপনার site-গুলোকে TCP 8080 এবং UDP 3478-এ পৌঁছাতে হবে। কোনো UXG gateway controller-এ Traffic Flow log পাঠালে TCP 5671-ও প্রয়োজন হবে। Public address স্থির হলে এগুলো site-গুলোর public address-এ সীমাবদ্ধ করতে পারেন। মনে রাখবেন, Docker published port ufw দিয়ে filter হয় না। তাই ufw status-এর ওপর নির্ভর না করে বাইরের কোনো machine থেকে পরীক্ষা করুন।

VPS controller বন্ধ হয়ে গেলে কি আমার network কাজ করা বন্ধ করবে?

না। Adopt করা access point এবং switch-গুলো controller আগে যে configuration পাঠিয়েছে, তা ব্যবহার করে traffic forward করতে থাকে। তাই client-গুলো connected থাকে এবং Wi-Fi কাজ করে। বন্ধ হয় management কার্যক্রম। Dashboard ও statistics collection আর পাওয়া যায় না। Controller যে live feature সরবরাহ করে, সেগুলোও বন্ধ হয়। এর মধ্যে guest portal authentication বা controller RADIUS server হলে RADIUS-ও রয়েছে।

UniFi controller তার automatic backup কোথায় সংরক্ষণ করে?

এখানে ব্যবহৃত container image-এ backup-গুলো /config/data/backup/autobackup-এ সংরক্ষিত হয়। Host-এ এটি আপনার data path-এর সঙ্গে data/backup/autobackup-এ map করা থাকে। Backup-গুলো .unf file হিসেবে থাকে, এবং file-এর নামের মধ্যে version ও timestamp থাকে। কিছু fresh install-এ autobackup directory থাকে না। তখন scheduled backup কোনো error না দেখিয়েই কিছু লেখে না। Schedule সেট করার এক দিন পর ওই directory list করুন। খালি থাকলে নিজে directory তৈরি করুন। File-গুলো VPS-এর বাইরে copy করুন। কারণ একটি .unf-এর মধ্যে site configuration এবং administrator account থাকে।

এই লেখাটি কি কাজে লেগেছে?

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