CasaOS Kurulumu: Kiralık Sunucu Üzerinde Debian 12 ile Adım Adım Kurulum ve Deneyimlerim

CasaOS’u uzak bir sunucu ortamında deneyimlemek için önce bir sunucu kiraladım ve başlangıç noktası olarak Debian 12 tercih ederek kuruluma buradan başladım. Amacım, CasaOS’u yalnızca bir masaüstü cihazda ya da ev sunucusunda değil, gerçek bir sunucu senaryosu üzerinde kurup; performans, stabilite, kaynak kullanımı ve yönetilebilirlik açısından nasıl davrandığını görmekti. Bu süreçte kurulum adımlarını yalnızca “nasıl yapılır” şeklinde değil, aynı zamanda neden bu şekilde yaptım, Debian 12’yi seçmemin teknik gerekçeleri nelerdi ve karşılaşılabilecek potansiyel sorunlar hangi durumlarda ortaya çıkabilir gibi sorular üzerinden ele alarak ilerledim. Bu yazı da tam olarak bu deneyimin, teknik notların ve pratik gözlemlerin derli toplu bir özeti niteliğinde.

Neden Kendi Sunucuma CasaOS Kurmak İstedim?

CasaOS’u kendi sunucuma kurmak istememin temel nedeni, kişisel projelerimi ve self-hosted servislerimi tek bir yerde, daha düzenli ve yönetilebilir bir yapıda toplamak istememdi. Uzun süredir projelerimi doğrudan terminal üzerinden yönetiyor olsam da, bazı durumlarda kurulan servislerin durumunu hızlıca görebileceğim, temel işlemleri panel üzerinden takip edebileceğim ve buna rağmen sistem üzerinde tam kontrolü kaybetmeyeceğim bir arayüz ihtiyacı hissettim. CasaOS tam olarak bu noktada, “görsel yönetim kolaylığı + terminalden müdahale esnekliği” dengesini sağlama konusunda dikkatimi çeken bir çözüm oldu.

Ayrıca bu süreci yalnızca bir deneme ortamı olarak değil, gerçekçi bir senaryo üzerinden test etmek istedim. Bu yüzden CasaOS’u lokal bir cihaz yerine kiraladığım bir sunucu üzerinde deneyimlemek daha anlamlı geldi. Böylece ağ erişimi, kaynak kullanımı, servis davranışı ve uzaktan yönetim gibi konularda gerçek dünya koşullarına yakın bir deneyim elde etmiş oldum. Kısacası CasaOS’u denemekteki amacım, hazır bir panel kullanmak değil; kendi altyapım içinde daha düzenli, merkezi ve yönetilebilir bir self-host ortamı oluşturup oluşturamayacağımı görmekti.

Neden Debian ve Neden Özellikle Debian 12?

Debian’ı tercih etmemin temel nedeni; stabilite, paket kararlılığı ve sunucu ortamlarında uzun yıllardır kendini kanıtlamış bir yapıya sahip olması. Self-hosted servisler ve Docker tabanlı uygulamalar söz konusu olduğunda, benim için en önemli kriterlerden biri, sistemin gereksiz ek yazılımlar veya masaüstü bileşenleriyle şişmemesi ve arka planda “sakin” çalışması. Debian tam olarak bu noktada, minimal kurulum + düşük kaynak tüketimi + kararlı paket deposu üçlüsüyle güçlü bir zemin sunuyor. Özellikle terminal odaklı bir sunucu yönetiminde, Debian’ın öngörülebilir davranışı ve uzun vadeli güncelleme politikası benim için kritik bir avantaj.

Debian 12’yi seçmemin sebebi ise yalnızca “en yeni sürüm” olması değil; container teknolojileri ve modern Linux çekirdeği ile daha uyumlu bir çalışma sunması. Eski sürümlerde docker, network ve kernel modülleri tarafında zaman zaman ek konfigürasyona ihtiyaç duyulabiliyor. Debian 12 ile birlikte gelen güncel kernel, security patch’ler, systemd uyumluluğu ve kütüphane sürümleri, özellikle Docker ve CasaOS gibi katmanlı yapılar için daha sorunsuz ve güncel bir çalışma ortamı sağlıyor. Yani tercih, yalnızca rahatlık değil; teknik uyumluluk ve uzun vadeli sürdürülebilirlik motivasyonuna dayanıyor.

Bununla birlikte, her senaryo için Debian tek doğru seçenek olmayabilir. Örneğin sanallaştırma katmanı odaklı bir yapı kurulacaksa Proxmox, NAS ağırlıklı bir kullanımda TrueNAS, masaüstüne yakın bir deneyim isteyenler için ise Ubuntu LTS daha mantıklı bir tercih olabilir. Ancak benim bu projedeki önceliğim, hafif, temiz, kararlı ve Docker’a odaklı bir sunucu ortamı kurmaktı — bu nedenle Debian 12, hem teknik hem pratik açıdan bu kurulum için en uygun zemin oldu.

