AI ile yönetilen sunucu: Claude Code ve ChatGPT gibi AI ajanlarını kendi sunucunuza güvenle bağlama

Yakın zamana kadar “sunucu yönetmek” şu anlama geliyordu: SSH oturumu açmak, logları okumak, komut yazmak, dokümantasyonda arama yapmak, yeniden yazmak. Claude Code, OpenAI Codex ve Gemini CLI komut satırı araçları olarak kullanıma sunulduğundan beri tam da bu işi bir AI ajanı üstlenebiliyor: Hata mesajını okuyor, nedenini araştırıyor, yapılandırmayı değiştiriyor, servisi yeniden başlatıyor ve ne yaptığını açıklıyor. Buna artık AI ile yönetilen sunucu (AI managed server) deniyor. Bu yazı, bunun arkasında ne olduğunu, hangi mimarilerin kendini kanıtladığını, hangi güvenlik kurallarının tartışmaya kapalı olduğunu ve her KernelHost root sunucusunun buna neden hiçbir uyarlama gerektirmeden uygun olduğunu açıklıyor.

AI ile yönetilen sunucu nedir (ve ne değildir)

AI ile yönetilen sunucu yeni bir ürün ya da özel bir donanım değildir. Bir AI ajanının kendi kullanıcı hesabı altında komut çalıştırmasına izin verilen sıradan bir root sunucudur. İnsan görevi gündelik dille tarif eder (“nginx neden bu sabahtan beri 502 ile yanıt veriyor?”), ajan sistemi inceler, değişiklik önerir, onaydan sonra bunları uygular ve sonucu belgeler.

Komutlarını elle kopyaladığınız bir sohbet botundan farkı şu: Ajanın bir kabuğu var. journalctl komutunu kendisi çağırabilir, yapılandırma dosyalarını okuyabilir, bir komutu deneyebilir, çıktıyı yorumlayabilir ve bir sonraki adımı buradan çıkarabilir. Kopyala-yapıştırla geçen yarım saatlik gidip gelme iki dakikaya iner.

AI ile yönetilen sunucu ne değildir: kendi kendini yöneten bir sunucu. Ajanlar talep üzerine, bir oturum bağlamında ve onaylarla çalışır. Onlara tam serbestlik verirseniz otonom bir yönetici değil, freni olmayan çok hızlı bir araç elde edersiniz. Aşağıdaki kurallar frenin yerinde kalmasını sağlar.

AI ile yönetilen sunucu ve klasik yönetilen sunucu karşılaştırması

Klasik yönetilen sunucuda bakımı aylık sabit bir ücret karşılığında hosting firması ya da bir hizmet sağlayıcı üstlenir. AI ile yönetilen sunucuda ise kontrol sizde kalır ve elle yapılan işleri bir ajana bırakırsınız.

Araçlar: Claude Code, ChatGPT Codex, Gemini CLI ve MCP

Üç büyük sağlayıcının hepsi artık Linux sunucularda çalışan, dosya okuyup yazan ve kabuk komutları çalıştıran bir komut satırı aracı sunuyor. Ayrıntılarda farklılar, temel ilke ise aynı.

Üçü de Node.js ile çalışır, GPU gerektirmez ve asıl düşünme işini sağlayıcının modeline gönderir. Sunucuda yalnızca birkaç megabaytlık aracın kendisi kalır. Bu yüzden en küçük KVM root sunucu bile yeterlidir.

MCP ek olarak ne sağlar

Buna bir de Model Context Protocol (MCP) eklenir: bir ajanın, kabuğu kullanmak zorunda kalmadan ek araçlar edinmesini sağlayan açık bir arayüz; örneğin bir veritabanına, bir izleme sistemine, bir destek talebi sistemine veya bir Docker ortamına erişim. Başlangıç için MCP gerekli değildir. Erişimleri hedefli olarak kısıtlamak istediğiniz anda ilginç hâle gelir: Yalnızca okuma amaçlı veritabanı sorgularına izin veren bir MCP sunucusu, veritabanı parolası kabukta duran bir ajandan daha güvenlidir.

Size hangi araç uygun?

