Railway’den AWS’ye: ZenithW artık kendi sunucusunda
v14.1 ile ZenithW’nin backend’i Railway’den Amazon Web Services üzerindeki kendi EC2 sunucusuna taşındı. Alan adı ve arayüz yine Cloudflare’ın hızlı uç ağından geliyor; indirme, dönüştürme ve canlı ilerleme işlemleri ise artık bize ayrılmış Ubuntu sunucusunda çalışıyor.
Bu yalnızca “sunucunun adını değiştirdik” güncellemesi değil. Çalışma biçimi, ağ sınırı, servis yönetimi ve sorunları gözlemleme araçları yeniden kuruldu. Railway’in kolaylığını geride bırakırken AWS’nin kontrolünü kazandık; bunun getirdiği sorumlulukları da saklamıyoruz.
Railway’de eskiden nasıldı?
Railway, uygulamayı GitHub’dan alıp çalıştırma, servis sürecini yönetme ve altyapının büyük bölümünü gizleme konusunda çok rahattı. Küçük bir ekip için hızlı başlangıç ve az bakım büyük artıydı. Buna karşılık sunucu işletim sistemi, ağ katmanı, kalıcı servisler ve kaynak kullanımı üzerinde daha az doğrudan kontrolümüz vardı; sorun araştırırken çoğunlukla platformun sunduğu görünümle sınırlıydık.
AWS’de şimdi ne çalışıyor?
Backend artık Amazon EC2 üzerindeki t3.small Ubuntu sunucusunda çalışıyor. Gunicorn ve gevent tek çalışanlı güvenli mimariyi koruyor; systemd servisi uygulamayı gözetiyor, Nginx HTTPS ve WebSocket trafiğini uygulamaya aktarıyor. FFmpeg ve diğer yardımcı servisler aynı makinede, açıkça sınırlandırılmış kaynak ayarlarıyla çalışıyor.
Cloudflare kapıda, AWS motor odasında
Cloudflare Pages arayüzü sunmaya devam ediyor; DNS, proxy ve dış HTTPS bağlantısı da Cloudflare üzerinden geçiyor. Cloudflare ile EC2 arasındaki bağlantı Full (strict) TLS ile doğrulanıyor. Nginx yalnızca güvenilen proxy zincirinden gelen gerçek ziyaretçi IP’sini kabul ediyor; hız sınırları başlık taklidi yapan bir istemciye göre değil gerçek kullanıcıya göre uygulanıyor.
AWS’nin bize kazandırdıkları
Sunucu süreçleri, disk, bellek, ağ ve servis günlükları artık doğrudan görülebiliyor. Nginx, systemd, güvenlik duvarı, yardımcı servisler ve çalışma sınırları ihtiyaca göre ayarlanabiliyor. Ayrılmış sanal makine, platformun soyut container yaşam döngüsüne daha az bağımlı; hata ayıklama ve performans ayarı daha ölçülebilir.
dürüst tarafı: AWS’nin eksileri
Bu kontrol bedelsiz değil. İşletim sistemi güncellemeleri, güvenlik yamaları, disk takibi, servislerin yeniden başlatılması, sertifika ve ağ yapılandırması artık bizim sorumluluğumuzda. Tek EC2 örneği yüksek erişilebilirlik sağlamıyor; makine veya bölge sorunu yaşanırsa otomatik ikinci sunucu henüz yok. Ayrıca trafik az olsa bile sunucu açık kaldığı sürece sabit maliyet oluşuyor ve kapasite artırımı Railway’e göre daha fazla planlama istiyor.
neden yine de geçtik?
ZenithW’nin medya işleme yapısı uzun süren bağlantılar, FFmpeg, WebSocket ve kontrollü geçici depolama kullanıyor. Bu iş yükünde kendi Linux sunucumuzu görmek ve sınırlarını doğrudan yönetmek bizim için daha değerli hale geldi. Railway kötü olduğu için değil; ZenithW artık daha fazla altyapı kontrolüne ihtiyaç duyduğu için AWS’yi seçtik.