Rehberler

Yazan Matt Connor 2026-08-13 · Güncellendi 2026-08-16

VPS uzerinde UniFi Controller kurulumu rehberi

UniFi Network Application yazilimini VPS uzerinde barindirmanin yollarini ogrenin. Docker ve MongoDB yapilandirmasi, set-inform komutu ve guvenlik icin kapatilmasi gereken portlar.

Bir VPS üzerinde UniFi controller ne işe yarar

Bir VPS üzerindeki UniFi controller, yönettiği sahalar çevrimdışı olduğunda dahi erişilebilir durumda kalan merkezi bir yönetim sunucusudur. Bu yazılım, arkasında bir MongoDB veritabanı bulunan Java tabanlı bir program olan Ubiquiti UniFi Network Application'dır. Erişim noktalarınızı ve anahtarlarınızı yapılandırır, istatistiklerini saklar ve yönetim arayüzünü sunar. İstemci trafiğini taşımaz.

Bu son nokta, yazılımın nerede barındırılması gerektiğini belirler. Controller'ı yönettiği ofis içindeki bir makineye kurarsanız, ağ bağlantısı koptuğu anda ağı izlemek için kullandığınız aracı da kaybedersiniz. Onu sabit bir genel IP adresine sahip bir VPS üzerine kurarsanız, sistem çalışmaya ve veri toplamaya devam eder; ayrıca birden fazla sahadaki cihazları tek bir noktadan yönetebilirsiniz. Bu sistem yüksek işlem gücünden ziyade yüksek çalışma süresine (uptime) ihtiyaç duyar.

Controller çevrimdışı olduğunda, daha önce yapılandırılmış olan erişim noktaları ve anahtarlar trafiği iletmeye devam eder. Bu durumda kontrol panelini, istatistikleri ve controller'ın aktif olmasını gerektiren özellikleri kaybedersiniz: örneğin misafir portalı girişi veya controller'ınızın RADIUS sunucusu olarak görev yaptığı durumlarda RADIUS (remote authentication dial-in user service) hizmeti devre dışı kalır. İstemcilerin bağlantısı ise kesilmez.

UniFi controller ne kadar RAM'e ihtiyaç duyar?

İki GB alt sınırdır, 4 GB ise satın alınması gereken miktardır. Bir kutu içerisinde Java ve MongoDB olmak üzere iki bellek tüketicisi bulunur ve bunlar birbirlerinden bağımsız olarak boyutlanırlar.

Java heap alanı, varsayılan olarak container imajı tarafından 1024 MB olarak ayarlanan MEM_LIMIT ile sınırlandırılmıştır. Diğer yarısını ise MongoDB oluşturur. MongoDB'nin WiredTiger depolama motoru, önbelleğini 1 GB üzerindeki RAM miktarının yarısı veya 256 MB (hangisi daha büyükse) olarak boyutlandırır. 2 GB'lık bir VPS üzerinde bu yaklaşık 512 MB önbellek, 1 GB heap alanı, JVM'in kendi heap dışı belleği ve işletim sistemi anlamına gelir. Yoğun bir güne kadar sistem çalışır, ancak o noktada çekirdeğin out-of-memory killer mekanizması bu iki süreçten birini sonlandırır. Açıklanamayan herhangi bir yeniden başlatma sonrasında, sorunun bu olup olmadığını anlamak için dmesg -T | grep -i 'killed process' komutunu çalıştırın. Eğer elinizdeki miktar 2 GB ise bir swap dosyası ekleyin.

CPU ve disk gereksinimleri düşüktür. Bir veya iki vCPU, birkaç düzine cihazı yönetebilir. 20 GB disk ile başlayın ve takipte kalın; çünkü veritabanı, gördüğünüz istemci sayısı ve istatistikleri ne kadar süre tuttuğunuza bağlı olarak büyür. Bir controller tek başına 4 GB'lık bir sunucunun büyük kısmını boşta bırakır. Bu nedenle yanına başka bir uygulama eklemeyi planlıyorsanız, önce o uygulamanın gereksinimlerine göre boyutlandırma yapın; çünkü PhotoPrism ve Immich çok farklı RAM alt sınırlarına sahiptir ve her ikisi de controller'dan daha fazla kaynak talep eder.