Debian’ı Tercih Etme Nedenlerim

Debian’ı tercih etmemin en önemli nedeni, sunucu tarafında güvenebileceğim kararlı ve öngörülebilir bir yapı sunması. Self-hosted servisler ve Docker tabanlı uygulamalarla çalışırken, benim için işletim sisteminin “arka planda görünmez” olması önemli. Yani sistemi sürekli ayarlarla uğraştıran, gereksiz paketlerle şişmiş, sürüm geçişlerinde beklenmedik davranışlar sergileyen bir yapıdan ziyade; stabil, sade ve tutarlı çalışan bir temel istiyorum. Debian bu noktada tam olarak ihtiyacımı karşılıyor.

Bir diğer tercih sebebim, Debian’ın minimal kurulum yaklaşımı. Kurulumdan sonra gelen paket seti olabildiğince sade ve gereksiz bileşen içermiyor. Bu sayede hem kaynak tüketimi düşük kalıyor hem de kurulum sonrası temizlik yapmak zorunda kalmıyorum. Özellikle uzak sunucularda CPU ve RAM’i gereksiz süreçlerle harcamamak, Docker konteynerlerinin daha verimli çalışması için büyük avantaj sağlıyor.

Ayrıca Debian’ın paket kararlılığı ve uzun vadeli güncelleme politikası da benim açımdan kritik bir etken. Rolling-release dağıtımlarda yeni özelliklere hızlı erişmek mümkün olsa da, sunucu tarafında asıl ihtiyacım yeni paket değil; sorunsuz ve tutarlı çalışan bir sistem. Debian depolarındaki yazılımlar biraz daha konservatif ilerlese bile, bu yaklaşım özellikle üretime yakın senaryolarda bana daha fazla güven veriyor.

Son olarak Debian ekosisteminin yaygınlığı ve topluluk desteği de tercihimi güçlendiren bir unsur. Karşılaşılan bir sorun için dökümantasyon bulmak, tartışma başlıklarına ulaşmak ve çözüme gitmek çoğu zaman oldukça kolay. Dolayısıyla bu kurulumda amacım; deneysel bir dağıtım denemek değil, CasaOS ve Docker için sağlam bir temel oluşturmak olduğu için Debian benim için en mantıklı seçenek oldu.

Debian 12 Seçmemin Teknik Gerekçeleri

Debian 12’yi seçmemin nedeni sadece “en güncel sürüm olması” değildi; CasaOS ve Docker tabanlı bir yapı kuracağım için, işletim sisteminin modern container teknolojileriyle uyumlu ve uzun vadede sorunsuz çalışabilecek bir zemin sunması benim için öncelikliydi. Debian 12 ile birlikte gelen güncel kernel sürümü, network bileşenleri ve kütüphane versiyonları, özellikle container ağ yapıları, volume yönetimi ve sistem servislerinin işleyişi konusunda daha stabil ve güncel bir mimari sağlıyor.

Eski sürümlerde zaman zaman karşılaşılan paket bağımlılığı problemleri, eksik kernel modülleri veya ek yapılandırma gerektiren network davranışları, Debian 12’de büyük ölçüde giderilmiş durumda. Bu sayede Docker kurulumu, container’ların başlatılması ve CasaOS’un arayüz üzerinden servis yönetimi gibi süreçler ek yamalarla uğraşmadan, daha sorunsuz şekilde çalışabiliyor. Özellikle overlay network, cgroup, systemd entegrasyonu gibi mekanizmaların güncel sürümlerle birlikte daha olgun bir seviyeye gelmesi, bu kurulum için önemli bir tercih sebebi oldu.

Bunun yanında Debian 12, güvenlik yamaları ve paket güncellemeleri açısından da dengeli bir yaklaşım sunuyor. Sık ama agresif olmayan güncellemeler, sunucu ortamında hem güvenlik hem de kararlılık tarafında sağlıklı bir denge oluşturuyor. Uzun vadede bu sistemi yalnızca bir test ortamı değil, zaman zaman aktif kullanım sağlayacağım bir self-host ortamı olarak düşündüğüm için, Debian 12’nin bu dengeli yapısı benim için önemli bir avantaj sağladı.

Kısacası Debian 12, bu kurulum özelinde bana; güncel container uyumluluğu, daha az ek konfigürasyon ihtiyacı ve uzun vadede sürdürülebilir bir sistem zemini sunduğu için tercih ettiğim sürüm oldu.

Hangi Durumda Debian Yerine Başka Dağıtım Seçilebilir?

Debian bu kurulum için benim tercih ettiğim dağıtım olsa da, her senaryo için en doğru seçenek olmak zorunda değil. Bazı kullanım amaçlarında farklı dağıtımlar, ihtiyaçlara daha uygun bir çalışma ortamı sunabiliyor. Bu nedenle karar verirken yalnızca “hangi dağıtım daha popüler?” sorusuna değil, kurulacak yapının amacı ve sistemin rolüne odaklanmak gerektiğini düşünüyorum.