Sunucu yönetimi açısından üç araç eşdeğerdir: Hepsi kural dosyalarını okur, müdahale eden komutlardan önce sorar ve gözetimsiz olarak başlatılabilir. Bu nedenle karar çoğu zaman zaten sahip olduğunuz hesaba bağlıdır. ChatGPT kullananlar Codex CLI ile, Claude aboneliği olanlar Claude Code ile, Google ekosisteminde çalışanlar Gemini CLI ile başlar. Birden fazla aracı yan yana çalıştırmak sorunsuz mümkündür, çünkü her biri kendi kural dosyasını okur.

Ajanı sunucuya bağlamanın üç yolu

1. Ajan kendi bilgisayarınızda çalışır ve SSH üzerinden iş yapar

Claude Code veya Codex dizüstü bilgisayarda çalışır ve her sunucu komutu ssh üzerinden gönderilir. Avantajı: Sunucuya hiçbir şey kurulması gerekmez, ajan aynı anda birden fazla sunucuyla ilgilenebilir ve AI sağlayıcısındaki oturumunuz kendi cihazınızda kalır. Dezavantajı: Ajan sunucuyu yalnızca tek tek komutların anahtar deliğinden görür ve uzun oturumlar sizin bağlantınıza bağlıdır. Ara sıra yapılan bakım ve birkaç küçük sunucu için en basit seçenek budur. Bizim de ayrı bir anahtar, bir host takma adı ve deploy işlemleri için sabit bir akışla bu şekilde nasıl çalıştığımızı Yapay zekâyı sunucuya bağlama başlıklı deneyim raporu gösteriyor.

2. Ajan doğrudan sunucuda çalışır

Araç sunucuya kurulur ve SSH üzerinden başlatılır. Ajan bu durumda dosyalara doğrudan erişerek çalışır, logları gerçek zamanlı takip edebilir ve daha uzun görevleri de sizin bağlantınız olmadan tamamlayabilir; örneğin her sabah logları özetleyen bir cron görevi kapsamında. AI ile yönetilen sunucudan söz edildiğinde pratikte en sık kastedilen seçenek budur. Bunun adım adım nasıl yapıldığı Claude Code ve Codex'i sunucuya kurma rehberinde anlatılıyor.

3. Ajan bir bastion sanal makinesinde çalışır

Birden fazla üretim sistemi için, ajanların üzerinde yaşadığı ve hedef sistemlere oradan SSH ile eriştiği küçük, ayrı bir sunucu kurmaya değer. Hedef sistemler yalnızca yetkileri kısıtlanmış bir SSH anahtarı alır; bastion sunucusu ise AI sağlayıcılarındaki oturumları, oturum kayıtlarını ve kuralları barındırır. Bu ilkeyi veri merkezi işletiminden bilenler hemen tanıyacaktır: önünde insan yerine bir ajanın oturduğu bir jump server. Bunun için 2 vCPU'lu bir KVM root sunucu yeterlidir.

Üç yolun karşılaştırması

Tartışmaya kapalı güvenlik kuralları

Kabuk erişimi olan bir ajan, root parolasını almış ama işe alıştırılmamış yeni bir iş arkadaşı kadar tehlikelidir. Bu kurallar her gün saldırıya uğrayan sunucuların işletiminden geliyor ve sağlayıcıdan bağımsız olarak geçerlidir:

• Ayrı kullanıcı, asla root. Ajan kendine ait bir hesap alır. Root komutları, tam olarak ihtiyaç duyduğu komutları içeren bir sudo beyaz listesi üzerinden çalışır: paket güncellemeleri, servis yeniden başlatmaları, log erişimi. Geri kalan her şey kapalı kalır.
• Onay modunu açık bırakın. Üç araç da müdahale eden işlemlerden önce sorar. --dangerously-skip-permissions veya danger-full-access gibi seçeneklerin yeri tek kullanımlık bir sanal makinedir, asla bir üretim sistemi değil.
• Her oturumdan önce yedek veya anlık görüntü. Bir yapılandırmayı “onaran” bir ajan onu bozabilir de. Anlık görüntü veya test edilmiş bir yedek varsa bu can sıkıcı bir durumdur, yoksa acil bir durumdur.
• Promptta sır yok. Parolalar, API anahtarları ve müşteri verileri göreve yazılmaz. Ajanın dosyalarda okuduğu her şey sağlayıcıya gider; bu nedenle sır içeren dosyalar onun erişiminin dışında tutulur ya da önceden maskelenir.
• Önce staging, sonra üretim. Yeni görev kalıpları bir test sanal makinesinde denenir. Akış ancak birkaç kez sorunsuz çalıştıktan sonra üretim sistemine alınabilir.
• Değişiklikleri izlenebilir tutun. /etc dizinini Git'te tutun (etckeeper), oturum kayıtlarını saklayın ve her değişikliği ajana özetletin. İzlenemeyen şey geri de alınamaz.
• Maliyet sınırları koyun. API anahtarlarına sağlayıcı tarafında aylık bir bütçe tanımlanır. Aksi hâlde sonsuz döngüye giren bir ajan her sunucudan daha pahalıya gelir.
• Ağı minimumda tutun. Ajanın yalnızca sağlayıcıya giden HTTPS bağlantısına ihtiyacı vardır. Gelen trafik tarafında hiçbir şey değişmez, sunucu güvenlik duvarı ve DDoS korumasının arkasında kalır.

Ayrı bir kullanıcı neden bu kadar önemli

Dil modelleri hata yapar ve bunu büyük bir özgüvenle yapar. Bir yolu karıştıran ajan, root yetkileriyle yanlış dizini siler; ayrı bir kullanıcıyla ise aynı komut yetki eksikliği yüzünden başarısız olur. Bu nedenle asıl güvenlik sınırı modelin temkini değil, sudo beyaz listesidir. Buna pratik bir avantaj da eklenir: Loglarda hangi işlemin ajandan, hangisinin bir insandan geldiği her zaman görülebilir. Böyle bir kullanıcının nasıl oluşturulduğunu Linux'ta sudo kullanıcısı oluşturma yazısı gösteriyor.

AI sağlayıcısı neleri görür

Ajan okuduğu her şeyi işlenmek üzere sağlayıcının dil modeline gönderir: log satırları, yapılandırma dosyaları, komut çıktıları. Sunucudaki araç yalnızca bir ulaktır. Buradan iki kural çıkar. Birincisi, erişim bilgileri içeren dosyalar ajanın görüş alanına girmemelidir; betikler bu dosyaları, ajan içeriklerini görüntülemeden yine de kullanabilir. İkincisi, müşterilere ait kişisel veriler görevlere girmemelidir. Müşteri verileri üzerinden analiz yapmanız gerekiyorsa ajana yalnızca sayılar veya anonimleştirilmiş sonuçlar döndüren bir sorgu yazdırın ve bu sorguyu kendiniz çalıştırın.

Ajanın iyi yaptığı işler ve kendiniz yazmanızın daha iyi olduğu yerler

Pratik deneyim şunu gösteriyor: Ajanlar çok okuma ve az risk içeren görevlerde parlar. Son 24 saatin loglarını özetlemek, bir hata mesajının nedenini bulmak, bir nginx yapılandırmasını hatalara karşı kontrol etmek, bir systemd unit dosyası yazmak, Docker Compose dosyalarını uyarlamak, log rotasyonu dâhil bir yedekleme betiği oluşturmak, bir güvenlik duvarı kuralını açıklamak. Akışı net olan rutin bakım da iyi çalışır; örneğin güncellemeleri kurmak, ardından servisleri kontrol etmek ve bir rapor yazmak.

Başlangıç için iyi görevler

• “Son 24 saatteki hataları ve uyarıları servislere göre gruplayarak özetle.”
• “Hangi servisler başarısız oldu ve her birinde son hata mesajı ne diyor?”
• “Hangi paketlerin bekleyen güvenlik güncellemesi var?”
• “nginx yapılandırmasını kontrol et ve nginx -t komutunun verdiği her uyarıyı açıkla.”
• “Hangi dizinler en çok yer kaplıyor ve bunlardan neler güvenle silinebilir?”

İnsanda kalan görevler