Bir CPU özelliği önemlidir ve ucuz planlarda gözden kaçması kolaydır:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 ve sonraki sürümler, x86_64 donanım üzerinde AVX (advanced vector extensions) desteğine ihtiyaç duyar. Eğer bu komut hiçbir çıktı vermiyorsa, mongod başlatma sırasında çöker ve container sürekli yeniden başlar; çünkü binary, CPU'nun sahip olmadığı bir komutu çalıştırmaya çalışmaktadır. Eski Intel Celeron ve Pentium sunucular veya CPU bayraklarını misafir sisteme gizleyen hipervizörler genellikle bu soruna neden olur. MongoDB 4.4, AVX gerektirmez ve tek yedek seçenektir; ancak bu, upstream tarafından artık yama almayan bir veritabanı sürümüdür. Daha yeni bir CPU'ya sahip bir sunucuya geçmek daha doğru bir çözümdür. ARM tabanlı bir VPS üzerinde bu soru ortaya çıkmaz, çünkü AVX bir x86 komut setidir ve her iki imaj da arm64 sürümleri yayınlamaktadır. İkisi arasında bir seçim yapıyorsanız, ARM ve x86 VPS planları arasındaki farklar sadece fiyattan ibaret değildir.

Docker Compose ile UniFi Network Application kurulumu

Docker, uygulamanın desteklediği bir MongoDB sürümünü sabitlemenize olanak tanıdığı ve dağıtımınızın sunduğu sürüme bağımlı kalmanızı engellediği için en az sürpriz barındıran yöntemdir. Eğer sunucunuzda Docker yüklü değilse, önce bir VPS üzerine Docker kurulumu işlemini gerçekleştirin.

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

Uygulamanın giriş yapabilmesi için MongoDB'nin bir kullanıcıya ihtiyacı vardır. Resmi MongoDB imajı, ilk başlatma sırasında /docker-entrypoint-initdb.d dizininde bulduğu tüm betikleri çalıştırır. Bunu ~/unifi/init-mongo.sh olarak kaydedin:

#!/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

Bu betik yalnızca veritabanı dizini boş olduğunda çalışır. Yığını yanlış parola ile bir kez başlatırsanız kullanıcı yanlış parola ile oluşturulur; sonrasında compose dosyasını düzenlemek hiçbir şeyi değiştirmez çünkü betik bir daha çalışmaz. Bu durumun belirtisi, uygulama container'ının MongoDB kimlik doğrulama hataları vermesi ve web arayüzünün asla açılmamasıdır. Yeni bir kurulumda çözüm, yığını durdurmak, ~/unifi/db dizinini silmek ve yeniden başlatmaktır.

Ardından ~/unifi/compose.yaml dosyasını oluşturun:

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

Her iki imaj etiketi de bilinçli olarak sabitlenmiştir. 10.5.67-ls141, Ağustos 2026 itibarıyla güncel uygulama sürümüydü; bu nedenle imajın sürüm listesini kontrol edin ve kurulum sırasında güncel olan sürümü sabitleyin. Veritabanı etiketi daha kritiktir. MongoDB, veri dosyalarını ana sürümler arasında otomatik olarak yükseltmez; bu nedenle mongo:latest bir gün yeni bir ana sürümü çekecek, bulduğu dosyaları açmayı reddedecek ve döngüsel olarak yeniden başlayacaktır. Ana sürümü sabitleyin ve yükseltmeleri bilinçli olarak yapın. UniFi Network 8.1 ve sonrası MongoDB 3.6 ile 7.0 arasını destekler, 9.0 sürümü ise MongoDB 8.0 desteğini eklemiştir.

PUID ve PGID değerleri, ana makinedeki gerçek bir kullanıcı ile eşleşmelidir; aksi takdirde ./config altındaki dosyalar, yazma yetkisi olmayan bir kimliğe ait olur. Kendi değerlerinizi öğrenmek için id komutunu çalıştırın. container imajlarında PUID ve PGID nasıl çalışır konusu, uyumsuzluk durumunda neler yaşandığını açıklar.

Başlatın ve izleyin:

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

docker compose ps komutu her iki container'ı da running durumunda göstermelidir. restarting durumunda takılı kalan bir unifi-db, yukarıda belirtilen AVX sorunu veya ./db üzerindeki bir izin sorunudur. Günlük kayıtları durulduğunda, iki dinleyiciyi kontrol edin:

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

