Wafrn'i Paylaşımlı Altyapıda Çalıştırmak: Caddy ile Çok Hizmetli Hosting Rehberi

Hayal: Bir Yazı, Birçok Platform

Fedverse'in cazibesini anlıyoruz. Tek bir yazı yayınlayıp BlueSky, Mastodon, Lemmy ve diğer merkeziyetsiz platformlarda aynı anda tüm takipçilerinize ulaşmak. Wafrn tam da bunu vaat ediyor—karmaşık paylaşım işlemlerini yönetecek birleşik bir yayın panosu. Ancak birçok güçlü açık kaynak aracı gibi, Wafrn da gerçek dünya hosting senaryolarıyla her zaman uyumlu olmayan varsayımlarla tasarlanmış.

Ama işte mesele burada: Wafrn varsayılan kurulumu tek kiracı modeline dayanıyor. Ayrı bir sunucu ayarla, Docker konteynerini çalıştır, Caddy'ye işini yap diyorsun. Oysa paylaşımlı bir VPS'de WordPress, birkaç mikro servis veya eski uygulamalar barındıran geliştiriciler için bu tümü-ya-da-hiçbirini yaklaşımı ciddi sorunlar yaratıyor.

Standart Yol (Neden Başarısız Olur)

Wafrn'in resmi kurulum talimatı kağıt üstünde oldukça basit görünüyor:

1. İçinde Caddy reverse proxy bulunan Docker konteyneri
2. Let's Encrypt üzerinden otomatik HTTPS sertifikası
3. ATProto hesap desteği (BlueSky federasyonu için gerekli)

Sorun ortaya çıkıyor: elinizde zaten etkinleştirilmiş bir Nginx veya başka bir web sunucusu varsa. Mimari çatışma burada başlıyor: Wafrn, ATProto hesap doğrulaması için Caddy'nin otomatik HTTPS sertifikasına dayanır. Bu sadece estetik bir şey değil—protokol tarafından gerekli kılınır. ActivityPub ve ATProto belirtimleri, federasyon isteklerini yapan tarafın sertifika sahipliği yoluyla alana hakimiyet gösterip göstermediğini kontrol eder.

443 portunda zaten dinleyen bir web sunucunuz varsa, yanına başka bir tane ekleyemezsiniz. Port çatışmasından öte, aynı alan adının SSL zincirini kontrol etmek için bir başka hizmet daha istediğinde sertifika yönetimi kabus haline gelir.

Pratik Çözüm: Caddy'yi Yardımcı Proxy Olarak Kullan

Mevcut web altyapınızı değiştirmek yerine, Caddy ve Wafrn'i birincil reverse proxy'nizin arkasında çalışan yalıtılmış bir hizmet olarak ayarla.

Mimari şöyle görünür:

İstemci (BlueSky, Mastodon vb.)
    ↓
