2026'da ConvertX Self-Hosting: Yüklemeler, JWT Secret'ları ve Kaynak Sınırları

“ConvertX çalıştırmanın” iki farklı anlamı vardır: Bir konteynerin mevcut olması veya servisin gerçek işini tamamlaması. Önemli olan yalnızca ikincisidir. Buradaki kanıt; birkaç temsili format yüklemek, her birini dönüştürmek, sonuçları indirmek ve deterministik oldukları durumlarda hash'leri veya medya özelliklerini karşılaştırmaktır.

ConvertX bu amaçla kullanılır: tarayıcı tabanlı bir dosya dönüştürme servisi. Deployment, bu davranışın arkasındaki parçaları korumalıdır; bir port, bir volume ve bir sertifika girdidir, sonuç değildir.

Uygulanabilir en küçük ConvertX topolojisini seçin

ConvertX ağ namespace'iyle başlayın: web listener'ı 3000 portudur; bir laptop tutorial'ından kopyalanmış host portu değildir. Yerel runtime gereksinimi, seçilen converter'lara uygun CPU, bellek ve geçici disk alanıdır. Bunu bir image default'u olarak bırakmak yerine beklenen kapasiteyi, sahipliği ve hata davranışını belgeleyin.

Gereksinim karşılandıktan sonra senaryonun tamamını çalıştırın — birkaç temsili format yükleyin, her birini dönüştürün, sonuçları indirin ve deterministik oldukları durumlarda hash'leri veya medya özelliklerini karşılaştırın. CPU, bellek, geçici disk, dosya boyutu ve her format çifti tarafından çağrılan converter binary'leri için log'ları ve ölçümleri kaydedin. Bu kanıt, bilinen ilk iyi mimariyi oluşturur ve Dockup compute ile bağlı bir sunucu arasındaki sonraki geçişleri test edilebilir hâle getirir.

İç ve dış URL'leri birbirinden ayırın

ConvertX için geçici ve kalıcı public origin'ler kullanmaktan kaçının. Bunun yerine UI'ı bilinçli upload limitleriyle HTTPS üzerinden yayınlayın, seçilen DNS adını platform route'una yönlendirin ve yalnızca 3000 portuna proxy uygulayın.

Bu işlemi host dışından test edin: birkaç temsili format yükleyin, her birini dönüştürün, sonuçları indirin ve deterministik oldukları durumlarda hash'leri veya medya özelliklerini karşılaştırın. Ingress başarısız olursa 502 troubleshooting guide, port ve listener hatalarını ele alır. ConvertX isteği alıyor ancak bir converter binary'si eksikse veya proxy büyük bir upload'ı reddediyorsa, kanıt artık proxy'nin ötesindeki bir soruna işaret eder.

İncelenmeye değer container ayarları

Bootstrap tamamlanana kadar route'u private bırakacak şekilde ConvertX'i başlatın.

docker run -d \
  --name convertx \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v convertx-data:/app/data \
  -e JWT_SECRET=replace-with-a-long-random-value \
  ghcr.io/c4illin/convertx:latest

Process döngüye girerse image'ın beklediği user ile mount edilen her path'in sahibi olan user'ı karşılaştırın. Çalışmaya devam ederse 3000 portunu yerel olarak test edin ve ardından doğrudan workflow'a geçin: birkaç temsili format yükleyin, her birini dönüştürün, sonuçları indirin ve deterministik oldukları durumlarda hash'leri veya medya özelliklerini karşılaştırın. Image'ı version-pin işlemini ancak bu uçtan uca kontrol başarılı olduktan sonra yapın ve kesin konfigürasyonu servisin yanında kaydedin.

Riskli ConvertX değişikliğini prova edin

Boşta çalışan bir health check, ConvertX hakkında çok az şey söyler. CPU, bellek, geçici disk, dosya boyutu ve her format çifti tarafından çağrılan converter binary'lerini izleyin; ardından kullanıcıların deneyimlediği belirti için alarm oluşturun: “birkaç temsili format yükle, her birini dönüştür, sonuçları indir ve deterministik oldukları durumlarda hash'leri veya medya özelliklerini karşılaştır” işleminin başarısız olması. Liveness'ı yerel ve düşük maliyetli tutun; readiness, restart storm'a neden olmadan migration veya initialization durumunu bildirsin.

Riskli yükseltme alanı, image release'lerinin converter ekleyip kaldırabilmesidir; bu nedenle kullanıcıların güvendiği kesin format matrisini test edin. Release notes'ları okuyun, state'in snapshot'ını alın, hedef sürümü geri yüklenmiş bir kopya üzerinde deploy edin ve kabul işlemini tekrarlayın. Bir converter binary'si eksikse veya proxy büyük bir upload'ı reddediyorsa, state'i silmek ya da gelişigüzel redirect eklemek yerine client isteğini ilk ilgili application log'uyla ilişkilendirin.

Container health'ten daha güçlü beş kontrol

ConvertX için ilk kullanıcı trafiğini acceptance test'i olarak kullanmayın. Zararsız örnek state hazırlayın ve “birkaç temsili format yükle, her birini dönüştür, sonuçları indir ve deterministik oldukları durumlarda hash'leri veya medya özelliklerini karşılaştır” işleminin tamamını çalıştırın. Çalıştırmayla ilişkili kesin public URL'yi, sonucu, image referansını ve log aralığını not edin.

Container'ı değiştirin ve data'yı yeniden oluşturmadan işlemi tekrarlayın. Ardından boş bir host üzerinde kurtarma gerçekleştirin; kurtarma koşulu, hesapların ve ayarların geri gelmesi ve sabit format matrisinin belirlenen limitler içinde hâlâ tamamlanmasıdır. Her geçişte CPU, bellek, geçici disk, dosya boyutu ve her format çifti tarafından çağrılan converter binary'lerini gözlemleyin ve idle container metrikleri yerine transaction'ın kötüleşmesi etrafında bir alarm tanımlayın.

