Yapay zekâyı sunucuya bağlama: AI ajanıyla deploy ve sunucu yönetimi

Çoğu kişi yapay zekâyı şimdiye kadar telefonun ucundaki çok bilgili bir meslektaş gibi kullanıyor: bir sunucu sorunu anlatılır, bir komut önerisi gelir, bu komut konsola kopyalanır, hata mesajı geri kopyalanır ve her şey çalışana kadar bu oyun tekrarlanır. Yapay zekâyı sunucunuza bağladığınız anda bu dolambaçlı yol ortadan kalkar. Claude Code, OpenAI Codex CLI veya Gemini CLI gibi bir AI ajanı sunucuda SSH üzerinden kendisi oturum açar, logları okur, yapılandırmayı kontrol eder, değişiklikleri uygular, sonucu test eder ve ne yaptığını yazıya döker. Görevi siz belirlersiniz ve geri alınamayan adımları siz onaylarsınız.

Bu yazı bir deneyim raporudur. KernelHost'ta aylardır bir AI ajanı her gün kendi altyapımız üzerinde bizimle birlikte çalışıyor: müşteri portalı, izleme, ödeme yolları, dokümantasyon. Ajan ile sunucu arasındaki bağlantının nasıl kurulduğunu, ajanın üretim sistemlerine hangi akışla deploy ettiğini, bu sırada bir şeylerin ters gitmesini ya da dışarı sızmasını hangi kuralların engellediğini ve tüm bunların çalışması için bir sunucunun neleri karşılaması gerektiğini gösteriyoruz. Araçlar ve mimarilerle ilgili temel bilgiler AI ile yönetilen sunucu: AI ajanlarını güvenle bağlama yazısında, sunucuya kurulum ise Claude Code ve Codex CLI rehberinde anlatılıyor.

Yapay zekâyı sunucuya bağlamak: bu ne anlama gelir

Bir yapay zekâyı sunucuya bağlamak, bir AI ajanına sunucunun komut satırına kendine ait, kontrollü bir erişim vermek demektir; bu erişim çoğunlukla bir SSH anahtarıyla sağlanır. Bu andan itibaren ajan komutları yalnızca önermekle kalmaz, onları kendisi çalıştırabilir, çıktıyı okuyabilir ve bir sonraki adımı buradan türetebilir. Dil modelinin kendisi yine sağlayıcıda (Anthropic, OpenAI veya Google) çalışır; bilgisayarınızda veya sunucunuzda yalnızca komutları gönderen hafif bir komut satırı aracı çalışır.

Belirleyici olan “kontrollü” kelimesidir. Sunucu erişimi olan bir ajan bir otopilot değil, müdahale eden her işlemden önce soran çok hızlı bir çalışma arkadaşıdır. Sormadan ne kadarını yapabileceğini siz belirlersiniz: salt okuma erişiminden, sabit bir akışa göre güncellemeleri kendi başına uygulamaya kadar.

Sohbet botu mu, ajan mı: tek tabloda fark

Böylece yarım saatlik gidip gelme çoğu zaman birkaç dakikaya iner ve komutu “yanlış yazma” hata kaynağı tamamen ortadan kalkar.

Bir AI ajanı sunucuda neler yapar: kendi işletimimizden örnekler

Aşağıdaki örnekler günlük işimizden geliyor. İsimleri, adresleri ve erişim bilgilerini vermiyoruz, akışlar ise gerçek.

Yedek ve geri dönüş yoluyla deploy

Müşteri portalında veya bir sunucu betiğinde bir şeyi değiştirdiğimizde, değişikliği uygulama işini ajan üstlenir. Başkasının yaptığı bir değişikliğin üzerine yazmamak için önce sunucudaki dosyayı bilinen son sürümle karşılaştırır. Ardından web dizininin dışında tarihli bir yedek oluşturur, bir geri dönüş betiği yazar, yeni dosyanın sözdizimini kontrol eder, dosyayı öncekiyle aynı sahip ve izinlerle yerine koyar, sonra da etkilenen işlevi test eder. İşin tamamlandığını ancak her şey yeşil olduğunda bildirir. Akışın tüm ayrıntıları aşağıda, deploy bölümünde yer alıyor.