Geri döndürülemez sonuçları olan ve tanımı belirsiz görevler daha az uygundur: veritabanlarını taşımak, disk bölümlerini değiştirmek, kullanıcıları silmek, üretim verilerini temizlemek. Burada ajan planı yazan iyi bir danışmandır, ama uygulayan insandır. Bir de şu var: Bir çıktıyı anlamayan ajan tahmin yürütür. Çıktıyı kendiniz değerlendiremiyorsanız onu onaylamamalısınız.

Gündelik kullanımda tipik akışlar

Günlük log raporu

Gözetimsiz görevlerin klasiği: Bir cron görevi, ajanı her sabah örneğin “Son 24 saatteki hataları ve uyarıları özetle” gibi sabit bir görevle başlatır ve sonucu e-postayla gönderir. Ajanın bu sırada yalnızca okumasına izin verilir, araçları journalctl ile sınırlıdır. Cron görevinin tam olarak nasıl göründüğü kurulum rehberinde yer alıyor.

Raporlu güncellemeler

Güvenlik güncellemelerinde ajan önce hangi paketlerin etkilendiğini ve ardından hangi servislerin yeniden başlatılması gerektiğini kontrol eder. Onayınızdan sonra güncellemeleri kurar, servisleri yeniden başlatır, durumlarını kontrol eder ve kısa bir rapor yazar. Güncellemeleri genel olarak otomatikleştirmek istiyorsanız bunu unattended-upgrades ile birleştirin ve ajana yalnızca kontrol işini bırakın.

Arıza anında sorun giderme

Bir arıza anında belirtiyi tarif edersiniz, örneğin “Web sitesi 502 ile yanıt veriyor”. Ajan web sunucusunun ve uygulamanın loglarını okur, backend servisinin çalışıp çalışmadığını kontrol eder, bir hipotez kurar ve bunu log satırlarıyla kanıtlar. Çözümü önerir; çözüm ancak sizin onayınızdan sonra uygulanır. Tipik nedenleri ve bunların nasıl giderileceğini nginx 502 Bad Gateway hatasını giderme yazısı anlatıyor.

KernelHost sunucularıyla tam uyumlu

Her KernelHost sunucusu, AI araçlarının tüm gereksinimlerini özel bir yapılandırma gerektirmeden baştan karşılar:

• Tam root erişimi KVM root sunucularda ve dedicated sunucularda sunulur; böylece kullanıcıları, sudo kurallarını ve Node.js'i kendiniz kurabilirsiniz.
• Serbest işletim sistemi seçimi: Debian, Ubuntu, AlmaLinux, Rocky Linux ve Claude Code, Codex CLI ile Gemini CLI'nin resmî olarak çalıştığı diğer dağıtımlar. Windows sunucularda araçlar yerel olarak veya WSL üzerinden çalışır.
• Giden bağlantılar serbest: Ajanlar HTTPS üzerinden api.anthropic.com, api.openai.com ve Google API'leriyle iletişim kurar. DDoS koruması yalnızca gelen saldırı trafiğini filtreler ve ajanları yavaşlatmaz.
• Sınırsız trafik: API istekleri küçüktür, ama log analiz eden bir ajan ay boyunca yine de veri trafiği oluşturur. KernelHost'ta bunun bir önemi yoktur.
• Node.js paket kaynaklarından veya NodeSource'tan, Debian'da Node.js rehberinde anlatıldığı gibi kurulabilir.
• Frankfurt lokasyonu: sağlayıcıların Avrupa'daki API uç noktalarına kısa yollar ve verilerin Almanya'daki veri merkezinde saklanması.

Kısacası: KernelHost'ta ayrıca sipariş etmeniz veya etkinleştirmeniz gereken hiçbir şey yok. Bir root sunucu, bir kullanıcı, bir araç, hepsi bu.

KernelHost API: ajan için sunucuları otomatik olarak devreye alma

Bir ajan yalnızca bir sunucu üzerinde çalışmakla kalmaz, KernelHost API üzerinden sunucuları devreye alıp yönetebilir de: ürünleri sorgulamak, sunucu sipariş etmek, durumu okumak, sunucuları başlatmak, durdurmak ve yeniden başlatmak, ayrıca iptal talepleri oluşturmak ve geri almak. Böylece “Güncelleme için bana bir test sunucusu kur” isteği, ajanın siparişten kurulumun tamamlanmasına kadar üstlendiği tek bir görev hâline gelir. API anahtarları gerekli yetkilerle sınırlandırılabilir, ajan bir isteği tekrarladığında bir Idempotency-Key mükerrer siparişleri önler ve erişim bilgilerinin her sorgulanışı bir e-posta bildirimi tetikler. Faturalandırma asgari süre olmadan PrePaid olarak yapılır; yani birkaç günlük bir test sunucusu sizi hiçbir şeye bağlamaz.