Örneğin hedef, konteyner tabanlı servislerden çok sanallaştırma altyapısı kurmak ise, Debian yerine Proxmox gibi hypervisor odaklı bir yapı çok daha doğru bir tercih olabilir. Benzer şekilde dosya depolama, paylaşım ve NAS ağırlıklı bir sistem planlanıyorsa, FreeBSD tabanlı TrueNAS gibi çözümler; ZFS entegrasyonu, snapshot yapısı ve veri bütünlüğü özellikleriyle Debian’a göre daha uygun bir platform sunar.

Masaüstüne yakın bir kullanım isteyen, grafik arayüzü sıkça kullanacak veya Linux’a daha yeni adım atan kullanıcılar için ise Ubuntu LTS sürümleri daha konforlu bir deneyim sağlayabilir. Paket erişimi, donanım uyumluluğu ve kullanıcı dostu dokümantasyon tarafında Ubuntu bazı durumlarda daha pratik olabilir. Öte yandan rolling–release mantığıyla çalışan Arch tabanlı sistemler, en güncel paketlere erişim önceliği gerektiren deneysel ortamlar için mantıklı olsa da, sunucu tarafında kararlılık beklentisi olduğunda her zaman en güvenli seçenek olmayabilir.

Özetle, dağıtım seçimini tek bir doğru üzerinden değil; kurulumun amacı, kullanım senaryosu ve uzun vadeli beklenti üzerinden yapmak daha sağlıklı. Benim amacım Docker ve CasaOS için kararlı, hafif ve öngörülebilir bir temel oluşturmak olduğu için Debian tercih ettim; ancak farklı ihtiyaçlarda başka dağıtımların öne çıkması gayet doğal.

Kiralık Sunucu Üzerinde Başlangıç Ayarları

Kiraladığım sunucuya Debian 12 kurulumu tamamlandıktan sonra, CasaOS kurulumuna geçmeden önce sistemi temel düzeyde hazırlamayı tercih ettim. Bu aşama, çoğu kişi tarafından atlanıyor gibi görünse de, özellikle uzak bir sunucu üzerinde çalışırken güvenlik, bağlantı ve temel sistem kararlılığı açısından kritik bir adım. Bu yüzden kuruluma başlamadan önce ilk olarak giriş yetkilerini, güncellemeleri ve temel paket yapısını düzenli bir hale getirdim.

Sunucuyu ilk açtığımda yalnızca root hesap ile giriş yapılabiliyordu. Root hesabıyla doğrudan çalışmak güvenlik ve operasyonsel hata riski oluşturabileceği için önce normal bir kullanıcı hesabı oluşturdum ve gerekli yetkileri verdim. Ardından sistem paketlerini güncelledim ve Debian’ın kurulumdan gelen temel bileşenlerini kontrol ederek gereksiz servislerin çalışmadığından emin oldum. Bu sayede CasaOS kurulumuna başlamadan önce elimde temiz, güncel ve minimum bileşenli bir temel sistem olmuş oldu.

Bu aşamada yaptığım işlemleri “kurulumdan önce yapılması gereken kritik hazırlıklar” olarak görüyorum. Çünkü self-hosted servisler, Docker konteynerleri ve yönetim panelleri her ne kadar uygulama katmanında çalışıyor gibi görünse de, aslında hepsinin sağlıklı çalışması tabandaki sunucu konfigürasyonuna bağlı. Bu nedenle CasaOS’a geçmeden önce bu hazırlık adımlarını tamamlamak, ileride çıkabilecek birçok sorunu en baştan engellemiş oluyor.

Sunucu Sağlayıcısı Seçimi ve Minimum Donanım Önerisi

Kiralık sunucu seçiminde benim için en önemli kriter; yüksek donanım rakamları değil, stabilite, ağ performansı ve veri merkezi güvenilirliği oldu. CasaOS ve Docker tabanlı servisler çalıştıracağım için, CPU gücünden çok disk yapısı, bağlantı kalitesi ve gecikme değerleri benim açımdan daha belirleyici faktörlerdi. Bu nedenle tercihimi, agresif fiyat yerine düzenli altyapı bakımı ve istikrarlı network performansı sunan bir sağlayıcıdan yana kullandım.

Bu kurulum için başlangıç seviyesinde tercih edilebilecek mantıklı minimum donanım bence şu aralıkta olmalı:

• CPU: 2 vCPU (yüksek frekans tercih sebebi)
• RAM: Minimum 2 GB (ideal başlangıç 4 GB)
• Disk: 20–40 GB SSD / NVMe
• Bağlantı: En az 1 Gbps port + düşük gecikme
• Depolama tipi: HDD yerine mutlaka SSD / NVMe

CasaOS tek başına ağır bir sistem değil, ancak konteyner sayısı arttıkça RAM ve I/O ihtiyacı da artıyor. Bu nedenle “en ucuz makine yeter” yaklaşımı kısa vadede çalışsa bile, ileride servis sayısı büyüdüğünde darboğaz oluşturmaya başlıyor. Özellikle NVMe depolamanın Docker volume erişiminde sağladığı hız farkı, pratik kullanımda ciddi avantaj sağlıyor.

