Hosting yönetimi genellikle geliştirmeyi kesintiye uğratır. Kodunuzu bir editörde yazarsınız, bir hosting panelini açıp bir web sitesi oluşturursunuz, projeyi paketlemek ya da yüklemek için terminale geçersiniz, dağıtımı incelemek için tekrar panele dönersiniz ve DNS, günlükler veya sunucu kaynaklarının ele alınması gerektiğinde daha fazla araç açarsınız.

Hostinger Connector, bu bağlam değiştirmeyi azaltır. Model Context Protocol (MCP) aracılığıyla Hostinger hizmetlerini yapay zekâ kodlama araçlarına bağlayarak, desteklenen barındırma kaynaklarını editörünüzden ayrılmadan bir yapay zekâ asistanına inceletebilir veya yönetebilirsiniz.

Bu kulağa kullanışlı geliyor. Ancak daha önemli bir soruyu da beraberinde getiriyor: Bir yapay zekâ asistanının gerçek hosting görevlerini doğru şekilde yerine getireceğine güvenebilir misiniz?

Bunu öğrenmek için Hostinger Connector’ı VS Code ve GitHub Copilot ile gerçek bir Hostinger hesabında test ettim. PulseWatch adlı küçük bir Express.js uygulaması kullandım ve kurulumu canlı dağıtıma kadar uzanan iş akışını takip ettim. Ayrıca tekrarlanan dağıtımları, derleme kayıtlarını, günlükleri ve uygulamanın başlangıç komutunu bilerek bozduktan sonraki kurtarma sürecini de test ettim.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger Sitesini Ziyaret Edin

Hostinger Connector Artıları ve Eksileri

Puan Dağılımı

İşte Hostinger Connector’ı bir geliştiricinin kullanıp kullanmamaya karar verirken en çok önem verdiği alanlarda nasıl puanladığım: maliyet, özellik yelpazesi, günlük kullanım kolaylığı, gerçek görevleri ne kadar doğru yürüttüğü ve bir şeyler ters gittiğinde arkasındaki destek. Her puan, pazarlama sayfasına değil, test sırasında gerçekten bulduklarıma dayanıyor.

Hostinger Connector Planları ve Fiyatlandırması

Hostinger Connector ayrı bir ürün olarak satılmıyor. Hostinger, Connector’ın tüm planlarla birlikte ücretsiz olduğunu söylüyor; bu da hosting faturanıza eklenecek ayrı bir aylık Connector ücretinin olmadığı anlamına geliyor.

Ancak “ücretsiz” ifadesinin bağlamı önemlidir. Connector, Hostinger kaynaklarını yönetir; onların yerine geçmez. Yapmasını istediğiniz görevler için yine uygun bir hosting, cloud, VPS, alan adı, e-posta veya başka bir Hostinger hizmetine ihtiyacınız vardır.

Bu incelemenin yapıldığı sırada Connector açılış sayfasında Business Web Hosting ve Cloud Startup öne çıkarılıyordu.

Fiyatlar uygulanabilir vergiler hariç gösteriliyordu. Promosyon fiyatları ve yenileme ücretleri değişebilir; bu yüzden planı yalnızca ilan edilen aylık fiyata bakarak değil, güncel ödeme toplamına bakarak değerlendirin.

Fiyatlandırma içgörüsü: Sadece Connector’a erişmek için daha yüksek bir plan satın almayın. Planı, ihtiyacınız olan web sitesi ve web uygulaması sayısına, bunların gerektirdiği kaynaklara ve istediğiniz destek seviyesine göre seçin. Connector, fiyatlandırılan ana ürün değil, dahil edilmiş bir yönetim katmanıdır.

Hostinger, uygun hosting alımları için 30 günlük para iade garantisi sunduğunu belirtiyor. Connector’ın ayrı bir ücreti olmadığı için değerlendirilecek ayrı bir Connector iade politikası yoktur.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger Sitesini Ziyaret Edin

Özellikler

• Node.js uygulama dağıtımı
• PHP ve HTML dağıtımı
• WordPress web sitesi yönetimi
• Website Builder ve Horizons iş akışları
• GitHub bağlantılı dağıtımlar
• Alan adı bağlantısı ve organizasyonu
• DNS inceleme ve güncelleme
• SSL ve web sitesi tanılama
• Veritabanı yönetimi
• VPS kurulumu ve yönetimi
• Docker proje dağıtımı
• CPU ve bellek izleme
• Bandwidth ve disk kontrolleri
• Hizmet ve konteyner yeniden başlatmaları
• Kötü amaçlı yazılım taraması
• Yedek geri yükleme
• E-posta kampanyası kurulumu
• Dağıtım ve derleme incelemesi