Maliyetler: abonelik mi, API mi

İşletim için iki tür maliyet söz konusudur: sunucu ve dil modeli. Sunucu, zaten çalışan sıradan bir root sunucudur. Model için iki yol vardır. Bir abonelik (Claude Pro veya Max, ChatGPT Plus veya Pro) ilgili komut satırı aracının kullanımını belirli bir kota dâhilinde kapsar ve günlük kullanımda çoğunlukla daha ucuzdur. Bir API anahtarı token başına ücretlendirilir, abonelik gerektirmez ve bir bütçeyle sınırlandırılabilir; ara sıra yapılan bakımda maliyet çoğu zaman ayda birkaç euroda kalır. Günlük log raporu gibi başında kimsenin olmadığı otomatik görevler için API anahtarı temiz yoldur, çünkü abonelik oturumu bir cihaza ve bir kişiye bağlıdır.

Başlangıçta sık yapılan hatalar

• Ajan root olarak çalışıyor. İlk gün rahat, ikinci günden itibaren tehlikeli. Çözüm: sudo beyaz listesine sahip ayrı bir kullanıcı.
• Tüm onay soruları kapatılmış. Çözüm: yalnızca okuma komutlarının sorulmadan çalışmasına izin vermek, müdahale eden her şeyi onaylamak.
• Kural dosyası yok. CLAUDE.md, AGENTS.md veya GEMINI.md olmadan ajan ne servislerinizi ne de sınırlarınızı bilir. Çözüm: kuralları yazıya dökmek ve her düzeltmede bunlara ekleme yapmak.
• Oturumdan önce yedek yok. Çözüm: ajan bir şeyi değiştirmeden önce, yedekleme stratejisi yazısında anlatıldığı gibi bir anlık görüntü veya test edilmiş bir yedek.
• Görev metninde sırlar. Çözüm: erişim bilgilerini yalnızca ajanın görüntülemesi gerekmeyen dosyalarda tutmak ve bir dikkatsizlik olursa hemen yeniden oluşturmak.
• Sonuçlar kontrol edilmeden benimsenmiş. Çözüm: bir tahmini destekleyen log satırı gibi kanıtlar istemek ve sonucu canlıda kontrol ettirmek.

Sonraki adım

Denemek isterseniz: Debian veya Ubuntu kurulu bir KVM root sunucu, temel sertleştirme için yeni root sunucular için kontrol listesi ve ardından Claude Code ve Codex CLI için adım adım rehber. Bir saat sonra sunucunuz kendi logları hakkındaki soruları yanıtlıyor olur.

SSH bağlantısından üretim sistemine deploy işlemine kadar bunun gündelik işte nasıl göründüğünü Yapay zekâyı sunucuya bağlama: AI ajanıyla deploy ve sunucu yönetimi başlıklı deneyim raporumuz gösteriyor.

Kısaca özetle

• AI ile yönetilen sunucu, Claude Code, Codex CLI veya Gemini CLI gibi bir AI ajanının kendi kullanıcısı altında çalıştığı sıradan bir root sunucudur.
• Ajan okur, analiz eder ve önerir; müdahale eden işlemleri yalnızca onaydan sonra uygular.
• Kendini kanıtlamış üç yol vardır: ajan SSH üzerinden çalışma bilgisayarında, doğrudan sunucuda ya da bir bastion sanal makinesinde çalışır.
• Ayrı kullanıcı, onay modu, her oturumdan önce yedek ve promptta sır bulunmaması tartışmaya kapalıdır.
• Dil modeli sağlayıcıda çalıştığı için GPU gerekmez.
• Her KernelHost sunucusu gereksinimleri baştan karşılar; hatta ajan, KernelHost API üzerinden sunucuları kendisi devreye alabilir.