Sunucu seçiminde göz önünde bulundurduğum ikinci önemli konu ise konum ve gecikme değerleri oldu. Kullandığım servislerin büyük çoğunluğu kendim tarafından erişileceği için, sunucunun Avrupa bölgesinde konumlanması daha stabil ve düşük gecikmeli bir bağlantı sağladı. Eğer servislerin dış erişime açık kullanılacağı bir senaryo söz konusuysa, hedef kullanıcı veya lokasyona göre veri merkezi seçimi yapmak da sağlıklı bir tercih olacaktır.

Son olarak şunu özellikle vurgulamak isterim: Bu yapı bir yüksek trafikli prodüksiyon sistemi değil, kişisel self-host ortamı ve deneme alanı niteliğinde. Bu nedenle donanımı seçerken amacım “maksimum kapasite” değil, dengeli ve sürdürülebilir bir başlangıç seviyesi oluşturmaktı. İhtiyaç büyüdüğünde ölçeklendirmek her zaman mümkün, ancak temelde stabil bir makine ile başlamak çok daha doğru bir yaklaşım.

Debian 12 İlk Kurulum Sonrası Yapılması Gerekenler

Debian 12 kurulumunu tamamladıktan sonra, CasaOS ve Docker tarafına geçmeden önce sistemi temel seviyede düzenlemek ve güvenli bir başlangıç ortamı oluşturmak benim için ilk adım oldu. Çünkü uzaktan erişilen bir sunucuda, kurulumdan sonra hiçbir ayar yapılmadan devam etmek; hem güvenlik hem de ileride karşılaşılabilecek hatalar açısından risk oluşturabiliyor. Bu yüzden önce sistemi güncelledim, kullanıcı yapısını düzenledim ve temel araçları kurarak ortamı stabil bir hale getirdim.

İlk olarak root hesapla giriş yaptıktan sonra, doğrudan root üzerinden çalışmak yerine yetkili bir kullanıcı hesabı oluşturdum. Bu yaklaşım hem güvenlik hem de yanlışlıkla yapılabilecek sistem seviyesindeki hataları azaltmak için önemli. Ardından sistem paketlerini güncelleyerek Debian’ın kurulumdan gelen çekirdek ve kütüphane sürümlerini güncel hale getirdim. Böylece CasaOS kurulumu sırasında eski paket veya bağımlılık kaynaklı sorun yaşama riskini en baştan düşürmüş oldum.

Bu aşamada ayrıca temel yardımcı paketleri kurmayı ve sistemin gereksiz servisler çalıştırmadığından emin olmayı da tercih ettim. SSH bağlantısının sağlıklı çalışıp çalışmadığını kontrol ettim, zaman senkronizasyonunun doğru olduğundan emin oldum ve ileride kuracağım Docker servislerinin ihtiyaç duyacağı minimum altyapıyı hazırladım. Bu adımlar küçük gibi görünse de, özellikle uzak sunucu ortamında çalışırken “kuruluma zemin hazırlayan kritik hazırlık süreci” olarak görüyorum.

Kısacası Debian 12 kurulumundan sonra yaptığım bu düzenlemeler, CasaOS’a geçmeden önce sistemi temiz, güncel ve öngörülebilir bir hale getirmeyi amaçlıyor. Bu yaklaşım sayesinde kurulum süreci daha sorunsuz ilerliyor ve ileride oluşabilecek pek çok sorun daha en başta engellenmiş oluyor.

Güvenlik ve Bağlantı Hazırlığı

Debian 12 kurulumu tamamlandıktan ve temel düzenlemeler yapıldıktan sonra, CasaOS kurulumuna geçmeden önce üzerinde durduğum en kritik adımlardan biri de güvenlik ve bağlantı hazırlığı oldu. Çünkü uzak bir sunucu üzerinde çalışırken, henüz hiçbir servis kurulu değilken yapılan güvenlik ayarları, ileride kurulacak tüm servislerin üzerinde yükseleceği koruma katmanı niteliğinde. Bu nedenle kurulumdan önce SSH erişimi, bağlantı yetkileri ve temel koruma katmanlarını gözden geçirerek sistemi daha güvenli bir hale getirmeyi tercih ettim.

İlk olarak SSH bağlantısı üzerinden root kullanıcı ile doğrudan erişimi kapatmak yerine, önce yetkili bir kullanıcı oluşturup sudo yetkisi vererek bağlantıyı bu kullanıcı üzerinden kullanacak şekilde yapılandırdım. Ardından SSH portunun erişebilirliğini kontrol ettim, mümkünse varsayılan portu değiştirdim ve yalnızca ihtiyacım olan IP aralıklarından erişim izinlerinin açık olduğundan emin oldum. Bu adım, özellikle bot taramaları ve otomatik brute-force girişimlerine karşı ilk savunma hattı olarak önemli bir rol oynuyor.