Kesin eylemler, hesabınızdaki Hostinger hizmetlerine ve bağlı AI istemcisine açılan araçlara bağlıdır.

Hostinger ayrıca oran sınırlamalarını belgeliyor. Connector FAQ’ya göre varsayılan izin 60 istek/dakika ve 1.000 istek/saat olup, oran sınırı bilgisi yanıt başlıklarında döndürülür.

Bu sınırlar etkileşimli kullanım için oldukça cömerttir; ancak otomatik veya çok tekrarlı iş akışları yine de gereksiz yinelenen çağrılardan kaçınmalıdır.

Kullanım Kolaylığı

1. Kurulum ve Kimlik Doğrulama

Hostinger Connector’ın dağıtım ve hosting yönetimini gerçekten iyi yapıp yapmadığını değerlendirmeden önce, ilk etapta çalıştırmak için ne gerektiğini bilmem gerekiyordu.

Editör içinde kalmaya odaklanan bir araç, kurulum config dosyalarını düzenlemeyi, API tokenları üretmeyi veya tekrar tekrar kimlik doğrulamayı gerektirirse hızla çekiciliğini kaybeder. Bu bölüm yalnızca kurulumu kapsar. Uygulamalı görev testleri hemen ardından geliyor.

Eklentiyi Yükleme

Hostinger Connector’ı VS Code Marketplace’ten yükledim. “Hostinger” aradığımda ilk sonuç olarak çıktı, yayıncı Hostinger Official olarak listelenmişti ve ilk denemede iki dakikadan kısa sürede yüklendi.

Son satırın üzerinde durmaya değer bir uyarı var. Beş yıldız güçlü görünür, ama iki yorumluk bir örneklem bana tipik kullanıcı deneyimi hakkında neredeyse hiçbir şey söylemez. İnceleme metninde bu sayıya fazla bel bağlamazdım.

Beni şaşırtan bir ön koşul vardı: Hostinger Connector, Hostinger araçlarını sağlar; ancak bunları gerçekten çağırmak için editörde zaten etkin olan bir AI aracısına ihtiyaç duyar.

Eklentinin kendisi tek başına konuşabileceği bir şeye sahip değildir. VS Code’da o aracı, şu anda VS Code’un MCP araç çağrıları için sunduğu AI arayüzü olan GitHub Copilot Chat’tir. Ben Copilot’u zaten etkin kullanıyordum, bu yüzden bu durum beni yavaşlatmadı; ancak okuyucular Connector’ın arkasında çalışan AI aracısı kadar kullanışlı olduğunu bilmelidir.

Yüklü ve oturum açmış bir araç olmadan, bağlanacağı hiçbir şey yoktur.

Kurulumun gerektirmediği şeyler:

• API anahtarı
• hPanel’den kopyalanmış bir token
• Manuel MCP yapılandırma dosyası düzenleme
• Yerel olarak saklanan kimlik bilgileri
• Özel bir sunucu komutu

Eklentinin kurulumu, tüm testin en sorunsuz bölümlerinden biriydi. Tek gerçek sorun, Hostinger’ın ön plana çıkarmadığı bir bağımlılıktı: eklentinin bir şey yapabilmesi için editörünüzde etkin bir AI aracısına ihtiyacı vardır.

Eklenti yerindeyken, bir gerçek hesabı bağlamanın da aynı derecede basit olup olmadığını görmek istedim.

Hesabı Bağlama

Hesap bağlantısı, “1-Click Connect” düğmesi üzerinden OAuth kullandı. VS Code tarayıcımda bir Hostinger yetkilendirme sayfası açtı, mevcut Hostinger oturumumu algıladı ve hostinger-mcp adlı bir şey için erişimi onaylamamı istedi.

Allow’a tıkladıktan sonra VS Code’a “Connected via OAuth” yazan bir ekrana geri döndüm.

Yetkilendirme ekranı bana Connector’ın web sitelerini, hostingi, alan adlarını, abonelikleri ve diğer Hostinger hizmetlerini yönetebileceğini söyledi.

Bu bir kategori listesidir, izin bazında ayrıntılı bir döküm değil. Burada daha fazla ayrıntı görmek isterdim; çünkü “abonelikleri yönet” ve “web sitelerini yönet” çok farklı risk düzeylerini kapsar.

Bana bu kontrolün bir kısmını sağlayan şey, eklenti içindeki her araç kategorisini listeleyen ve her birini ayrı ayrı etkinleştirmeme ya da devre dışı bırakmama izin veren ayrı bir paneldi:

Bu toplamda 199 araç demek, bunların 125’i varsayılan olarak etkin. E-ticaret ve VPS’yi doğrudan test etmeye hazır olana kadar kapalı bıraktım ve eklenti test boyunca bu sınırları korudu.

Bu, Hostinger’ın pazarlama sayfasında görünmeyen ama bir yapay zekâ asistanına ne kadar hesap erişimi vereceğine karar veren herkes için önemli olan bir güvenlik ayrıntısıdır. Bunu gerçekten güçlü bir yön olarak değerlendiririm.

Hesabın bağlantısını kesmek, saklanan bir tokenı değiştirmeye veya Hostinger şifrenizi aramaya gerek kalmadan aynı panelden mümkündür.

Yetkilendirme hızlıydı ve benim token yönetmemi gerektirmedi, ancak izin ekranı ayrıntılı olmaktan çok genel kalıyor. Eklenti içindeki kategori düzeyindeki araç kontrolleri, OAuth ekranının sağladığından çok daha fazla gerçek risk sınırlaması sunuyor.

Desteklenen Editörler

Hostinger, eklentinin kendi başlangıç ekranından derlenen aşağıdaki istemci desteğini listeliyor:

Birincil test ortamım olarak VS Code ile GitHub Copilot kullandım.

Kurulum bana Connector’ın erişiminin kolay olduğunu gösterdi. Bağlandıktan sonra işini gerçekten iyi yapıp yapmadığını henüz söylemiyordu; daha zor olan soruya ise şimdi geçtim.

2. Hostinger Connector İş Başında

Bir eklentiyi kurmak ve bağlamak kolay kısımdır. Asıl önemli olan, gerçek hosting işini doğru yapıp yapmadığıdır; bu yüzden PulseWatch adlı küçük bir Express.js uygulaması oluşturdum ve Connector’ı bir geliştiricinin kurulumdan sonra izleyebileceği aynı yoldan geçirdim: hesabı incelemek, bir dağıtım hedefi bulmak, projeyi dağıtmak, güncellemek, sonuçları incelemek ve bilerek oluşturduğum bir hatadan kurtarmak.

PulseWatch bilerek basitti: bir Express sunucusu, bir ana sayfa, bir package.json start scripti ve JSON döndüren bir /api/health uç noktası. O sağlık uç noktası daha sonra önemli hale geldi.

Bir hosting platformu, uygulama başlangıçta başarısız olsa bile tamamlanmış bir derleme raporlayabilir. Canlı bir uç nokta bana, dağıtılan sürecin gerçekten yanıt verip vermediğini kontrol etmek için durum rozetine güvenmek yerine bağımsız bir yol sağladı.

Hesap Verilerini Okuma

Önce asistanı canlı değişikliklere yaklaştırmadan yalnızca okuma amaçlı istemlerle başladım. Hesabımı doğru tanımlayamazsa, onu dağıtımlar, DNS veya VPS eylemleri için güvenilir bulmam için pek neden olmazdı.

Connector’ın web sitesi listeleme aracı beş site döndürdü:

• webhostpro.io
• hostinger-monitor.hostadvice.com
• hostingermonitor.hostadvice.com
• blog.webhostpro.io
• red-lapwing-356282.hostingersite.com

Hesabımda aslında bundan daha fazlası vardı. hPanel; Premium, Business ve Growth planlarına yayılmış, WordPress siteleri, PHP/HTML siteleri, Website Builder projeleri ve birkaç geçici alan adı dahil olmak üzere daha fazla web sitesi gösteriyordu.

Aktif hosting planlarım hakkında ayrı bir istemde asistan bana “one active hosting plan” olduğunu söyledi. hPanel ise üç plan gösteriyordu: Premium, Growth ve Business.

Adil olmak gerekirse, ona karşı çıktığımda ve tutarsızlığı işaret ettiğimde kendini düzeltti, doğruladığını varsaydığı şey ile gerçekten doğruladığı şeyi net biçimde ayırdı ve yanlış iddiayı tekrarlamadı.

Bu, hatalıda ısrar etmekten daha iyi bir başarısızlık modudur; ancak planla ilgili herhangi bir sorunun ilk yanıtı olduğu gibi kabul edilmemelidir.

Salt okuma erişimi çalıştı, ancak hesap geneli sorularda ilk cevap eksikti. Sorgulandığında kendini düzeltti; bu önemli, ama bunu sorgulamak zorunda kalmamalıydım.

Hesap görünürlüğündeki bu boşluk, daha büyük bir sorunun habercisiydi. Bunun önemli olup olmadığını anlamak için sırada, daha önce adı söylenmemiş yeni bir web sitesini bulmasını istediğim test vardı.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger Sitesini Ziyaret Edin