Son bir kontrol bilerek başarısız olmalıdır: şu sınırla ilişkili kaynak veya format limitine yakın, zararsız bir input gönderin: bir converter binary'si eksik veya proxy büyük bir upload'ı reddediyor. Ortaya çıkan ConvertX mesajının veri silme ya da sonsuz restart başlatmak yerine ilgili sınırı belirttiğini doğrulayın. Geçerli koşulu geri yükleyin ve aynı örnek transaction'ın başarılı olduğunu doğrulayın. Bu kısa tatbikatı release checklist'ine ekleyin.

ConvertX'teki tüm kalıcı byte'ları bulun

Kalıcı kurtarma seti application data'sını, hesapları ve saklanan conversion ayarlarını içerir. Bootstrap'tan önce /app/data'yı mount edin, zararsız örnek data yazın ve bu path'in gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Bir volume, data'yı container değişiminden korur; ancak host kaybına, yanlışlıkla silinmeye veya application-level corruption'a karşı koruma sağlamaz.

Data source'u anlayan yedekler alın: gerektiğinde çalışan database'ler için logical dump kullanın ve dosyaları yalnızca tutarlı bir state'ten kopyalayın. Şifrelenmiş bir kopyayı ConvertX host'undan ayrı bir yerde saklayın. Restore için acceptance criterion nettir — hesaplar ve ayarlar geri gelmeli, sabit format matrisi de belirlenen limitler içinde hâlâ tamamlanmalıdır. Restore-tested backup guide, yalnızca job başarısının neden yeterli olmadığını açıklar.

ConvertX'in sahip olduğu yetkileri azaltın

İlk login'den sonra anonymous visitor'ın, normal user'ın ve administrator'ın neler yapabildiğini ayrı ayrı inceleyin. Kaçınılması gereken ConvertX hatası, örnek bir JWT secret kullanmak veya unrestricted public conversion sunmaktır. Amaçlanan policy; gerçek bir JWT secret kullanmak, login zorunluluğu getirmek ve internetten güvenilmeyen dosyaları kabul etmeden önce upload'ları sınırlandırmaktır.

JWT_SECRET'ı uzun ve rastgele bir değer olarak oluşturun; bunu değiştirmek normalde session'ları veya token'ları geçersiz kılar. Bu nedenle değişikliği encryption migration gibi ele almak yerine kullanıcı etkisini planlayın. Dependency hesaplarını insan hesaplarından ayrı tutun, mümkün olduğunda kullanılmayan egress'i engelleyin ve CPU, bellek, geçici disk, dosya boyutu ve her format çifti tarafından çağrılan converter binary'lerinin etkilediği işleri sınırlandırın.

Sınırlarını kaybetmeden ConvertX'i Dockup üzerinde deploy edin

Dockup, ConvertX çevresindeki manuel reverse-proxy ve lifecycle işlerini ortadan kaldırır. Servis, replacements sırasında 3000 portuna sabit bir HTTPS route'u, inject edilmiş konfigürasyonu ve kalıcı storage'ı alır. Bağlı bir customer server da Dockup-hosted compute ile aynı modeli izler.

Launch sonrasında application contract'ı karşılayın: UI'ı bilinçli upload limitleriyle HTTPS üzerinden yayınlayın, yerel gereksinimi doğrulayın — seçilen converter'lara uygun CPU, bellek ve geçici disk alanı — ve şu kanıtı çalıştırın: birkaç temsili format yükleyin, her birini dönüştürün, sonuçları indirin ve deterministik oldukları durumlarda hash'leri veya medya özelliklerini karşılaştırın. Bu, ConvertX'i kurtarılabilir ve güvenli kılan ayrıntıları göz ardı etmeden one-click deneyimini kullanışlı tutar.

Sık sorulan sorular

Production deployment için ConvertX'in neye ihtiyacı var?

ConvertX container'ını 3000 portu üzerinden tek bir HTTPS origin'e route edin. Yerel runtime gereksinimi, seçilen converter'lara uygun CPU, bellek ve geçici disk alanıdır. Birkaç temsili format yükleyip her birini dönüştüremeden, sonuçları indiremeyip deterministik oldukları durumlarda hash'leri veya medya özelliklerini karşılaştıramadan ConvertX'i hazır kabul etmeyin.

ConvertX'teki hangi data yedeklenmeli?

/app/data'yı kalıcı hâle getirin ve application data'sını, hesapları ve saklanan conversion ayarlarını aynı recovery manifest'ine ekleyin. Temiz bir ConvertX restore işlemi yalnızca hesaplar ve ayarlar geri geldiğinde ve sabit format matrisi belirlenen limitler içinde hâlâ tamamlandığında başarılıdır.

Reverse proxy arkasında ConvertX için HTTPS gerekir mi?

Public ConvertX origin'i için HTTPS kullanın ve 3000 portunu internal route üzerinde tutun. ConvertX ayarını doğru uygulayın: UI'ı bilinçli upload limitleriyle HTTPS üzerinden yayınlayın. ConvertX için HTTPS, credentials veya user content'in transit sırasında korunmasını ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.

ConvertX yükseltmesi nasıl test edilmeli?

Mevcut ConvertX state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Image release'leri converter ekleyip kaldırabildiğinden özellikle dikkat edin; bu nedenle kullanıcıların güvendiği kesin format matrisini test edin. Data migration ve rollback sınırı anlaşılana kadar önceki ConvertX image'ını saklayın.