Herhangi bir HTTP durum kodu, dinleyicinin bağlı olduğunu ve yanıt verdiğini gösterir. Connection refused, uygulamanın hala başlatılmakta olduğunu (küçük bir VPS üzerinde ilk çalıştırmada bir veya iki dakika sürebilir) ya da hiç başlamadığını gösterir.

Yönetim arayüzüne dışarıya açmadan erişim

8443 numaralı port yukarıdaki dosyada 127.0.0.1 üzerinde yayınlanmıştır, bu nedenle VPS dışındaki hiçbir şey yönetim arayüzüne erişemez. Kurulum sihirbazını çalıştırmak için bu portu SSH üzerinden yönlendirin:

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

Bu oturumu açık bırakın ve https://127.0.0.1:8443 adresine gidin. Sertifika kendinden imzalı olduğu için tarayıcı bir kez uyarı verecektir. Yönetici hesabını oluşturun, siteyi adlandırın ve cihaz ekleme adımını şimdilik atlayın.

SSH tüneli tek bir yönetici için yeterlidir. Bir ekip için VPS'e özel bir IP adresi atayın ve arayüzü bu adrese bağlayın. kendi VPS'inizde bir WireGuard VPN ve bir Tailscale subnet router kurulumu, yalnızca ekibinizin yönlendirebileceği bir adres sağlar. Yayınlanan portu WireGuard için 10.8.0.1:8443:8443 adresine veya Tailscale'in atadığı adrese değiştirin. Dikkat edilmesi gereken bir nokta: Docker henüz var olmayan bir adreste yayın yapamaz; bu nedenle tünel arayüzü container başlamadan önce ayağa kalkmalıdır, aksi takdirde container bir bind hatası vererek başarısız olur.

Uzak bir UniFi cihazı neden benimsenmiyor (adopt edilmiyor)

Kutudan yeni çıkmış bir UniFi cihazı, yerel ağda UDP 10001 portu üzerinden yayın (broadcast) yaparak kontrolcüsünü bulur. Yayın trafiği yerel ağın dışına çıkmaz; bu nedenle başka bir şehirdeki ofiste bulunan cihaz, VPS üzerindeki bir kontrolcüyü asla keşfedemez. Bu durum Katman 3 (Layer 3) benimseme sürecidir ve çoğu kullanıcının takıldığı yer burasıdır. Cihazda veya kontrolcüde bir sorun yoktur; sadece cihazın nereye bakması gerektiği belirtilmemiştir.

Öncelikle kontrolcüye hangi adresi dağıtması gerektiğini bildirin. Kontrolcünün Ayarlar (Settings) bölümündeki Sistem (System) kısmında, geçersiz kılma (override) seçeneğine sahip bir "inform host" ayarı bulunur. Burayı VPS'inizin genel ana bilgisayar adı (hostname) veya IP adresi ile yapılandırın. Bu ayar yapılmazsa kontrolcü, kendi arayüzünde gördüğü adresi duyurur; Docker köprü ağı içinde bu adres 172.18.0.3 gibi özel bir IP'dir. Cihaz bu adresi alır, ancak bu adrese yönlendirme yapamadığı için tekrar arama moduna döner.

Ardından cihazı bu adrese yönlendirin. Uzak yerel ağdaki cihaza SSH ile bağlanın. Fabrika ayarlarındaki bir cihaz, ubnt kullanıcı adı ve ubnt parolası ile giriş kabul eder:

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

Daha yeni cihaz yazılımları sizi kabuk (shell) yerine bir menüye yönlendirir. Aynı işlemi tek bir komut olarak çalıştırın:

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

Cihaz artık kontrolcüde benimsenmeye hazır olarak görünür. "Adopt" butonuna tıkladığınızda durum "Adopting" olarak değişir. Herkesi şaşırtan kısım şudur: genellikle set-inform komutunu ikinci kez çalıştırmanız gerekir. Cihaz, yapılandırma (provisioning) aşamasına geçmek için yeniden başlar ve kontrolcünün henüz değiştirmeyi tamamlamadığı, kendi hafızasındaki eski inform URL'sine geri döner. Durum "Adopting" iken komutu tekrar çalıştırmak, devir işlemini tamamlar. Cihazın mevcut inform URL'sini ve durumunu görmek için cihaz üzerinde info komutunu yazın.