Sorun giderme: dakikalar içinde belirtiden nedene

“Web sitesine ofisimizden erişilemiyor, dışarıdan ise erişilebiliyor.” Eskiden bu uzunca bir arama anlamına gelirdi. Ajan güvenlik duvarı kurallarını kontrol eder, koruma yazılımının loglarında ofis adresini arar, devreye giren kuralı bulur ve kuralı hangi isteğin tetiklediğini açıklar. Ne yapılacağına dair karar bizde kalır, dedektiflik işi ise bizde kalmaz. 502 Bad Gateway veya dolan diskler gibi tipik web sunucusu hatalarında da aynı şekilde çalışır: journalctl çıktısını ve uygulama loglarını okur, bir hipotez kurar ve bir şeyi değiştirmeden önce bu hipotezi kanıtlarla doğrular.

Ajanın kendi kurduğu izleme

İzleme sistemimizin büyük bir kısmı ajanla birlikte çalışarak ortaya çıktı: birkaç dakikada bir cron görevi ile bir servisi uçtan uca test eden ve bir hata olduğunda, örneğin bir Telegram botu üzerinden, telefona mesaj gönderen küçük kontrol betikleri. Ajan betiği yazar, bilerek tetiklenmiş bir hatayla test eder, cron görevini kurar ve alarmın nasıl susturulacağını belgeler. Böyle bir yapıyı temelde nasıl kuracağınızı Sunucu izleme kurulumu yazısı anlatıyor.

Genel bakışlar ve temizlik işleri

Hangi sunucular, ilgili sözleşme iptal edilmiş olmasına rağmen hâlâ çalışıyor? Hangi ek hizmetler için ödeme yapılıyor ama artık kullanılmıyor? Ajan bu tür soruları, veritabanlarını ve arayüzleri yalnızca okuma amaçlı sorgulayıp sonucu tablo hâlinde hazırlayarak yanıtlar. Temizlik yapmasına ancak onaydan sonra izin verilir; öncesinde de makinenin gerçekten kullanılmadığını, örneğin son günlerin veri trafiğine bakarak kontrol eder.

Kendiliğinden büyüyen dokümantasyon

Her değişiklik, değişiklik günlüğüne bir kayıtla ve gerekirse işletim el kitabına bir eklemeyle son bulur. Bu, ajana saniyelere mal olur, bize ise sonradan saatler kazandırır, çünkü “Bu aslında neden böyle?” sorusunun yazılı bir cevabı vardır.

Yapay zekânın doğrudan sunucuda çalışmasının avantajları

• Hız: Ajan, bir insanın dakikalar harcadığı şeyi saniyeler içinde okur ve bir hipotezi önce tarif etmek yerine hemen dener.
• Titizlik: Yalnızca birinin önemli bulduğu kesiti değil, dahil edilen dosyalarla birlikte yapılandırmanın tamamını ve hatanın çevresindeki log satırlarını okur.
• Tutarlı akış: Yedekleme, sözdizimi kontrolü ve doğrulama her seferinde çalışır; cuma akşamı da, yirminci küçük değişiklikte de.
• Ek yük olmadan dokümantasyon: Her değişiklik, nedeni, yedeğin yeri ve geri dönüş yoluyla birlikte açıklanır.
• Betik yazmayı öğrenmeden otomasyon: Kontrol betikleri, cron görevleri ve raporlar günlük dille yapılan bir tariften doğar ve kullanıma alınmadan önce test edilir.
• Çalışırken öğrenme: Ajan ne yaptığını ve nedenini açıklar. Yazdıklarını takip eden biri, birkaç hafta sonra sunucusunu belirgin şekilde daha iyi anlar.

Üç mimari ve hangisini kullandığımız

Bir ajanı bir sunucuya bağlamanın kendini kanıtlamış üç yolu vardır. Bunlar, aracın nerede çalıştığı ve erişim bilgilerinin nerede durduğu bakımından birbirinden ayrılır.

Bizim tercihimiz: ajan çalışma bilgisayarında, sunucular SSH üzerinden