Sonraki aşamada basit ama etkili bir güvenlik katmanı olarak firewall (ufw / iptables) yapılandırmasını gerçekleştirdim. CasaOS kurulumu sırasında ihtiyaç duyulacak bağlantı portları dışındaki tüm giriş trafiğini sınırlayarak, sistemi gereksiz erişime kapattım. Opsiyonel olarak fail2ban gibi brute-force engelleme mekanizmalarını da değerlendirdim; özellikle SSH denemelerinin yoğun olduğu ortamlarda bu tür araçlar ek güvenlik tamponu sağlıyor.

Ağ tarafında ise DNS çözümlemesi, saat senkronizasyonu ve bağlantı kararlılığını kontrol ederek sunucunun dış dünya ile iletişiminin sağlıklı şekilde çalıştığından emin oldum. Çünkü network kaynaklı en küçük bir problem bile, ilerleyen aşamalarda Docker container’larının paket indirmesinden CasaOS güncellemelerine kadar birçok sürecin beklenmedik şekilde aksamasına neden olabiliyor.

Özetle bu aşamadaki hedefim, CasaOS’u kurmadan önce sunucuyu erişim kontrollü, güvenli ve bağlantı açısından stabil bir başlangıç noktasına taşımaktı. Kurulumdan önce yapılan bu güvenlik ve bağlantı hazırlığı, hem sistem yönetimi açısından önemli bir alışkanlık hem de ileride çıkabilecek birçok sorunu daha başlamadan engelleyen kritik bir adım.

CasaOS Kurulumu: Terminal Üzerinden Adımlar

CasaOS kurulumuna geçerken süreci tamamen terminal üzerinden ilerletmeyi tercih ettim. Bunun nedeni, uzaktaki bir sunucu ortamında görsel arayüz yerine doğrudan kontrol edilebilir, şeffaf ve takip edilebilir bir kurulum süreci oluşturmak istememdi. Kurulum adımlarında önce Docker altyapısını hazırladım, ardından CasaOS’un resmi kurulum komutu ile sistemi çalıştırdım. Aşağıdaki adımlar, benim uyguladığım sıralamayı ve bu tercihin teknik gerekçelerini içeriyor.

Docker Kurulumu ve Doğrulama

CasaOS Docker üzerinden çalıştığı için, kurulumdan önce sistemde Docker’ın sorunsuz bir şekilde hazır olması önemli. İlk adımda paketleri güncelledim ve Docker’ı resmi depo üzerinden kurdum:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg

Ardından Docker reposunu ekleyip kurulumu tamamladım:

curl -fsSL https://get.docker.com | sudo sh

curl -fsSL https://get.docker.com | sudo sh

Kurulum sonrası versiyon doğrulaması yaptım:

docker --version
docker ps

docker --version
docker ps

Bu noktada amacım, CasaOS kuruluma geçmeden önce Docker’ın sorunsuz olarak çalıştığını teyit etmek ve olası sorunları en baştan görmektı.

CasaOS Kurulum Komutu ve İlk Başlatma

CasaOS, resmi kurulum script’i ile geliyor. Debian 12 ortamında kurulumu şu komutla başlattım:

curl -fsSL https://get.casaos.io | sudo bash

curl -fsSL https://get.casaos.io | sudo bash

Kurulum sırasında script paketleri indirerek gerekli bağımlılıkları otomatik olarak yapılandırdı. Süreç tamamlandığında panel erişimi için sunucunun IP adresi şu şekilde görüntülendi:

http://SUNUCU_IP:80

http://SUNUCU_IP:80

İlk erişimde kısa bir başlangıç sihirbazı ile kullanıcı hesabı oluşturuluyor. Bu adımda özellikle dikkat ettiğim nokta, zayıf parola kullanmamak ve yönetici hesabını tek kullanıcıya sabitlememek oldu.

İlk Arayüz Girişi ve Temel Kontroller

Kurulumun ardından terminale geri dönerek container’ların sağlıklı çalışıp çalışmadığını kontrol ettim:

docker ps

docker ps

Bu aşamada baktığım noktalar:

• CasaOS servis container’ları çalışıyor mu?
• Log çıktılarında hata var mı?
• Port çakışması oluşmuş mu?

Ek olarak sistem hizmetlerinin genel durumunu kontrol ettim:

sudo systemctl status docker
sudo systemctl status casaos

sudo systemctl status docker
sudo systemctl status casaos

Kurulumdan sonra her şey sorunsuz görünse bile, özellikle ilk kurulumlarda kısa bir gözlem süresi geçirmek ve logları takip etmek ileride çıkabilecek sorunları erken fark etmek açısından oldukça faydalı.

Kısacası bu aşamada hedefim, CasaOS’u yalnızca “çalıştırmak” değil; kurulum sürecinin her adımını kontrol ederek stabil ve öngörülebilir bir yapı oluşturmak oldu. Bir sonraki bölümde, kuruluma paralel olarak karşılaşılabilecek olası hatalar ve çözüm yaklaşımlarını paylaşacağım.