Alan Adınız (nginx/reverse proxy :443'te)
    ↓
İç Ağ
    ↓
Caddy + Wafrn (ATProto sertifika doğrulaması)

Akış bu şekilde işliyor:

1. Dış trafik birincil web sunucunuza alan adınızdan giriyor
2. Birincil reverse proxy Wafrn'e özgü rotaları (örneğin /wafrn/*) iç ağda Caddy örneğine yönlendiriyor
3. Caddy kendi sertifika zincirini yönetiyor — ATProto doğrulaması için alt alan adlar veya token tabanlı yöntemler aracılığıyla
4. Wafrn federasyonu tam uyum sağlayarak gerçekleştiriyor

Bu yöntem mevcut altyapınızı koruyor, Wafrn'in özzel gereksinimlerini ise ayırt ediyor.

Nginx'ten Caddy'ye Geçiş: Yapay Zeka Ne Zaman Yardımcı, Ne Zaman Zararlı?

Birincil reverse proxy'nizi Nginx'ten Caddy'ye taşımaya karar verirsen—makul bir basitleştirme—yapay zeka destekli kod dönüştürme araçları süreci hızlandırabiliyor. Tipik bir Nginx ayarını Caddyfile söz dizimine çevirmek yeterince mekaniksel bir işlem olduğundan, AI bu işi tek seferde iyi yapıyor.

Fakat bu melezleştirilmiş kurulumda Wafrn'i yapılandırmak—AI araçlarının zorluk çektiği alan bilgisi gerektiriyor:

• ATProto'nun sertifika sabitleme (certificate pinning) gereksinimlerini anlamak
• Wafrn'in hangi ortam değişkenlerinin proxy davranışını kontrol ettiğini bilmek
• Yapılandırma biraz yanlış gittiğinde federasyon arızalarının hatasını ayıklamak
• AI'ın önerilerinin güvenlik açığı yarattığını fark etmek

Pratik ders: Yapay zeka araçlarını direkt dönüşümler (Nginx → Caddy) için kullan, ama yeni mimari değişiklikleri önerileri başlangıç noktası olarak gör, dinin gibi değil. Özellikle kenar durumlarında, AI üretimi yapılandırmaları hata ayıklama için kendinden yazma kadar zaman harcayabilirsin.

Kendini Yap: Senin Kurulumun için Dökümantasyon

Eğer bunu zaten yapılandırdıysan, Wafrn'in dökümantasyonunun nerede fazla varsayımda bulunduğunu ve gerçek hosting dünyasının nerde standart yoldan ayrıldığını biliyorsundur. Topluluk bu boşlukları belgelemenin faydasını görecek.

Yapılandırmanı yayınla—güncellenmiş talimatlı bir fork, ayrı bir rehber, veya halk tarafından bakılan deployment şablonu olarak. Bu, sonraki geliştiriciyi 2-3 saatlik deneme-yanılmadan kurtarır. Wafrn'in resmi dokümantasyonuna katkı yapıp GitHub/GitLab'de herkese açık bir referans yapılandırması yayınlamayı düşün.

Wafrn Self-Hosting için Ana Noktalar

1. Protokol gereksinimlerini anla: ATProto federasyonu isteğe bağlı değildir—alan adına bağlı geçerli sertifikalar gerektirir.

2. Varsayılan kurulumun kendi altyapına uyacağını kabul etme: Ayrılmış sunucular daha basittir, ama paylaşımlı hosting daha uygun ve yaygındır.

3. Caddy'yi yardımcı hizmet olarak çalıştır: Birincil web sunucundan ayrı tut, Wafrn'in özel ihtiyaçlarını yerine getirmesini sağla.

4. Yapılandırmaları dönüştür, otomatik yapılandırma yapma: Biçim çevirmeleri için AI'dan yardım al, altyapı tasarımı için değil.

5. Çözümünü belge ve paylaş: Başkaları faydalanacak, gelecek projeler için bir referansın olacak.

Sırada Ne Var?

Benzer bir kurulum çalıştırıyorsan—paylaşımlı VPS'de birçok hizmet, özel protokol gereksinimli—Wafrn mimarisini bir şablon olarak düşün. Aynı düzen, sertifika kontrolü gerektiren diğer federasyon farkında uygulamalar için de işe yarar: proxy katmanını ayır, TLS yönetimini kendi kendine yaptır, ve birincil reverse proxy üzerinden köprüle.

Benzer bir kurulum yapıyorsan, kendini barındıran cross-posting araçlarının alternatiflerini keşfetmek mi yoksa ATProto ve ActivityPub federasyonuna derinlemesine inmek mi istiyorsun? Yorumlara yazabilirsin, iyi self-hosting'ler.

Karmaşık uygulamaları kendini barındırmak ağ, SSL/TLS ve protokol uyumluluğuna dikkat gerektirir. Çoklu hizmet altyapıları barındıran geliştiricilerin ve küçük ekiplerin yanında güvenilir domain yönetimi ve merkeziyetsiz protokollerle iyi oynaşan DNS sağlamıyla yer alırız. Wafrn, Mastodon veya özel federasyon uygulaması çalıştırıyorsan, sağlam domain altyapısı temeli oluşturur.