Bir Dağıtım Hedefi Bulma

Testlerde en çok sonucu burada gördüm. Asistandan, yeni oluşturulmuş bir Node.js web sitesini, bana alan adını söylemeden ve mevcut hiçbir siteye dokunmadan tanımlamasını istedim.

Hedef seçimi, canlı bir hesap üzerinde işlem yapabilen bir araç için temel bir güvenlik gereksinimidir; bu yüzden temiz bir yanıttan ziyade belirsizliği nasıl ele aldığını görmek istedim.

Olanlar sırasıyla şöyleydi:

Temel sorun şuydu: kullandığı iki ID, hosting order ID değil, domain kaynak ID’leriydi. Canlı bir web sitesi oluşturma aracını bunlarla çağırmadan önce bu ayrımı hiç doğrulamadı.

Kendisine bunu açıkladığımda, asistan sonunda doğru bir açıklama yaptı: Tüm süre boyunca kullanılabilir bir web sitesi listeleme aracı vardı, ancak hPanel’de yeni bir site oluşturduktan sonra onu tekrar çağırmadı; bunun yerine doğrulanmamış bir alan adıyla boşluğu doldurdu.

O yeni kaydı kontrol etmek için aynı listeleme aracını tekrar çalıştırmasını doğrudan istediğimde, bunun yerine üç ilgisiz dağıtım-araçlarını çağırdı ve “yeni web sitesi görünmedi” sonucuna vardı; oysa gerçekten yaptığı araç çağrıları böyle bir sonuca destek veremezdi.

Bunların hiçbiri hesabımda yanlışlıkla bir web sitesi oluşturmadı. Başarısız çağrılar geride bir şey bırakmadı. Ancak desenin adını açıkça koymak önemli. Eksik veriler karşısında asistan boşluğu makul görünen bir varsayımla doldurdu, zayıf bir sinyali güçlü kanıt gibi ele aldı ve bu varsayım doğrulanmadan canlı bir hesap üzerinde işlem yaptı.

Bu bölümdeki en önemli bulgu budur. Connector, bir hedefi tahmin eder ve tahminine dayanarak hareket eder; durup sormaz. Burada güvenli biçimde başarısız oldu, ancak zayıf bir sinyali kanıt gibi görme alışkanlığı kendi hesabınızda dikkat etmeniz gereken şeydir.

Connector tek başına yeni hedefi bulamayınca geriye bir tek seçenek kaldı: hedefi kendim kurup bunun bir şeyi değiştirip değiştirmediğini görmek.

Kurulumu hPanel’de Tamamlama

Connector yeni hedefi kendi başına güvenilir şekilde bulamadığı için, Connector tabanlı dağıtım mümkün olmadan önce Hostinger’ın ne hazırladığını görmek amacıyla ilk kurulumu hPanel üzerinden manuel olarak tamamladım.

Yol şuydu: Yeni site oluştur → Node.js web uygulaması → geçici alan adı → Hostinger otomatik olarak 147ms gecikme tahminiyle Birleşik Krallık veri merkezini seçti → üç dağıtım yönteminden biri.

Bu üçüncü ekran kendi başına da önemli. Hostinger, GitHub içe aktarma ve manuel dosya yüklemeyle birlikte “Build with Hostinger Connector”ı bir dağıtım yöntemi olarak sunuyor. Bunu, site kurulumunu tamamlamasını bekleyerek seçtim.

Bunun yerine, zaten tamamladığım Connector kurulum sayfasına yönlendirdi. Bu gerçek bir onboarding boşluğu. Connector’a özgü bir yol olarak sunulan seçenek aslında hiçbir şey sağlamadı.

Geri dönüp bunun yerine manuel dosya yüklemeyi seçtim. Hostinger proje arşivimi kabul etti (11.46 KB, node_modules hariç tutulmuştu) ve ayarlar ekranı doğru otomatik algılamayı gösterdi:

• Çerçeve ön ayarı: Express
• Node sürümü: 22.x
• Kök dizin: ./

Deploy’a tıkladım. Başarıyla tamamlandı ve Hostinger bana gerçek bir geçici alan adı verdi: orange-walrus-700988.hostingersite.com. Bu, Connector’ın daha önce uydurduğu alan adından farklıdır. Hem ana sayfayı hem de /api/health uç noktasını manuel olarak açtım ve ikisinin de çalıştığını doğruladım.

Manuel yol, Connector’ın bulmasını beklemeyi bıraktığım anda sorunsuz çalıştı. Bu ekrandaki “Build with Hostinger Connector” düğmesi düzeltilmeli ya da kaldırılmalı. Şu anda gerçekleştirmediği bir şeyi vaat ediyor.