Olası Hatalar ve Çözüm Notları

Kurulum süreci genel olarak sorunsuz ilerlese de, özellikle uzak bir sunucuda çalışırken bazı durumlarda beklenmedik hatalarla karşılaşmak mümkün. CasaOS ve Docker temelli bir kurulum olduğu için sorunların önemli bir kısmı genellikle paket bağımlılıkları, port çakışmaları veya network kaynaklı problemlere dayanıyor. Bu bölümde, kurulum sırasında veya sonrasında karşılaşılması muhtemel hataları ve bunlara yönelik pratik çözüm notlarını paylaşıyorum.

Docker Kurulmadı / Paket Çakışması

Bazı sunucu imajlarında önceden kurulmuş eski Docker sürümü, Podman veya containerd gibi bileşenler olabiliyor. Bu durum yeni kurulumu engelleyebiliyor.

Belirti:

• Kurulum script’i hata veriyor
• Docker başlatılamıyor
• docker ps çalışmıyor

Kontrol komutu:

dpkg -l | grep docker

dpkg -l | grep docker

Çözüm:
Eski veya çakışan paketleri kaldırıp yeniden kurmak genellikle sorunu çözüyor:

sudo apt remove docker docker-engine docker.io containerd runc -y
curl -fsSL https://get.docker.com | sudo sh

sudo apt remove docker docker-engine docker.io containerd runc -y
curl -fsSL https://get.docker.com | sudo sh

Amaç, CasaOS kurulmadan önce temiz ve güncel bir Docker ortamı oluşturmak.

Port Çakışması Sorunları

CasaOS arayüzü varsayılan olarak 80 portunu kullanıyor. Eğer sunucuda daha önce Nginx, Apache veya başka bir servis çalışıyorsa port çakışması oluşabiliyor.

Belirti:

• Panel açılmıyor
• Script başarıyla bitiyor ama erişim yok
• Log’larda “address already in use” hatası

Kontrol:

sudo lsof -i :80

sudo lsof -i :80

Çözüm seçenekleri:

1. Mevcut servisi yeniden yapılandırmak
2. CasaOS portunu değiştirmek
3. Gerekli değilse eski servisi kaldırmak

Benim yaklaşımım genelde önce mevcut servisleri gözden geçirmek, gerekirse reverse proxy planına geçmek yönünde oluyor.

DNS / Network Kaynaklı Erişim Hataları

Kurulum sırasında paket indirilememesi veya container’ların internet erişimi olmaması yaygın bir durum.

Belirti:

• Script indirilemiyor
• Container’lar update çekemiyor
• Temporary failure in name resolution

Kontrol:

ping -c 3 google.com
cat /etc/resolv.conf

ping -c 3 google.com
cat /etc/resolv.conf

Çözüm:
Gerekirse geçici olarak Google DNS eklemek sorunu çözebiliyor:

echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

Ardından bağlantıyı yeniden test etmekte fayda var.

Sunucu Kaynak Yetersizliği Durumları

CasaOS küçük sistemlerde bile çalışıyor, ancak Docker container sayısı arttıkça kaynak gereksinimi doğal olarak yükseliyor.

Belirti:

• Container’lar kapanıyor
• Servisler geç tepki veriyor
• OOM (out of memory) logları oluşuyor

Kontrol:

free -h
df -h
iotop

free -h
df -h
iotop

Pratik çözüm önerileri:

• Gereksiz container’ları durdurmak
• Swap alanı açmak (dikkatli kullanılmalı)
• NVMe disk tercih etmek
• Minimum donanım seviyesini yeniden gözden geçirmek

Benim yaklaşımım: yama yapmak yerine kaynak dengesini gerçek ihtiyaca göre büyütmek.

Kurulumdan Sonra Yaptığım İlk Ayarlar

Bazen panel açılır ancak arka plandaki servisler hatalı çalışır.

Kontrol:

docker ps
docker logs CASAOS_CONTAINER_ID

docker ps
docker logs CASAOS_CONTAINER_ID

Çoğu durumda sorun:

• eksik izinler
• volume yazma hatası
• port çakışması

gibi basit bir yapılandırma problemi çıkıyor.

Kurulumda karşılaşılan sorunların çoğu CasaOS kaynaklı değil, altyapı ve ortam konfigürasyonu ile ilişkili oluyor. Bu nedenle kurulumdan önce:

• sistemi güncel tutmak
• güvenlik ve ağ yapılandırmasını doğru yapmak
• Docker’ı temiz kurulumla hazırlamak

çoğu problemi daha en baştan ortadan kaldırıyor.

Depolama ve Volume Yönetimi

CasaOS kurulumu tamamlandıktan sonra üzerinde özellikle durduğum konulardan biri depoma yapısı ve volume yönetimi oldu. Çünkü Docker tabanlı bir sistemde asıl önemli olan, container’ların çalışması değil; uygulama verilerinin doğru yerde, kalıcı ve kontrollü bir şekilde tutulması. Aksi halde bir container silindiğinde, güncellendiğinde veya yeniden kurulduğunda veri kaybı yaşamak kaçınılmaz hale geliyor.

