NixOS Nedir? Tekrarlanabilir Ortam ve Karar Rehberi

NixOS nedir sorusunun en net cevabı; tüm işletim sistemi yapılandırmasının, kurulu paketlerin ve sistem servislerinin tek bir merkezden, bildirime dayalı (declarative) olarak yönetildiği, tam izole bir Linux dağıtımı olmasıdır. Geliştirici ortamlarında “benim bilgisayarımda çalışıyordu” problemini kökten çözen bu yapı, sistem durumunu şansa bırakmaz. Her paket ve bağımlılık kriptografik hash’ler ile izole edilerek tam tutarlılık sağlanır.

Hollanda hükümetinin Microsoft ekosistemine alternatif olarak NixOS tabanlı bir altyapı inşa etmeye başlaması, tekrarlanabilir ve izole ortam arayan mühendislerin ilgisini artırmıştır. Kurumsal düzeyde dijital egemenlik arayışı, işletim sistemi seviyesinde deterministik yaklaşımları zorunlu kılmaktadır. Altyapıyı kod olarak yönetirken Monolitik Terraform State Bölme: IaC Plan Süresini 25 Dakikadan 45 Saniyeye Düşürmek başlıklı yazıda incelediğimiz state izolasyonu kavramı, NixOS ile doğrudan işletim sistemi çekirdeğine inmektedir.

30 Mayıs 2026 tarihinde yayınlanan NixOS 26.05 “Yarara” sürümü ile birlikte sistem yönetimi pratikleri büyük ölçüde değişmiştir. İşletim sistemi önyükleme sürecinde varsayılan olarak systemd Stage 1 yapısına geçilmiş, çekirdek derleyici tarafında GCC 15 desteği getirilmiştir. Aşağıda, NixOS’un teknik mimarisi, kullanım senaryoları ve üretim ortamına (production) geçiş kararı alırken dikkat edilmesi gereken metrikler incelenmektedir.

İçindekiler

• NixOS Nedir ve Geleneksel Linux Dağıtımlarından Farkı
• Yeni Nesil Yaklaşım: Nix Flakes ve Tekrarlanabilir Derlemeler
• NixOS Ne Zaman Kullanılır? Karar Matrisi
• Ne Zaman Kullanılmamalı ve Alternatifleri
• Jeopolitik Bir Vaka: Hollanda Hükümeti Neden NixOS’a Geçiyor?
• Pratik NixOS Yapılandırma ve Kod Örnekleri
• NixOS Uygulama Kontrol Listesi
• Sık Sorulan Sorular
• Değerlendirme

NixOS Nedir ve Geleneksel Linux Dağıtımlarından Farkı

Ubuntu, Debian veya CentOS gibi geleneksel Linux dağıtımları, FHS (Filesystem Hierarchy Standard) adı verilen standart bir dosya sistemi hiyerarşisi kullanır. Bu sistemlerde çalıştırılabilir dosyalar /bin, kütüphaneler /usr/lib veya /lib altında toplanır. Bir paketi güncellediğinizde, sistemdeki o kütüphaneyi kullanan diğer tüm uygulamalar bu değişiklikten etkilenir.

NixOS, FHS uyumunu tamamen reddeder. Sistemde geleneksel /bin veya /usr/lib dizinleri bulunmaz. Bunun yerine her paket, bağımlılıkları ve derleme talimatlarıyla birlikte hesaplanan benzersiz bir kriptografik hash ile /nix/store dizini altında tutulur. Böylece OpenSSL’in iki farklı versiyonu sistemde birbirini ezmeden, tamamen izole dizinlerde yan yana barınabilir. Bu mimari, bağımlılık çakışmalarını (dependency hell) matematiksel olarak imkansız hale getirir.

Paket deposu tarafında NixOS Paket Arama Motoru (Nixpkgs), anlık olarak 140.000’den fazla paket barındırmaktadır. Dünyanın en geniş paket depolarından biri olan Nixpkgs, devasa bir açık kaynak topluluğu tarafından desteklenmektedir. Sadece geçmişteki 22.05 sürümü bile 1611 farklı katılımcının 46.727 commit’i ile inşa edilmiştir.

Yeni Nesil Yaklaşım: Nix Flakes ve Tekrarlanabilir Derlemeler

NixOS ekosisteminde yapılandırma yönetimi ciddi bir evrim geçirmiştir. Geleneksel paket yönetim komutu olan nix-env ve kanal tabanlı nix-channel yapısı büyük ölçüde kullanımdan kalkmıştır. Bu eski araçların yerini, bağımlılıkları tam olarak kilitleyen (lock file mantığı ile) Nix Flakes mimarisi ve nix profile komutları almıştır.