Artık gerçek ve doğrulanmış bir web sitesi vardı. Bir sonraki soru, Connector’ın artık bulacağı sağlam bir şey olduğunda farklı davranıp davranmayacağıydı.

Canlı Uygulamayı Dağıtma ve Güncelleme

Gerçek ve doğrulanmış bir web sitesi yerindeyken, Connector’a tam o alan adını incelemesini söyledim. Bu kez temiz biçimde çalıştı.

Bu önemli bir şeyi doğruladı: önceki başarısızlıklar, var olan bir Node.js sitesiyle çalışabilme değil, yeni bir hedefi bulma ve oluşturma ile ilgiliydi.

Sonra Hostinger’ın en çok öne çıkardığı özelliği test ettim: kodu yerelde değiştirip hPanel açmadan yayınlamak.

Asistandan, ana sayfadaki tek bir satır metni “Monitor Every Service. Catch Every Issue.” ifadesinden “Monitor Every Service. Resolve Issues Faster.” ifadesine değiştirmesini istedim.

Tüm güncelleme yaklaşık bir dakika sürdü. Asistan, yeni dağıtımı hemen sonra “pending” olarak bildirdi; bunun nedeni, Hostinger işlemi henüz tamamlamadan kontrol etmiş olmasıydı.

Ben canlı siteyi yenilediğimde, yeni başlık zaten oradaydı.

Sonrasında getirdiği derleme günlükleri spesifik ve kullanışlıydı: 67 paket eklendi, 68 paket denetlendi, sıfır güvenlik açığı bulundu, hata yoktu.

Var olan sitelerde bu, Hostinger’ın vaat ettiği iş akışına oldukça yakın: düzenle, yerelde doğrula, gönder ve onayla; hepsi editörden ayrılmadan, yaklaşık bir dakikada. Tüm testteki en güçlü sonuç buydu.

Temiz bir dağıtım yalnızca mutlu yolun çalıştığını söyler. Connector’ın baskı altında gerçekte ne yaptığını görmek için uygulamayı bilerek bozdum.

Hata Kurtarmasını Test Etme

Bir araç, yalnızca temiz bir demo değil, gerçek bir hata ile karşılaştığında güven kazanır. Connector’ın durum raporlamasının ve günlüklerinin bir hatayı gerçekten teşhis etmeme yardımcı olup olmadığını görmek için uygulamayı bilerek bozduğum.

Herhangi bir değişiklik yapmadan önce asistan package.json dosyasını package.json.bak olarak yedekledi; bu kendi başına iyi bir alışkanlık.

Ardından start scriptini “start”: “node server.js” ifadesinden “start”: “node missing-server.js” olarak değiştirdi; bu dosya mevcut değil.

Yerelde çalıştırmak gerçek, tekrarlanabilir bir hatayı doğruladı: Error: Cannot find module ‘…/missing-server.js’.

Bozuk sürümü, ne olacağını görmek için bilerek dağıttım.

Connector üzerinden erişilebilen derleme günlükleri yalnızca bağımlılıkların başarıyla kurulduğunu ve başka bir şey olmadığını gösteriyordu. Eksik modül çalışma zamanı hatası bu günlüklerde hiç görünmedi. Yeşil bir “tamamlandı” rozeti gören bir geliştiricinin sitenin bozuk olduğundan şüphelenmesi için hiçbir neden olmazdı.

Kurtarma sorunsuz geçti. Asistan package.json dosyasını yedekten geri yükledi, uygulamayı yerelde doğruladı, yeniden dağıttı ve düzeltmeyi, dağıtım durumuna güvenmek yerine canlı /api/health uç noktasını doğrudan çağırarak onayladı.

Bu uç nokta çalışır durumda bir yanıt döndürdü; tüm testte uygulamanın gerçekten çalıştığını kanıtlayan tek kanıt buydu.

Bu ikinci büyük bulgu. Tamamlanmış durum, çalışan bir uygulamanın kanıtı değildir ve Connector’ın kendi günlükleri de size bunu söylemez. Kurtarmanın kendisi, bir sorun olduğunu bildikten sonra iyi çalıştı.

Bir durum rozetinin ortaya çıkaramadığı bir hatadan sonra, Connector’ın güveninin başka nerelerde gerçek yeteneğini aşabileceğini merak ettim. Sırada ortam değişkenleri testi vardı.

Ortam Değişkeni Yapılandırmasını Deneme

Asistandan zararsız bir ortam değişkeni eklemesini, dokunmadan önce bunun ayrı bir Connector özelliği olarak var olduğunu doğrulamasını ve yoksa durmasını istedim.