Bu nedenle ilk aşamada CasaOS’un oluşturduğu dizin yapısını inceleyerek, verilerin hangi path altında tutulduğunu kontrol ettim. Uygulama kurulumlarında mümkün olduğunca container içindeki klasörleri host tarafındaki belirli bir dizine map ederek çalıştırmayı tercih ediyorum. Böylece veriler container’dan bağımsız kalıyor ve gerektiğinde yalnızca uygulamayı yeniden kurup volume’ü aynı dizine bağlayarak sistemi kaypsız şekilde geri yükleyebiliyorum.

Özellikle medya sunucuları, veritabanı içeren servisler ve dosya paylaşım uygulamaları için ayrı klasörler oluşturup dizin yapısını baştan planlamak önemli. Bu sayede hem yönetim daha düzenli oluyor hem de yedekleme ve taşıma süreçlerinde dosya yapısını anlamak çok daha kolaylaşıyor. Benim yaklaşımım; container sayısını artırmadan önce dizin yapısını netleştirmek, daha sonra servisleri bu yapının üzerine inşa etmek yönünde oldu.

Volume tarafında dikkat ettiğim ikinci nokta ise disk türü ve I/O performansı. NVMe depolama, küçük dosya işlemlerinde ve veritabanı tabanlı container’larda belirgin bir avantaj sağlıyor. Öte yandan gereksiz sayıda büyük volume oluşturmak yerine, mantıklı bir klasör hiyerarşisiyle ilerlemek hem performans hem de yönetim açısından daha sağlıklı bir sonuç veriyor.

Kısacası CasaOS üzerinde volume yönetimini, yalnızca bir depolama ayarı değil; sistem sürdürülebilirliği ve veri bütünlüğünün temel parçası olarak görüyorum. Kurulumu hızla tamamlamak yerine, verinin nerede ve nasıl tutulduğunu en baştan doğru planlamak, ileride yapılacak genişleme ve taşıma işlemlerini çok daha sorunsuz hale getiriyor.

Yedekleme / Snapshot Yaklaşımı

CasaOS ve Docker tabanlı bir yapıda, kurulumun çalışıyor olması tek başına yeterli değil; asıl önemli olan, sistemde bir sorun yaşandığında veriyi ve çalışma ortamını ne kadar hızlı geri döndürebildiğiniz. Bu nedenle kurulumu tamamladıktan sonra üzerinde en çok düşündüğüm konulardan biri de yedekleme ve snapshot yaklaşımı oldu.

Ben bu yapıda yedeklemeyi iki katmanlı düşünmeyi tercih ediyorum:

Birinci katman, uygulama verilerinin düzenli yedeklenmesi. Container’lardan bağımsız tutulan volume dizinlerini periyodik olarak harici bir dizine veya ikinci bir depolama alanına kopyalamak, en temel güvenlik ağı olarak görülmeli. Özellikle medya verileri, yapılandırma dosyaları ve veritabanı içeren servisler için bu yaklaşım, sistem tamamen kapanmış olsa bile verinin korunmasını sağlıyor. Bu işlem için rsync tabanlı basit ama güvenilir çözümler çoğu zaman fazlasıyla yeterli oluyor.

İkinci katman ise sistem genelinin snapshot mantığıyla korunması. Sunucu sağlayıcısının sunduğu snapshot veya imaj alma özelliği varsa, belirli periyotlarda sistemin genel durumunu kaydetmek; kritik bir hata, bozulma veya yanlış yapılandırma sonrası geri dönüş süresini ciddi anlamda kısaltıyor. Bu yaklaşım özellikle büyük yapı taşıyan değişikliklerden önce alınan manuel snapshot’larda son derece faydalı.

Yedekleme stratejisinde dikkat ettiğim bir diğer nokta ise, yalnızca yedek almak değil, geri dönüş senaryosunu da düşünmek. Bir yedeğin var olması yeterli değil; gerektiğinde ne şekilde ve ne kadar sürede geri yüklenebileceği de planın bir parçası olmalı. Bu nedenle veriyi nereye kopyaladığımı, hangi dizinlerin kritik olduğunu ve geri yükleme adımlarının nasıl ilerleyeceğini önceden netleştirmeyi tercih ediyorum.

Özetle, CasaOS üzerinde kurulan her servisin arkasında bir yedekleme stratejisi bulunması gerektiğini düşünüyorum. Sistem düzgün çalışırken yedekleme gereksiz gibi görünse de, gerçek ihtiyacın ortaya çıktığı an genellikle en kritik hatanın yaşandığı andır — bu yüzden yedekleme ve snapshot yaklaşımı, benim için kurulum sürecinin “opsiyonel değil, zorunlu” bir parçası.

Appstore mi, Docker Compose mu? (Benim Tercihim)