Cihaz daha önce başka bir kontrolcü tarafından benimsendiyse, set-inform komutu tek başına yeterli olmaz; çünkü cihaz hala eski kontrolcünün kimlik bilgilerini tutuyordur. Öncelikle cihazı reset butonuyla veya eski kimlik bilgileriyle SSH üzerinden set-default komutunu kullanarak fabrika ayarlarına döndürün.

Birkaç cihazdan fazlası için DHCP yöntemini kullanın. DHCP (dynamic host configuration protocol) 43 numaralı seçenek, satıcıya özel bir değer taşır ve UniFi cihazları inform URL'sini 2 numaralı alt seçenekten (suboption) okur. Onaltılık (hex) dizgiyi herhangi bir Linux makinesinde oluşturun:

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 için 31 baytlık bir dizgi 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d çıktısını verir. Bu sonucu yönlendiricinizin DHCP 43 numaralı seçenek alanına onaltılık değer olarak yapıştırın. O ağda açılan her cihaz, SSH ile hiçbir işlem yapmanıza gerek kalmadan, kira (lease) süresi üzerinden kontrolcü adresini öğrenir. Eski kılavuzlar bunun yerine 1 numaralı alt seçeneği, yani 0104 ve ardından IPv4 adresinin onaltılık formatta dört baytını gösterir; cihazlar bu formatı da hala kabul etmektedir.

Sitede DNS hizmetini siz yönetiyorsanız üçüncü bir yol daha vardır. UniFi cihazı açılışta unifi ana bilgisayar adını çözümlemeye çalışır. Bu nedenle, VPS adresinizi işaret eden bir unifi A kaydı, cihaz bazlı hiçbir işlem yapmadan cihazların benimsenmesini sağlar. Bu yöntem yalnızca cihazların kullandığı DNS çözümleyiciyi kontrol ettiğiniz durumlarda işe yarar.

Hangi UniFi portlarının açılması, hangilerinin gizli tutulması gerektiği

Uzak bir noktadan erişilebilir olması gereken yalnızca iki port vardır.

TCP 8080, inform kanalıdır ve benimsenen (adopted) her cihaz buna bağlanır. İçerik, cihazın benimsenme sırasında kontrolcüden aldığı bir anahtarla AES şifrelenmiştir; bu nedenle burada normal ayar düz HTTP'dir.
UDP 3478, cihazların kontrolcüye giden yolu açık tutmak için kullandığı STUN (session traversal utilities for NAT) protokolüdür.

Diğer her şey bir VPS üzerinde kapalı kalmalıdır.

TCP 8443, yönetici arayüzüdür. Bu port asla herkese açık olmamalıdır. Kontrolcünün yönettiği her sitenin yapılandırmasını tek bir parola arkasında tutar.
UDP 10001 ve UDP 1900, yayın (broadcast) keşfi içindir. Yayınlar internet üzerinden geçmez, bu yüzden bunları açmak hiçbir işe yaramaz.
TCP 8880 ve TCP 8843, misafir portalı yönlendirmeleridir. Yalnızca bir misafir portalı çalıştırıyorsanız bunları açın.
TCP 6789 mobil hız testi, UDP 5514 ise uzak syslog içindir. Bunları kullandığınızda ekleyin.
TCP 27117, MongoDB içindir. Yukarıdaki compose dosyasında veritabanı hiçbir port yayınlamaz, bu yüzden yalnızca dahili Docker ağında var olur. Bunu bu şekilde tutun.

Sitelerinizin statik genel IP adresleri varsa, yalnızca bunlara izin verin:

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 güvenlik duvarı için ufw temelleri, bu kuralların varsaydığı varsayılan reddetme (deny) kurulumunu kapsar.

Burada insanları her seferinde tuzağa düşüren bir durum vardır. Docker'ın yayınladığı portlar ufw'yi devre dışı bırakır. Bir portu yayınlamak, NAT ve yönlendirme kurallarını doğrudan iptables içine yazar ve bu trafik ufw'nin yönettiği INPUT zincirinde değil, Docker'ın kendi zincirinde filtrelenir. Bu nedenle ufw deny 8443, ufw status içinde doğru görünse bile port dünyaya açık kalır. Bunu asla VPS'in kendisinden değil, başka bir makineden test edin:

nc -vz vps.example.com 8443

İstediğiniz sonuç bir bağlantı reddi veya zaman aşımıdır. Eğer bağlantı kurulursa, ufw ne derse desin port herkese açıktır. Güvenilir çözüm, zaten compose dosyasında yer alan yöntemdir: portu 127.0.0.1 üzerinde veya bir tünel adresi üzerinde yayınlayın, böylece Docker onu asla genel arayüze bağlamaz. DOCKER-USER zincirindeki bir kural da işe yarar, ancak bağlama (binding) işlemi daha basittir ve kural sıralamasındaki bir hata bunu geçersiz kılamaz.

Ubiquiti'nin kendi yükleyicileri hakkında ne söylenebilir?

Ubiquiti, Network Application için bir Debian paketi yayınlamaktadır. Bu paket çalışır durumdadır ancak güncel Ubuntu sürümlerinde, dağıtımın artık yanıt vermediği bir MongoDB sorunu ortaya çıkarır: Ubuntu 22.04 ve 24.04 sürümleri MongoDB sunucu paketi içermez; bu nedenle MongoDB'nin kendi deposunu eklemek ve sürümleri manuel olarak eşleştirmek zorunda kalırsınız. Yukarıdaki container, bu eşleştirmeyi sabitlenmiş bir etiket (tag) ile otomatik olarak yapar; bu rehberde bu yöntemin tercih edilmesinin nedeni budur.

Ubiquiti'nin daha yeni self-hosted ürünü, UniFi uygulamalarını Podman container'ları içinde çalıştıran ve donanım konsollarıyla aynı UniFi OS deneyimini sunan UniFi OS Server'dır. Ağustos 2026 itibarıyla bu ürün, x86_64 mimarili Ubuntu 22.04 veya 24.04, slirp4netns ile birlikte Podman 4.3.1 veya daha yeni bir sürüm gerektirir. Minimum 2 vCPU ve 4 GB RAM, önerilen ise 4 vCPU ve 8 GB RAM talep eder. Yükleyici, indirme sayfasında ücretsiz bir Ubiquiti hesabı arkasında yer aldığından, rehbere yapıştırılabilecek sabit bir URL adresi bulunmamaktadır. Bu yükleyici, uosserver adında bir sistem kullanıcısı oluşturur ve container'ları bu kullanıcı yetkisiyle çalıştırır. Üreticinin kendi paketleme yöntemini tercih ediyorsanız bunu seçin. Sürümleri kendiniz sabitlemek ve sunucuyu diğer işleriniz için esnek tutmak istiyorsanız container yığınını tercih edin.

UniFi yedeklerinin konumu ve sunucudan nasıl alınacağı

Controller, yedeklerini Ayarlar (Settings) içerisindeki yedekleme bölümünde belirlediğiniz zamanlamaya göre oluşturur ve kaç adet yedek tutulacağını da yine buradan ayarlarsınız. Dosyalar container içerisinde /config/data/backup/autobackup dizinine kaydedilir; bu dizin ana makinede (host) ~/unifi/config/data/backup/autobackup yoluna karşılık gelir ve dosyalar autobackup_10.5.67_20260813_1200_1755086400004.unf benzeri bir isimlendirme düzenine sahiptir.

Dosyaların gerçekten oluşup oluşmadığını kontrol edin:

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

Zamanlamayı ayarladıktan bir gün sonra dizinin boş olması, yeni container kurulumlarında bilinen bir sorundur. Uygulama autobackup dizininin var olmasını bekler ancak bu dizini kendisi oluşturmaz; bu nedenle zamanlanmış görev sessizce hiçbir şey yazmaz. Dizini container'ı çalıştıran kullanıcı yetkileriyle kendiniz oluşturun ve bir sonraki çalıştırma zamanını bekleyin:

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

Bir .unf dosyası, site yapılandırmasını ve yönetici hesaplarını içerir; bu nedenle dosyayı bir kriptografik anahtar gibi değerlendirin. Dosyaların kopyalarını kontrolünüz altındaki bir makineye çekin ve gizli tutun:

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