Biz ilk seçenekle çalışıyoruz. Ajan çalışma bilgisayarında çalışır, her sunucunun SSH yapılandırmasında bir kaydı vardır ve ajan kendine ait bir anahtarla bağlanır. En önemli neden: çok sayıda sistemle ilgileniyoruz ve tek bir ajan tam da bu şekilde, bir oturum içinde bir sorunun nedenini birden fazla sunucu boyunca takip edebiliyor, örneğin web sunucusundan veritabanına, oradan da güvenlik duvarına kadar. Ayrıca AI sağlayıcısındaki oturum ve anahtarlar, zaten koruduğumuz tek bir yerde duruyor. Yalnızca bir sunucunuz varsa ve geceleri otomatik raporlar istiyorsanız ikinci seçenek sizin için iyi bir yoldur. Avantajlar ve dezavantajlar hakkında daha fazlasını AI ile yönetilen sunucu yazısında bulabilirsiniz.

Rehber: AI ajanını SSH üzerinden sunucuya bağlama

Aşağıdaki yedi adım Claude Code, Codex CLI ve Gemini CLI ile aynı şekilde çalışır. Örneklerde dokümantasyon adresi 203.0.113.10 ve kullanıcı adı deploy kullanılıyor; ikisini de kendi değerlerinizle değiştirin. Ön koşul, SSH güvenliği ve anahtarla giriş kurulumu yazısında anlatıldığı gibi SSH anahtarıyla oturum açılabilen bir sunucudur.

Adım 1: yalnızca ajan için ayrı bir SSH anahtarı oluşturun

Ajan hiçbir zaman sizin kişisel anahtarınızı almaz, kendine ait bir anahtar alır. Böylece kendi erişiminizi kaybetmeden onun erişimini istediğiniz an kaldırabilirsiniz ve loglarda hangi oturum açma işleminin ajandan geldiği görülebilir.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 kısa ve hızlıdır, güvenli kabul edilir. ki-agent yorumu daha sonra sunucunun authorized_keys dosyasında görünür ve anahtarı ilk bakışta tanınır kılar.

Adım 2: açık anahtarı sunucuya yerleştirin

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Erişimi daha da daraltmak isterseniz sunucudaki ~/.ssh/authorized_keys dosyasında anahtarın önüne seçenekler ekleyin. from= yalnızca belirli bir adresten oturum açılmasına izin verir; no-agent-forwarding ve no-port-forwarding ise bağlantının bir atlama tahtası olarak kullanılmasını engeller:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Sunucu bundan sonra Permission denied (publickey) yanıtı verirse SSH Permission denied (publickey) hatasını giderme yazısı yardımcı olur.

Adım 3: SSH yapılandırmasında bir host takma adı oluşturun

Takma ad, ajanın yalnızca kısa bir isim bilmesini ve her zaman doğru anahtarı kullanmasını sağlar:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

Bundan sonra ssh web-prod "systemctl status nginx" yeterlidir. IdentitiesOnly yes, SSH'ın anahtarlığınızdaki diğer anahtarları sırayla denemesini engeller. Her ek sunucu için ayrı bir blok oluşturun; test ve üretim sistemleri için en iyisi web-test ve web-prod gibi farklı isimler vermektir, böylece bir karışıklık daha isimden fark edilir.

Adım 4: ajanı kurun ve oturum açın

Claude Code, Codex CLI ve Gemini CLI; Linux, macOS ve Windows üzerinde çalışır ve sağlayıcıdaki bir hesapla ya da bir API anahtarıyla oturum açar. Kurulum ve tarayıcı olmadan oturum açma adım adım rehberde anlatılıyor. Çalışma bilgisayarı seçeneğinde aracı sunucuya değil, kendi bilgisayarınıza kurun.

Adım 5: ajanın uyacağı kuralları belirleyin

Üç araç da başlangıçta çalışma dizinindeki bir kural dosyasını okur: Claude Code CLAUDE.md dosyasını, Codex CLI AGENTS.md dosyasını, Gemini CLI ise GEMINI.md dosyasını. Sunucularınızda nasıl çalışılacağı burada yazar. Denenmiş bir başlangıç:

# Sunucularda çalışma kuralları

- Her değişiklikten önce web dizininin dışında tarihli bir yedek oluştur.
- Uygulamadan önce sözdizimini kontrol et (nginx -t, php -l, apachectl configtest).
- Uyguladıktan sonra servisi, logu ve işlevi kontrol et ve sonucu bildir.
- Parolaları, API anahtarlarını ve token'ları asla çıktıda gösterme, asla dosyalara kopyalama.
- Silme, veritabanı değişiklikleri ve geri alınamayan her şey yalnızca açık onaydan sonra.
- Kontrol panelinin yönettiği dosyaları doğrudan değiştirme.
- Testten sonra test dosyalarını kaldır.

Kurallar zamanla büyür. Ajan bir şeyi sizin istediğinizden farklı yaptığında, düzeltme her seferinde bir kural olarak bu dosyaya yazılmalıdır. Birkaç hafta sonra tam olarak sizin çalışacağınız gibi çalışır.

Adım 6: onayları ve beyaz listeyi ayarlayın

Araçlar varsayılan olarak bir şeyi değiştiren her komuttan önce sorar. Başlangıçta doğru olan budur. Sürekli onayladığınız okuma komutlarına kalıcı olarak izin verebilirsiniz. Claude Code'da bu, .claude/settings.json dosyasında yapılır:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Bu listede olmayan her şey yine sizin onayınızı gerektirir. Tüm onay sorularını kapatan seçeneklerin yeri olsa olsa tek kullanımlık bir test makinesidir.

Adım 7: ilk görev: yalnızca okuma

Hiçbir şeyi değiştiremeyecek görevlerle başlayın ve ajanın nasıl ilerlediğini gözlemleyin:

web-prod üzerinde son 24 saatin nginx hatalarını kontrol et ve en sık görülen üç
nedeni, her biri için logdan bir kanıtla birlikte belirt. Hiçbir şeyi değiştirme.

Analizler doğru çıktığında sırada küçük değişiklikler vardır, örneğin yeni bir log rotasyonu veya bir systemd servisi; üretim sistemine deploy ise ancak bundan sonra gelir.

Ajan nasıl deploy eder: üretim sistemindeki her değişiklik için akışımız

Bir AI ajanı bir üretim sistemine yalnızca yedek, önceden hazırlanmış bir geri dönüş yolu ile uygulama öncesinde ve sonrasında birer kontrol içeren sabit bir akışa göre deploy etmelidir. Bizde bu akış şöyle görünür:

1. Mevcut durumu kontrol etmek. Sunucudaki dosya bilinen son sürümle karşılaştırılır. Bu arada başka biri dosyayı değiştirdiyse ajan, başkasının değişikliğinin üzerine yazmak yerine işlemi durdurur ve sorar.
2. Yedek oluşturmak. Etkilenen dosyalar, tarihleriyle birlikte web dizininin dışındaki bir yedek klasörüne gider. Web dizinindeki bir yedek, koşullara bağlı olarak herkese açık şekilde indirilebilir olabilir.
3. Geri dönüş yolunu hazırlamak. Eski durumu tek bir komutla geri yükleyen küçük bir betik, acil durum çıktığında değil, değişiklikten önce oluşturulur.
4. Sözdizimini kontrol etmek. Yeni dosya uygulanmadan önce kontrol edilir: PHP için php -l, nginx için nginx -t ile. Böylece bir sözdizimi hatası üretim sistemine hiç ulaşmaz.
5. Doğru izinlerle uygulamak. Sahip, grup ve dosya izinleri eski sürümden devralınır. Yanlış izinler, sözdizimi hatalarından sonra, güncelleme sonrası kesintilerin en sık nedenidir.
6. Yan etkisiz test etmek. Testler salt okuma yoluyla, uydurma test verileriyle veya yalıtılmış bir ortamda yapılır; asla gerçek siparişlerle veya gerçek müşteri verileriyle yapılmaz.
7. Canlıda kontrol etmek. Uygulamanın ardından HTTP durumu, hata logu ve değiştirilen işlev kontrol edilir.
8. Belgelemek. Değişiklik günlüğü ve işletim el kitabı, yedeğin yeri ve geri dönüş komutu dahil olmak üzere güncellenir.