Flakes mimarisi, tekrarlanabilir derlemeler (reproducible builds) konseptini en üst seviyeye taşır. Bir projenin bağımlılıkları belirli bir Git commit hash’ine kilitlenir. Böylece kodu beş yıl sonra başka bir makinede derlediğinizde, derleyici sürümünden kütüphane versiyonlarına kadar her şey bayt bazında aynı kalır. Haziran 2026 itibarıyla yayınlanan Nix package manager 2.35.2 sürümüyle yapılan optimizasyonlar, tam NixOS konfigürasyonlarının değerlendirilmesi gibi iş yüklerinde %5 ila %12 arasında zaman tasarrufu (wall-clock improvement) sağlamıştır.

Geçici geliştirme ortamları kurmak Flakes ile daha güvenlidir. Sisteme kalıcı olarak paket kurmadan izole bir ortam yaratmak için nix shell nixpkgs#paket_adi veya tam bir geliştirme araç zincirini yüklemek için nix develop komutu kullanılır. Bu yaklaşım, CI/CD süreçlerindeki tutarsızlıkları giderir. Büyük ölçekli dağıtımlarda ArgoCD Reconciliation Gecikmesini 12 Dakikadan 4 Saniyeye Düşürmek başlıklı vaka çalışmasında bahsettiğimiz GitOps prensipleri, Nix Flakes ile birleştiğinde altyapı yönetiminde tam otomasyon sağlar.

NixOS Ne Zaman Kullanılır? Karar Matrisi

NixOS her proje için uygun bir çözüm değildir. Doğru aracı seçmek için ekibinizin yetkinliklerini ve projenin gereksinimlerini analiz etmeniz gerekir. Aşağıdaki karar matrisi, hangi durumlarda hangi işletim sistemi veya aracın seçilmesi gerektiğini özetlemektedir.

Kriter / Gereksinim	NixOS	Ubuntu / Debian (Ansible ile)	Docker / Konteyner
%100 Tekrarlanabilirlik	Evet (İşletim sistemi seviyesinde)	Kısmen (State kaymaları yaşanabilir)	Evet (Uygulama seviyesinde)
Geri Alma (Rollback) Hızı	Anında (Boot menüsünden)	Yavaş (Manuel müdahale gerektirir)	Hızlı (Eski imajı başlatarak)
Öğrenme Eğrisi	Çok Dik (Nix dili gerektirir)	Düşük (Standart Linux bilgisi)	Orta (Dockerfile ve YAML)
FHS Uyumluluğu	Yok (Geçici çözümler gerekir)	Tam Uyumlu	Tam Uyumlu (İmaj bazlı)

Eğer-İse Karar Özeti:

• Eğer ekibinizde Nix dilini bilen mühendisler varsa ve yüzlerce sunucunun birebir aynı konfigürasyonda çalışması kritikse -> NixOS kullanın.
• Eğer sistemde çok hızlı, standart dışı (ad-hoc) SSH müdahaleleri yapılması gerekiyorsa ve ekip standart Linux komutlarına alışıksa -> Ubuntu veya Debian kullanın.
• Eğer sadece uygulamanızı izole etmek istiyor ancak altındaki işletim sisteminin durumuyla ilgilenmiyorsanız -> Docker veya Kubernetes kullanın.

Ne Zaman Kullanılmamalı ve Alternatifleri

NixOS’un en büyük tuzağı dik öğrenme eğrisidir. Konfigürasyon için kullanılan Nix Expression Language, fonksiyonel bir programlama dilidir. Bash, Python veya YAML bilmek NixOS’u yönetmek için yeterli değildir. Dilin temellerini ve tembel değerlendirme (lazy evaluation) mantığını öğrenmek ciddi bir zaman yatırımı gerektirir.

FHS uyumunun olmaması, dışarıdan indirilen derlenmiş (pre-compiled) binary dosyaların veya kapalı kaynaklı yazılımların doğrudan çalışmamasına neden olur. Standart /bin/bash yolunu arayan basit bir bash scripti bile NixOS üzerinde hata verecektir. Bu tür durumlarda patchelf veya buildFHSUserEnv gibi geçici çözümler (workaround) uygulamak zorunludur. Ayrıca gelecekteki sürümlerde x86_64-darwin desteğinin sonlandırılacağı duyurulduğu için Apple ekosistemindeki eski Intel cihazlarda kullanım planı gözden geçirilmelidir.