Mevcut araçları aradı, Node.js ortam değişkenlerini yönetmek için özel bir eylem bulamadı ve kodda veya dağıtımda herhangi bir değişiklik yapmadan durdu.

Bu, bu testin diğer her yerinde görmek istediğim davranıştır. Gerçek bir sınıra karşılaştığında, tahmin etmek yerine durdu. Hostinger Connector’ın araç setinin herhangi bir yerinde ortam değişkeni desteği olmadığını değil, yalnızca bu test sırasında böyle bir eylemin açığa çıkarılmadığını söylerim. 

Hata ve Kurtarma Testi Özeti

Bu Test Bize Güvenilirlik Hakkında Ne Söylüyor

Hostinger Connector, rutin ve deterministik görevlerde iyi performans gösterdi:

• Bilinen dağıtım kayıtlarını okuma
• Belirli bir dosyayı düzenleme
• Yerel komutları çalıştırma
• Bir projeyi paketleme
• Bilinen bir web sitesine dağıtma
• Derleme durumunu kontrol etme
• Kullanılabilir günlükleri getirme
• Bilinen iyi bir sürümü geri yükleyip yeniden dağıtma

Eksik hesap verileri arasında yorum gerektiren görevlerde daha zayıftı:

• Yeni oluşturulmuş bir web sitesini tanımlama
• Alan erişilebilirliğini web sitesi varlığından ayırma
• Tamamlanan bir derlemenin uygulamanın sağlıklı olup olmadığını belirleme

Bu desen, asistana ne kadar özerklik verileceğine karar verirken faydalıdır.

Düşük riskli inceleme için daha geniş istemler kullanın. Canlı altyapıyı değiştiren eylemler için ise kesin istemler ve açık onay gereksinimleri kullanın.

Örneğin şunun yerine:

şunu kullanın:

İkinci istem, asistanın varsayım yapabileceği alanı daraltır.

Genel Kullanım Kolaylığı Kararı

Hostinger Connector’ı çalıştırmak kolaydı; olağan kurulum sürtünmelerinin hiçbiri yoktu ve ayrıntılı araç-kategorisi kontrolleri, AI’nın neye dokunabileceği konusunda bana gerçek söz hakkı verdi.

Bir web sitesi var olup bilinen bir alan adına sahip olduğunda, işi iyi yaptı: tek satırlık bir kopya değişikliğini, editörden ayrılmadan, yaklaşık bir dakikada canlıya taşıdı; buna faydalı derleme günlükleri de eşlik etti.

Sorun daha önce ortaya çıktı, sonra değil. Bulamadığı yeni bir hedefle karşılaştığında, Connector bir alan adı uydurdu ve kontrol etmeden önce onun üzerinde işlem yaptı. Ayrıca bozuk bir dağıtımı, çalışma zamanı hatası kendi günlüklerinde hiç görünmeden “completed” olarak işaretledi. Bu sorunların hiçbiri aracı yerleşik siteler için güvenilmez yapmıyor; ancak yeni dağıtımlar ve dağıtım sonrası durum için, güvenmeden önce ikinci bir bakış gerektiği anlamına geliyor.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger Sitesini Ziyaret Edin

Destek Düzeyi

Hostinger desteğini telefon görüşmeleri yerine canlı sohbet ve kendi kendine hizmet etrafında kuruyor; bu yüzden testimi çoğu kullanıcının gerçekten karşılaşacağı yerde odakladım: hPanel’e gömülü AI asistanı, onun arkasındaki insan yükseltme mekanizması ve bir geliştiricinin sohbet açmadan önce başvuracağı bilgi tabanı.

Destek Kanalları

Canlı sohbet, Hostinger’ın acil bir şey olduğunda geliştiricileri yönlendirdiği kanal olduğundan ve bir dağıtımı hata ayıklarken gerçekten kullanılma ihtimali en yüksek yol olduğundan, e-posta talebi açmak yerine o yolu doğrudan test ettim.

Canlı Sohbet: Kodee ve İnsan Devri

hPanel’de “Ask AI” üzerinden canlı sohbeti açtım ve Kodee’ye yanlış cevap verilmesi kolay olmayan bir soru sordum: Node.js dağıtımında tamamlanan bir derleme durumu, uygulamanın gerçekten çalıştığını garanti eder mi ve bunun aksine kanıtı nerede bulurdum?

Kodee’nin ilk yanıtı belirli ve doğruydu:

“Completed” genellikle derleme aşamasının başarıyla tamamlandığı anlamına gelir; uygulamanın başlatma sonrası sağlıklı olduğunu garanti etmez. Kötü bir başlangıç komutunu veya başka bir çalışma zamanı çökmesini yakalamak için çalışma zamanı günlüklerini kontrol edin: hPanel’de Websites → Dashboard → Deployments yoluna giderek derleme günlüklerini açın ve ardından Port already in use ya da Module not found gibi başlangıç hataları için uygulamanızın nodejs  klasöründeki stderr.log  dosyasını açın.

Bu tek yanıt, daha önce bu incelemede karşılaştığım hata kurtarma testindeki belirsizliği çözebilirdi. Kodee gerçek bir günlük dosyasını, doğru klasörü adlandırdı ve derleme başarısı ile çalışma zamanı sağlığı arasındaki doğru ayrımı yaptı.

Ancak gerçekten bir insan temsilciye erişip erişemeyeceğimi de görmek istedim; bu yüzden Kodee’ye doğrudan bir destek uzmanıyla bunu doğrulamak istediğimi söyledim.

Fakat  hatta bir insanı bağlatmak beklediğimden zordu. Doğrudan canlı temsilci istedim ve iki kez tekrar Kodee’ye yönlendirildim; her seferinde bunu beklemekten daha hızlı olduğu çerçevesiyle sundu:

Bu konuda ne dediğinizi anlıyorum. Sorunu tam burada, en hızlı şekilde tespit etmemize yardımcı olmak için derleme, başlangıç komutu ve çalışma zamanı günlüklerini doğrulamanıza yardım edebilirim.

Bir uzmanı kuyruğa almadan önce. Sorunu çözebilir ve sizi beklemekten kurtarabilirim.

Kodee’nin beni bir kişiyle bağlama konusundaki isteğimi kabul etmesi için iki açık, doğrudan istek gerekti. Kendi çözebileceğim bir soru için bu sürtünme önemsizdir. Ancak ortasında kesinti yaşayan ve bir insan isteyen biri için ciddi bir hayal kırıklığıdır.

Sonraki olan şey, “canlı temsilci” ifadesinin genelde ne anlama geldiği tarzında bir canlı aktarım değildi. Kodee, gerçek modeli açıkça anlattı:

Talebinizi ekibimizden bir uzmana ilettim; uzman sohbetimizi kişisel olarak inceleyip yanıtını bana gönderecek, ben de onu burada size ileteceğim.

Bu, canlı bir aktarma değil, asenkron bir incelemedir. Kodee arayüz olarak kalır; bir insan transkripti arka planda inceler ve Kodee yanıtı geldiğinde size iletir. Bu ayrım, yükseltme yapıp yapmama kararı veren okuyucular için önemlidir; çünkü burada “insan temsilci” yeni bir kişinin canlı sohbet penceresine katılması anlamına gelmez.

Beklerken aynı teknik konuyu daha da ileri götürdüm ve Kodee’ye tam günlük yolunu ve stderr.log  dosyasının her zaman doldurulup doldurulmadığını sordum. Kendi başına sağlam bir yanıt verdi; uygulama hiç tam başlamadıysa veya hatasını başka bir yere yazdıysa günlük boş olabilir dedi.

Uzman incelemesi yaklaşık 3 dakika içinde geldi, sohbet içinde Mayas adlı bir ekip üyesine atfedildi ve Kodee’nin yanıtından daha iyisini sundu:

domains/[your-domain]/nodejs/stderr.log  doğru konumdur. Her zaman oluşturulmaz veya doldurulmaz. Orada yalnızca uygulama stderr’e yazdığında, örneğin yakalanmamış istisnalar veya işlenmemiş reddetmeler olduğunda girişler görürsünüz. Başlangıç komutu yanlışsa ve süreç sessizce çıkıyorsa, stderr.log  boş olabilir veya hiç olmayabilir.

Mayas ayrıca Kodee’nin bahsetmediği iki yedek kontrol daha ekledi: çökmeden önceki son çıktıyı görmek için stdout.log  kontrolü ve uygulamanın hiç başlamadığının işareti olarak başlangıç onay satırının eksik olup olmadığını arama.

Bilgi Bankası

Hostinger’ın bilgi bankası geniş ürün kategorileri halinde düzenlenmiştir: Getting Started, hPanel, Website Builder, Hostinger Horizons, Domains, DNS, Files Management, Email, MySQL Databases, Website, VPS, Agency Hosting Plans, Hostinger Reach, SSL Certificates, PHP, Profile Management, Billing, Affiliates and Referrals, Features, cPanel ve About Hostinger.

Bu kategorilerin hiçbiri Hostinger Connector’a özel değildir. Doğru makaleyi bulmanın tek yolu doğrudan “Hostinger Connector” araması yapmaktı; bu da çoğu yalnızca gevşek biçimde ilgili olan beş sonuç döndürdü, bunlar arasında bir affiliate marketing eklenti kılavuzu ve genel bir Node.js hosting makalesi de vardı.