Geri yükleme tek adımlı bir işlemdir. Yeni bir kurulumdaki kurulum sihirbazının ilk sayfası, bir yedekleme dosyasından geri yükleme seçeneği sunar; çalışan bir controller ise aynı ayarlar sayfasından yedek kabul eder. Geri yüklemeyi aynı veya daha yeni bir sürüme yapın. Geri yükleme yaptığınız uygulamadan daha yeni bir sürüm tarafından oluşturulan yedek dosyası reddedilir; bu nedenle dosya ile birlikte sürüm numarasını da not etmeniz gerekir.

Controller yükseltmesinin bozabileceği unsurlar

Her yükseltme işleminden önce manuel bir yedek alın ve bu yedeği indirin. Ardından:

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

Veritabanı, sorun çıkma ihtimali en yüksek olan ilk bileşendir. mongo etiketini uygulama ile aynı düzenleme içerisinde yeni bir ana sürüme yükseltmek, controller'ın başlamamasına neden olan en hızlı yoldur; çünkü MongoDB, aşamalı bir yükseltme yapılmadan farklı bir ana sürüme ait veri dosyalarını açmaz. Uygulamayı kendi başına yükseltin. MongoDB'yi ise her seferinde tek bir ana sürüm atlayacak şekilde, elinizde güncel bir yedek varken ayrı olarak yükseltin.

Bellek, dikkat edilmesi gereken bir sonraki unsurdur. Daha büyük bir sürüm, daha büyük bir heap alanı gerektirir. Uygulama başlıyor, birkaç dakika çalışıyor ve ardından kapanıyorsa MEM_LIMIT ve MEM_STARTUP değerlerini 1536 veya 2048 olarak yükseltip yeniden başlatın. Host üzerindeki dmesg -T | grep -i 'killed process' komutu, sürecin kernel tarafından sonlandırılıp sonlandırılmadığını doğrular.

Cihaz yazılımı (firmware), insanların unuttuğu bir risk faktörüdür. Controller kendini yükselttikten sonra, sisteme dahil edilmiş cihazlar için yazılım yükseltmeleri önerir. Bunları aynı oturum içerisinde onaylamayın. Bir cihaz yükseltmesi ile controller yükseltmesi çakışırsa ve aralarındaki bağlantı koparsa, cihaz yarı yapılandırılmış durumda kalabilir; bu da sizi başka bir binadaki donanıma SSH üzerinden set-inform yapmaya zorlar.

Yükseltme süreci kulağa geldiğinden daha zahmetsizdir. Controller yeniden başlarken cihazlar trafiği iletmeye devam eder, bu nedenle kullanıcılar herhangi bir kesinti yaşamaz. Duracak olan tek şey, eğer controller tarafından sağlanıyorsa misafir portalı ve RADIUS servisidir; bu yüzden bu servislerin kullanılmadığı bir zaman dilimini seçin. Gece saat 3'te sessizce kapanan bir controller'dan haberdar olmak önemlidir, bu nedenle bir Uptime Kuma durum izleyicisi'ni 8080 numaralı porta yönlendirin ve sizi bilgilendirmesini sağlayın.

Dürüst alternatif: Ubiquiti barındırmalı konsol

Ubiquiti, aynı işi bir hizmet olarak satmaktadır. Ağustos 2026 itibarıyla Official UniFi Cloud Console aylık 29 dolar başlangıç fiyatıyla sunulmakta olup 500 adede kadar UniFi cihazını yönetebilmektedir; güncellemeler ve yedeklemeler Ubiquiti tarafından yürütülür. Az önce kurduğunuz self-hosted uygulama ücretsizdir ve herhangi bir abonelik ücreti gerektirmez.

Tek bir site yönetiyorsanız ve yama yapmak yerine ödeme yapmayı tercih ediyorsanız barındırmalı konsolu seçin. Birden fazla site yönetiyorsanız veya kontrolcünün kontrolünüz altındaki bir ağda bulunmasını ve çalıştırdığınız diğer servislerle aynı sunucuyu paylaşmasını istiyorsanız bir VPS tercih edin. Küçük ölçekte maliyet farkı gerçektir ancak dikkate alınması gereken tek husus bu değildir: barındırmalı konsol başkasının çalışma süresine (uptime) bağlıdır, VPS ise diskinin dolduğu gece dahil olmak üzere tamamen sizin sorumluluğunuzdadır. Sunucu her iki durumda da maliyetini karşılayacaksa, bir VPS üzerinde başka neleri çalıştırabileceğiniz bir sonraki okumanız gereken listedir.