Her paket güncellemesi ve konfigürasyon değişikliği sistemde yeni bir jenerasyon yaratır. Düzenli olarak çöp toplama (garbage collection) işlemi yapılmazsa, /nix/store dizini sunucunun diskini çok kısa sürede dolduracaktır. Projede sadece çalışması hedeflenen basit, tek seferlik bir web sunucusu kurulacaksa NixOS kullanmak aşırı mühendislik (over-engineering) olacaktır. Pulumi Automation API ile PR Bazlı İzole Test Altyapıları kurarken olduğu gibi pragmatik ve hızlı çözümler arıyorsanız, geleneksel dağıtımlar daha hızlı sonuç verir.

Jeopolitik Bir Vaka: Hollanda Hükümeti Neden NixOS’a Geçiyor?

Teknolojik kararlar sadece performans metrikleriyle alınmaz. Hollanda hükümetinin DAWO (Digitaal Autonome Werkomgeving Overheid – Dijital Otonom Hükümet Çalışma Ortamı) projesi bunun en güncel örneğidir. 2025’in başlarında ABD’nin Uluslararası Ceza Mahkemesi’ne (ICC) uyguladığı yaptırımlar sonucu Microsoft hizmetlerinin kesintiye uğraması, Avrupa’da dijital egemenlik tartışmalarını alevlendirmiştir.

Bu kesintilerin ardından Hollanda hükümeti, dışa bağımlılığı bitirmek adına Windows’u terk edip NixOS tabanlı bir işletim sistemine geçiş yapma kararı almıştır. Projenin ilk kararlı sürümünün 2027 sonunda çıkması hedeflenmektedir. Bu stratejik hamle, NixOS’un sadece niş bir geliştirici aracı olmadığını, aynı zamanda ulusal güvenlik seviyesinde kurumsal ölçeklenebilirliğe sahip olduğunu kanıtlamaktadır.

NixOS’un seçilmesinin temel nedeni, işletim sisteminin her bir bileşeninin kaynak koddan itibaren denetlenebilir ve tekrarlanabilir olmasıdır. Geleneksel sistemlerde zamanla oluşan yapılandırma kayması (configuration drift), NixOS’un salt okunur (read-only) dosya sistemi mimarisi sayesinde engellenmektedir.

Pratik NixOS Yapılandırma ve Kod Örnekleri

NixOS üzerinde sistem yapılandırması /etc/nixos/configuration.nix adlı ana dosya üzerinden yürütülür. İşletim sistemi kurulurken nixos-generate-config aracı donanımı tarar ve hardware-configuration.nix dosyasını otomatik oluşturur. Bu dosya, imports = [ ./hardware-configuration.nix ]; dizilimiyle ana konfigürasyona dahil edilir.

Aşağıda, 26.05 “Yarara” sürümü standartlarına uygun bir yapılandırma örneği bulunmaktadır:

# /etc/nixos/configuration.nix
{
  description = "Prod Web Sunucusu Konfigürasyonu";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-26.05";
  };

  outputs = { self, nixpkgs }: {
    nixosConfigurations.webserver = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        ./hardware-configuration.nix
        ({
          # 26.05 ile gelen systemd Stage 1 varsayılanı
          boot.initrd.systemd.enable = true;

          # Ağ yapılandırması - Global DHCP kullanımdan kalkıyor
          networking.hostName = "prod-web-01";
          networking.useDHCP = false;
          networking.interfaces.eth0.useDHCP = true;

          # Disk tasarrufu için optimizasyonu manuel açıyoruz
          nix.optimise.automatic = true;

          # Sistem paketleri
          environment.systemPackages = with nixpkgs; [
            git
            neovim
            htop
          ];

          # SSH Servisi
          services.openssh.enable = true;

          system.stateVersion = "26.05";
        })
      ];
    };
  };
}

Yapılandırma dosyasında yapılan değişikliklerin sisteme uygulanması için Flakes mimarisinde aşağıdaki komut çalıştırılır:

sudo nixos-rebuild switch --flake .#webserver

Eski sürümlerde kullanılan --no-build-nix bayrağı artık tamamen kullanımdan kaldırılmıştır. Sistem güncellemelerinden sonra bir sorun yaşarsanız, sistemi bir önceki çalışan duruma döndürmek (rollback) son derece basittir:

sudo nixos-rebuild switch --rollback

Kullanıcıya özel dotfiles ve paketlerin yönetimi için ise sistem konfigürasyonuna ek olarak topluluk standardı haline gelen home-manager aracı kullanılır. Disk alanını korumak için eski jenerasyonların temizliği şu komutla yapılır:

sudo nix-collect-garbage -d

NixOS Uygulama Kontrol Listesi

NixOS’u üretim ortamına almadan önce aşağıdaki adımları doğruladığınızdan emin olun:

• Donanım Taraması: nixos-generate-config komutu ile hardware-configuration.nix dosyasının eksiksiz oluşturulduğunu teyit edin.
• Flakes Aktivasyonu: Eski kanal yapısı yerine konfigürasyonunuzun tamamen flake.nix üzerinden yönetildiğinden emin olun.
• Çöp Toplama Otomasyonu: nix-collect-garbage -d komutunu haftalık çalışacak bir cron job veya systemd timer olarak ayarlayın.
• Optimizasyon Ayarı: Varsayılan olarak kapalı gelen nix.optimise.automatic = true; ayarını aktif ederek disk tüketimini minimize edin.
• Ağ Yapılandırması: Global networking.useDHCP = false; yaparak, sadece ilgili ağ arayüzleri için DHCP’yi manuel aktifleştirin.
• Sürüm Takibi: NixOS 26.05 Sürüm Notları sayfasını inceleyerek 31 Aralık 2026’daki EOL tarihine kadar güncelleme planınızı oluşturun.

Sık Sorulan Sorular

NixOS nedir ve Ubuntu, Debian gibi geleneksel Linux dağıtımlarından teknik olarak farkı nedir?

NixOS, FHS (Filesystem Hierarchy Standard) kullanmayan, tüm paketleri kriptografik hash’ler ile /nix/store altında izole eden bir dağıtımdır. Ubuntu ve Debian’da paketler ortak dizinleri (örn. /usr/lib) paylaşırken, NixOS’ta her paket kendi bağımlılıklarıyla tam izole yaşar, bu da bağımlılık çakışmalarını önler.

NixOS Flakes nedir, neden geleneksel nix-channel yönteminin yerini almaktadır?

NixOS Flakes, projenin tüm bağımlılıklarını belirli bir Git commit’ine kilitleyerek (lock file) %100 tekrarlanabilir derlemeler sağlayan yeni nesil mimaridir. Geleneksel nix-channel yapısı durum bilgisi (state) tuttuğu için farklı makinelerde farklı sonuçlar üretebiliyordu; Flakes bu tutarsızlığı tamamen ortadan kaldırır.

NixOS sistemi güncellemelerden sonra çökerse eski sürüme veri kaybı olmadan nasıl dönülür?

NixOS’ta her konfigürasyon değişikliği yeni bir jenerasyon yaratır. Sistem çökerse bilgisayarı yeniden başlatıp boot menüsünden bir önceki çalışan jenerasyonu seçebilir veya terminalden sudo nixos-rebuild switch --rollback komutunu çalıştırarak sistemi saniyeler içinde eski haline döndürebilirsiniz.

NixOS üzerinde Docker kullanmaya gerek var mı?

NixOS’un kendi izolasyon mekanizması tekrarlanabilir ortamlar sunsa da, Docker kullanmak hala geçerlidir. Özellikle ekibinizdeki diğer geliştiriciler macOS veya Windows kullanıyorsa, uygulamanızı standart bir OCI imajı olarak paketlemek ve dağıtmak için Docker veya Podman entegrasyonu NixOS üzerinde sorunsuz çalışır.

NixOS günlük masaüstü kullanımı ve oyun oynamak için uygun mudur?

Evet, NixOS 26.05 sürümüyle birlikte GNOME 50 “Tokyo” gibi güncel masaüstü ortamlarını tam destekler. Ancak FHS uyumu olmaması nedeniyle, Steam dışındaki kapalı kaynaklı oyunları veya bağımsız binary dosyalarını çalıştırmak için patchelf gibi ek yapılandırmalar gerektirdiğinden son kullanıcı için zahmetli olabilir.

Değerlendirme

NixOS, işletim sistemi yönetimine getirdiği deterministik ve bildirime dayalı yaklaşımla sistem yöneticileri için farklı bir güvenilirlik sunar. 26.05 “Yarara” sürümüyle birlikte systemd Stage 1 entegrasyonu ve GCC 15 desteği gibi yenilikler, platformun olgunluğunu kanıtlamaktadır. Hollanda hükümetinin DAWO projesi gibi devasa ölçekli geçişler, bu mimarinin pratik ve stratejik bir değer taşıdığını da göstermektedir.

Öğrenme eğrisi dik olsa da, yüzlerce sunucuyu yönetirken bağımlılık çakışmalarından ve yapılandırma kaymalarından kurtulmak isteyen ekipler için NixOS uygun bir araçtır. Geçiş sürecine başlamak için mevcut bir projenizin geliştirme ortamını nix develop ile izole ederek ilk adımı atabilir, tekrarlanabilir derlemelerin konforunu yerel makinenizde test edebilirsiniz.