Gerçek yollar yerine yer tutucularla bir komut dizisi olarak bu, aşağı yukarı şöyle görünür:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Geri dönüş yolu neden değişiklikten önce oluşturulur

Bir hata anında kimse temiz bir geri dönüş yolu düşünecek en iyi durumda değildir. Betik zaten hazırsa geri alma saniyeler süren bir iştir ve uygulama sonrasındaki kontrol başarısız olursa ajan bunu kendisi de yürütebilir. Bir şeyi “çabucak” değiştiren bir ajan ile kendisine bir üretim sistemi emanet edilen bir ajan arasındaki en büyük fark budur.

Hiçbir şeyi bozamayan testler

Pek çok işlev, bir şey gerçekleşmeden test edilemez: bir sipariş, bir ödeme, bir e-posta. Burada üç teknik yardımcı olur. Birincisi, aracın kendisinin sunduğu deneme çalıştırmaları. İkincisi, hiçbir yerde var olmadığı kesin olan uydurma ID'ler. Üçüncüsü, yalıtılmış bir ortam: ağ bağlantısı olmayan kendi ağ ad alanında çalışan bir süreç (unshare -n) ne harici bir arayüze ulaşabilir ne de yanlışlıkla bir şey satın alabilir, ama yerel veritabanını Unix soketi üzerinden görmeye devam eder. Testten sonra tüm test dosyaları kaldırılır.

Paraya mal olan işlemler kilit gerektirir

Bir akış bir şey sipariş ediyor, faturalandırıyor veya siliyorsa, biri çift tıklasa ya da ajan bir komutu tekrarlasa bile aynı anda iki kez çalışmamalıdır. Linux'ta en basit çözüm flock komutudur:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "zaten çalışıyor"