Connector kurulumunu gerçekten belgeleyen makalenin başlığı “How to Set Up Web Hosting MCP on Local IDEs” ve Features → General Information altında yer alıyor.

Ürünün pazarlama adını aramak onu buldu, ancak kategorilere göz atan bir okuyucu ya da MCP’yi Hostinger’ın markalamasını bilmeden arayan biri bunu kolayca kaçırabilir; belgelerdeki ad ile pazarlamadaki ad arasındaki uyumsuzluk, aramaya geçmeden önce bilinmesi gereken bir ayrıntıdır.

Makale bulununca oldukça güçlüdür. Test ettiğimden altı gün önce güncellenmişti ve şunları kapsıyordu:

• Eklenti üzerinden önerilen tek tık OAuth kurulumu
• Eklentinin doğrudan desteklemediği IDE’ler için API token kullanan manuel kurulum yolu
• Mac, Linux ve Windows için kesin yapılandırma dosyası yolları
• Tam JSON yapılandırma örnekleri
• Bağlantının çalıştığını doğrulamak için adım adım bir doğrulama istemi
• Hangi desteklenen istemcilerin bağlantıyı otomatik algıladığı, hangilerinin manuel yapılandırma girişi gerektirdiği

Bu son nokta, test sırasında doğrudan karşılaştığım bir şeyi doğruladı: Devin Desktop otomatik algılanıyor, OpenAI Codex ise manuel yöntemi gerektiriyor. Makale bu ayrımı doğru veriyor.

Destek Hakkında Genel Karar

Kodee’nin zor bir teknik soruya verdiği ilk yanıt doğru ve spesifikti; bu her AI destek asistanının başaramadığı bir şeydir. Onu destekleyen bilgi bankası makalesi de bir kez bulduğunuzda güncel ve ayrıntılıdır; ancak ürünün pazarlama adı ile belge başlığı eşleşmiyor, bu yüzden kategorilere göz atmaktan çok arama daha güvenilir bir yoldur.

Daha zayıf nokta insan yükseltme yoludur. Kodee, bir kişi istememe rağmen beni iki kez tekrar kendisine yönlendirdi ve hatta “insan temsilci” dediğimde bile bunun yerine sohbet içinden asenkron bir inceleme oldu. Bir insan gerçekten baktığında ise cevap Kodee’ninkinden daha iyiydi; daha hassas ve Kodee’nin sunmadığı iki ek tanı adımı içeriyordu.

Çoğu soru için Kodee tek başına sizi hızlı ve doğru bir cevaba ulaştıracaktır. Ama gerçekten bir kişinin cevabı doğrulamasını istiyorsanız, birden fazla kez sormanız gerekebilir ve canlı bir konuşma yerine iletilmiş bir cevap için kısa bir bekleme süresi beklemelisiniz.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger Sitesini Ziyaret Edin

Son Karar: Hostinger Connector Kullanılmaya Değer mi?

Evet, zaten Hostinger kullanan ve rutin dağıtımları editör içinden yönetmek isteyen geliştiriciler için. Kurulum dakikalar sürdü, OAuth API anahtarı ihtiyacını ortadan kaldırdı ve bir web sitesi bir kez var olup bilinen bir alan adına sahip olduğunda Connector bir canlı güncellemeyi yaklaşık bir dakikada, günlüklerle destekleyerek gönderdi. Kodee’nin kendi desteği de gerçek bir teknik sorunu ilk denemede çözebilecek kadar güçlüydü.

Ancak mesele rahatlık değil, güvendir. Bulamadığı yeni bir hedef verildiğinde Connector bir alan adı uydurdu ve kontrol etmeden önce onun üzerinde işlem yaptı.

Ayrıca bozuk bir dağıtımı, uygulama aslında çalışmıyorken ve günlüklerinde hiçbir çalışma zamanı hatası görünmezken “completed” olarak işaretledi. Bunu yerleşik siteler için aracı güvenilmez yapacak kadar büyük bulmadım; ancak yeni hedeflerde güvenmeden önce doğrulamanız ve önemli her dağıtımdan sonra canlı siteyi kendiniz kontrol etmeniz gerektiği anlamına geliyor.

Hostinger

5.0

2,470 user reviews

80 TL /mo

Başlangıç fiyatı

Hostinger Sitesini Ziyaret Edin

Rating based on expert review

• Kullanıcı Dostu
  4.9
• Destek
  4.9
• Özellikler
  4.8
• Güvenilirlik
  4.7
• Ücretlendirme
  4.5