FAQ

UniFi cihazım neden VPS üzerindeki bir controller'a adopt olmuyor?

Cihazlar, controller'ları UDP 10001 portu üzerinden yayın (broadcast) yaparak keşfederler. Yayın trafiği yerel ağ dışına çıkmadığı için uzak bir noktadaki cihaz, internet üzerindeki bir controller'ı bulamaz. Controller sistem ayarlarından inform host override kısmını VPS ana makine adınızla güncelleyin, ardından cihaz üzerinde ssh ubnt@<device-ip> komutunu ve ardından set-inform http://vps.example.com:8080/inform komutunu çalıştırarak cihazı yönlendirin. Cihaz "Adopting" durumunda takılı kalırsa, bu durumdayken set-inform komutunu tekrar çalıştırın. Cihaz daha önce başka bir controller tarafından yönetildiyse, eski controller'ın kimlik bilgilerini tuttuğu için öncelikle fabrika ayarlarına döndürün.

Self-hosted bir UniFi controller ne kadar RAM'e ihtiyaç duyar?

2 GB alt sınırdır, 4 GB ise rahat bir çalışma ortamı sağlar. Uygulama Java ve MongoDB bileşenlerinden oluşur ve her ikisi de belleği ayrı yönetir: container imajı Java heap boyutunu varsayılan olarak 1024 MB ile sınırlar, MongoDB'nin WiredTiger önbelleği ise 1 GB üzerindeki RAM'in yarısını kullanır. x86_64 mimarisinde, işlemcinin AVX desteği sunduğunu grep -m1 -o avx /proc/cpuinfo ile doğrulayın; çünkü MongoDB 5.0 ve sonraki sürümler bu destek olmadan çalışmaz ve veritabanı container'ı sürekli yeniden başlar.

8443 numaralı portu internete açmalı mıyım?

Hayır. 8443 numaralı port yönetim arayüzüdür ve controller'ın yönettiği tüm sitelerin yapılandırmasını içerir. Bu portu 127.0.0.1 üzerinde yayınlayın ve ssh -L 8443:127.0.0.1:8443 you@vps.example.com ile erişin ya da bir WireGuard veya Tailscale adresi ile sınırlandırın. Sadece TCP 8080 ve UDP 3478 portlarının uzak noktalardan erişilebilir olması gerekir; eğer uzak noktaların IP adresleri sabitse, erişimi bu IP'lerle kısıtlayabilirsiniz. Docker üzerinden yayınlanan bir portun ufw tarafından filtrelenmediğini unutmayın; bu nedenle ufw status çıktısına güvenmek yerine testi dış bir makineden gerçekleştirin.

VPS üzerindeki controller çökerse ağım çalışmaya devam eder mi?

Evet. Adopt edilmiş erişim noktaları ve anahtarlar, controller tarafından daha önce gönderilen yapılandırmayı kullanarak trafiği iletmeye devam eder; bu sayede istemciler bağlı kalır ve Wi-Fi çalışmayı sürdürür. Kesintiye uğrayan tek şey yönetimdir. Dashboard ve istatistik verileri ile controller tarafından sağlanan misafir portalı kimlik doğrulaması veya RADIUS sunucusu gibi canlı özellikler devre dışı kalır.

UniFi controller otomatik yedeklemeleri nereye kaydeder?

Burada kullanılan container imajında yedekler, ana makinedeki veri yolunuzun altında bulunan data/backup/autobackup dizinine, /config/data/backup/autobackup yolu üzerinden kaydedilir. Yedekler, sürüm ve zaman damgası ile adlandırılmış .unf dosyalarıdır. Bazı yeni kurulumlarda autobackup dizini mevcut olmayabilir; bu durumda zamanlanmış yedekleme herhangi bir hata vermeden hiçbir dosya oluşturmaz. Bu nedenle, yedekleme zamanlamasını ayarladıktan bir gün sonra dizini kontrol edin ve boşsa dizini kendiniz oluşturun. Dosyaları VPS dışına kopyalayın, çünkü bir .unf dosyası tüm site yapılandırmasını ve yönetici hesaplarını içerir.

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