Veritabanı uygulamalarında adlandırılmış bir kilit (MySQL ve MariaDB'de GET_LOCK), arayüzlerde ise bir Idempotency-Key aynı amaca hizmet eder; bununla ilgili daha fazlası aşağıda, KernelHost API bölümünde.

Güvenlik: hiçbir şey dışarı sızmadan ajana erişim vermek

En sık duyduğumuz endişe şu: “Peki verilerim ne olacak?” Dürüst cevap: ajan okuduğu her şeyi işlenmesi için sağlayıcının dil modeline gönderir. Bu yüzden ajanın neyi görebileceğine aşağıdaki kurallarla siz karar verirsiniz.

Sırların sohbette yeri yoktur

Parolalar, API anahtarları ve token'lar asla bir göreve yazılmaz ve ajan tarafından asla çıktı olarak verilmez. Betikler bunları, izinleri 600 olan ve ajanın betiği kullanmak için içeriğini görüntülemesi gerekmeyen dosyalardan okur. Buna rağmen bir anahtar sohbete düşerse hemen sağlayıcıda iptal edilir ve yeniden oluşturulur. Anahtar parçalarının da sohbette yeri yoktur: bir anahtarın ilk karakterleri sorun gidermede kimseye yardımcı olmaz, ama bir saldırganın işini kısaltır.

Ayrı anahtarlar, ayrı yetkiler, her an geri alınabilir

Her ajan kendine ait bir SSH anahtarı alır ve her anahtar authorized_keys dosyasında yorumundan tanınır. Erişimi kaldırmak isterseniz o tek satırı silersiniz. Yeterli olduğu yerlerde ajan, kendine ait bir kullanıcıyla ve yalnızca gerekli komutlara izin veren bir sudo kuralıyla çalışır. API'ler için mümkün olan en düşük yetkilere sahip ayrı anahtarlar kullanılır; salt değerlendirme amaçlı anahtarlar yalnızca okuma yetkisi alır.

Onaylar: insan olmadan asla gerçekleşmeyenler

Bizde ajan açık onay olmadan silme yapamaz, veritabanlarına yazamaz, güvenlik duvarı veya koruma kurallarını gevşetemez, makineleri durduramaz ve hiçbir şey sipariş edemez. Araçlar bunu destekler: Claude Code müdahale eden işlemleri durdurur ve ayrıca, bir güvenlik filtresinin riskli komutları tanıyıp onay verilene kadar engelleyeceği şekilde ayarlanabilir. Günlük işimizden: bu filtre, teknik açıdan doğru ama geri alınamaz olan bir işlemi birden fazla kez durdurdu. İşlem ancak bir insan onu açıkça onayladıktan sonra çalıştı. Tam da olması gerektiği gibi.

İzlenebilirlik: log, değişiklik listesi, yedekler

Her oturum bir insanın okuyabileceği izler bırakır: tarihli yedekler, geri dönüş betiği, değişiklik günlüğündeki kayıt ve sistem logundaki oturum açma kayıtları. /etc dizinini ek olarak etckeeper ile Git'te yönetirseniz her yapılandırma değişikliğini bir diff olarak görürsünüz. İzlenemeyen şey geri de alınamaz. Temel, çalışan bir yedekleme stratejisi olmaya devam eder, çünkü bir ajan yedeğin yerini tutmaz.

Bir AI ajanı için hangi sunucu uygundur?

AI destekli yönetim için bir sunucunun tam root erişimine, SSH anahtarıyla oturum açmaya, engelsiz giden bağlantılara, sürekli DDoS korumasına ve ideal olarak sunucuların otomatik biçimde sipariş edilip yönetilebildiği bir API'ye ihtiyacı vardır. GPU'ya ihtiyacı yoktur, çünkü dil modeli sağlayıcıda çalışır.

AI ile yönetilen sunucular için neden KernelHost

Bir AI ajanı temelde kabuk erişimi aldığı her sunucuyla çalışabilir. Ancak pratikte, ona gerçekten ne kadar iş devredebileceğinizi ortam belirler. KernelHost'un bir KVM root sunucusunda veya dedicated sunucusunda kısıtlanmış hesaplar, AI sağlayıcılarına giden HTTPS bağlantılarının önünde engeller ve denemeyi pahalı hâle getiren bir sözleşme bağı yoktur. Sürekli DDoS koruması her sunucuda ek ücret olmadan etkindir; yoğun hesaplama gerektiren görevler için ise size ayrılmış çekirdeklere sahip Profesyonel VDS paketleri vardır. Faturalandırma PrePaid olarak yapılır: sözleşme yok, asgari süre yok, kurulum ücreti yok. Önce denemek isterseniz ücretsiz test sunucusuyla başlayın.

KernelHost API: ajanınız sunucuları kendisi sipariş eder ve yönetir

En büyük kaldıraç, tek tek sunucuların bir seviye üstünde yer alır. KernelHost API üzerinden bir ajan ürünleri ve fiyatları sorgulayabilir, sunucu sipariş edebilir, hizmetlerinin durumunu okuyabilir, sunucuları başlatabilir, durdurabilir ve yeniden başlatabilir, ayrıca iptal talepleri oluşturup bunları geri alabilir. Böylece “Bana bir test sunucusu kur” tek bir görev hâline gelir: ajan makineyi sipariş eder, kurulumun tamamlanmasını bekler, SSH üzerinden bağlanır, uygulamayı kurar ve adresi geri bildirir.

Arayüz, ajanlar tarafından kullanılmak üzere bilinçli olarak temkinli tasarlandı. API anahtarları yalnızca ihtiyaç duydukları yetkileri alır; değerlendirme için kullanılan bir anahtar hiçbir şey sipariş edemez. Bir Idempotency-Key, ajanın zaman aşımı hatasından sonra tekrarladığı bir siparişin iki kez yürütülmemesini sağlar. İstekler anahtar başına, hesap başına ve adres başına sınırlandırılmıştır; böylece sonsuz döngüye giren bir ajan bile bir çığ başlatamaz. Ayrıca erişim bilgilerinin her sorgulanması bir e-posta bildirimi tetikler; bu sayede bir ajanın erişim bilgilerini ne zaman okuduğunu görürsünüz.

AI ile yönetilen bir sunucunun maliyeti nedir?

İki kalem vardır. Birincisi sunucunun kendisi: SSH üzerinden çalışan bir ajan için sunucunun özel bir donanıma ihtiyacı yoktur, uygulamanızın zaten üzerinde çalıştığı her root sunucu yeterlidir. Ajan doğrudan sunucuda çalışıyorsa aracın kendisi yalnızca birkaç yüz megabayt belleğe ihtiyaç duyar; üzerinde başka pek bir şey çalışmıyorsa 2 vCPU ve 4 GB RAM'li bir root sunucu yeterlidir. İkincisi dil modeli: ya sağlayıcının komut satırı aracının kullanımını içeren bir aboneliği ya da kullanıma göre faturalandırılan bir API anahtarı. Günlük yoğun kullanımda abonelik çoğunlukla daha ucuzdur; başında insan olmayan otomatik görevler için ise API anahtarı temiz yoldur, çünkü aylık bir bütçeyle sınırlandırılabilir. Güncel sunucu fiyatlarını Root sunucu kiralama sayfasında bulabilirsiniz.

Sık yapılan hatalar ve bunlardan nasıl kaçınırsınız

• Ajan, yöneticinin kişisel anahtarıyla çalışıyor. Bu durumda erişimi ayrıca kaldırılamaz ve loglarda ayırt edilemez. Çözüm: kendi yorumuna sahip ayrı bir anahtar.
• Tüm onay soruları kapatılmış. Bu ilk gün tıklamalardan tasarruf sağlar, bir gün de bir sunucuya mal olur. Çözüm: okuma komutları için beyaz liste, müdahale eden her şey için onay.
• Değişiklikten önce yedek yok. Çözüm: CLAUDE.md veya AGENTS.md dosyasında sabit bir kural olarak yedek ve geri dönüş betiği.
• Web dizininde yedekler. Web kök dizinindeki config.php.bak gibi bir dosya, veritabanı parolasıyla birlikte herkese açık şekilde indirilebilir olabilir. Çözüm: web dizininin dışında, izinleri 700 olan bir yedek klasörü.
• Promptta sırlar. Çözüm: erişim bilgileri yalnızca betiklerin okuduğu, izinleri 600 olan dosyalarda; bir dikkatsizlik olursa hemen yeniden oluşturulur.
• Çift yürütme. Çift tıklama veya tekrarlanan bir istek iki kez sipariş verir. Çözüm: flock ile kilit veya Idempotency-Key.
• Kontrol panelinin yönettiği dosyalar doğrudan değiştirilmiş. Panel bir sonraki güncellemede bu dosyaların üzerine yazar ya da bu dosyalar yüzünden bozulur. Çözüm: bu tür dosyaları kurallarda hariç tutmak ve değişiklikleri panel ya da panelin arayüzü üzerinden yapmak.
• Çıktılar kontrol edilmeden kabul edilmiş. Bir çıktıyı anlamayan ajan tahmin eder. Çözüm: kanıt istemek (“bana log satırını göster”) ve sonuçları canlıda kontrol ettirmek.

Kısaca özetle

• Bir yapay zekâyı sunucuya bağlamak, Claude Code, Codex CLI veya Gemini CLI gibi bir ajana kendine ait bir SSH anahtarı ve net kurallar vermek demektir.
• Ajan logları okur, değişiklikleri uygular, sonucu kontrol eder ve belgeler; müdahale eden adımlar yalnızca onayla çalışır.
• Her deploy sabit bir akışı izler: mevcut durumu kontrol etmek, yedeklemek, geri dönüş yolunu hazırlamak, sözdizimini kontrol etmek, uygulamak, test etmek, canlıda kontrol etmek, belgelemek.
• Sırların sohbette asla yeri yoktur; paraya mal olan işlemler ise çift yürütmeye karşı bir kilit gerektirir.
• Sunucunun root erişimine, SSH anahtarlarına, serbest giden bağlantılara ve DDoS korumasına ihtiyacı vardır, GPU'ya ise ihtiyacı yoktur.
• KernelHost sunucuları, sözleşme bağı olmadan PrePaid olarak, tüm gereksinimleri baştan karşılar; hatta ajan, KernelHost API üzerinden sunucuları kendisi sipariş edip yönetebilir.