CasaOS’u kurduktan sonra uygulamaları hangi yöntemle yükleyeceğime karar verirken iki farklı seçenek ön plana çıktı: CasaOS App Store üzerinden tek tıklama kurulumlar ve Docker Compose ile manuel kurulum yaklaşımı. İlk bakışta App Store oldukça pratik görünüyor; hızlı kurulum, hazır şablonlar ve arayüzden yönetim imkânı özellikle başlangıç aşamasında ciddi bir kolaylık sağlıyor. Ancak işin uzun vadeli sürdürülebilirlik tarafına baktığımda, her iki yöntemi de farklı amaçlarla kullanmanın daha doğru bir yaklaşım olduğunu gördüm.

App Store’u daha çok deneme, keşif ve hafif servisler için tercih ediyorum. Yeni bir uygulamayı hızlıca kurup test etmek, arayüz davranışını görmek veya kısa süreli kullanım için bu yöntem oldukça pratik. Ancak versiyon kontrolü, yapılandırma esnekliği ve bağımlılık yönetimi gibi konularda App Store kurulumları zaman zaman sınırlayıcı olabiliyor. Güncelleme sonrası config farklılıkları veya volume yollarında oluşan değişiklikler, bazı projelerde beklenmedik davranışlara yol açabiliyor.

Buna karşılık Docker Compose, özellikle kalıcı çalışacak servislerde benim için daha güvenilir bir seçenek. Compose dosyasında uygulamanın tüm tanımının — ağ yapısı, volume bağları, environment değişkenleri ve port eşleştirmeleri — tek bir yerde ve okunabilir şekilde bulunması; hem yedekleme hem de yeniden kurulum süreçlerini çok daha öngörülebilir hale getiriyor. Gerektiğinde aynı servisi başka bir sunucuya taşımak veya farklı bir ortama kopyalamak Compose ile çok daha kontrollü ilerliyor.

Bu nedenle benim yaklaşımım şu yönde şekillendi:

• Kısa süreli denemeler, keşif amaçlı uygulamalar → App Store
• Uzun süre çalışacak servisler, veri tutan uygulamalar → Docker Compose

CasaOS arayüzünü ise bu noktada bir yönetim katmanı olarak görüyorum; temel operasyonları panelden takip etmek güzel, ancak kritik servislerin bel kemiği benim için hâlâ Compose dosyaları ve terminal tarafında duruyor.

Kısacası tercihimi tek bir yöntem üzerinden değil, uygulamanın kullanım amacına ve kalıcılığına göre yapıyorum. App Store hız kazandırıyor, Compose ise kontrol ve sürdürülebilirlik sağlıyor — benim için bu iki yaklaşım birlikte kullanıldığında gerçek anlamda dengeli bir kurulum modeli ortaya çıkıyor.

CasaOS’yi Sunucu Ortamında Kullanırken Çıkardığım Dersler

CasaOS’yi kiraladığım bir sunucu üzerinde kullanırken, kurulum ve kullanım süreci bana yalnızca bir panel aracı değil, aslında altyapı yaklaşımıyla ilgili bazı önemli dersler de gösterdi. İlk olarak şunu net bir şekilde gördüm: CasaOS, doğru beklentiyle kullanıldığında son derece pratik ve kullanıcı dostu bir araç. Ancak onu bir “tam kapsamlı sunucu yönetim platformu” gibi konumlandırmak yerine, Docker tabanlı servisleri daha düzenli ve erişilebilir hale getiren bir yardımcı katman olarak görmek çok daha sağlıklı.

İkinci olarak, kurulum sürecinin en kritik kısmının CasaOS’un kendisi değil, onun üzerinde çalıştığı Linux, Docker ve depolama altyapısının doğru hazırlanması olduğunu deneyimledim. Güvenlik, volume yapısı, yedekleme ve kaynak planlaması baştan doğru kurgulanmadığında; panel ne kadar iyi olursa olsun sistemin uzun vadede stabil kalması zorlaşıyor. Yani CasaOS, mevcut altyapıyı güçlendiren bir araç — altyapının yerini alan bir çözüm değil.

Son olarak, App Store ve Docker Compose yaklaşımını birlikte kullanmanın, hem esneklik hem de sürdürülebilirlik açısından en dengeli model olduğunu düşünüyorum. Hızlı kurulum kolaylığı App Store tarafında, kontrol ve dokümantasyon ise Compose tarafında duruyor. Bu denge sayesinde sistem hem deneme yapmaya açık kalıyor hem de kalıcı servisler için sağlam bir temel korunmuş oluyor.

Kısacası CasaOS’yi sunucu ortamında kullanırken çıkardığım en önemli ders, araçtan ziyade yaklaşımın belirleyici olduğu. Doğru yapılandırılmış bir altyapı üzerinde, bilinçli tercihlerle kullanıldığında CasaOS; self-host ortamını daha düzenli, takip edilebilir ve yönetilebilir hale getiren değerli bir araç haline geliyor.

Sıkça Sorulan Sorular