Vercel Python genel kullanımda, Daemons açık betada

Vercel, San Francisco’daki Vercel Ship etkinliğinde Python arka uçlarını genel kullanıma açtı; şirketin 15 Ekim 2026 tarihli duyurusu, özel container desteğini ve sürekli çalışan arka plan işçileri için Vercel Daemons’ı açık beta kapsamında tanıtıyor. Python ile HTTP isteğine yanıt veren bir servis ve kuyruktan iş çeken bir süreç artık aynı platformda yer alabiliyor. Ancak Python desteğinin genel kullanıma çıkması, Daemons işçisinin de aynı yayın statüsüne ulaştığı anlamına gelmiyor.

Originbrief’in 19 Ekim 2026 değerlendirmesi, Vercel Ship duyurusunu ön yüz dağıtımından tam yığın uygulama çalıştırmaya doğru bir genişleme olarak ele alıyor ve Python arka uçlarını kullanan 150 bin ekip ile açık betadaki container desteği üzerinden 150 bin dağıtım yapan 5 bin ekibe ilişkin Vercel verilerini aktarıyor. Bunlar şirketin bildirdiği kullanım sayıları; bir API’nin, container içinde çalışan HTTP servisinin ve Daemons işçisinin üretimde aynı şekilde davranacağını göstermiyor.

Python genel kullanımda; container ve Daemons açık betada

Yeni kapsamın ayrımı programlama dilinden çok sürecin nasıl başladığında görülüyor. Python desteği FastAPI, Flask ve Django gibi çatıların standart CPython ve PyPI bağımlılıklarıyla çalışmasını kapsıyor. Vercel çatı tanımayı ve derlemeyi üstleniyor; HTTP isteğine yanıt veren uygulama Fluid Compute üzerinde trafiğe göre ölçekleniyor.

Genel kullanım — Python on Vercel: İstek alan Python uygulamaları yerel geliştirme, preview ve production dağıtımlarında çalışabiliyor. Ön yüz ile Python arka ucu Vercel Services aracılığıyla aynı proje içinde dağıtılabiliyor.
Açık beta — container desteği: Özel çalışma ortamı, sistem kitaplığı veya yürütülebilir dosya gerektiren HTTP uygulaması bir container ile Vercel Functions üzerinde çalıştırılabiliyor. Bu modelde kapasite gelen isteklere göre değişiyor.
Açık beta — Vercel Daemons: Container içindeki süreç, kuyruk veya veritabanı gibi bir sistemden işi kendisi çekerek çalışmaya devam ediyor. Ekip bölge başına örnek sayısını belirliyor; süreç kapanır veya çökerse Vercel örneği yeniden başlatıyor.

Bu statüler aynı projenin parçalarına farklı biçimde uygulanıyor. FastAPI ile yazılmış bir HTTP uç noktası genel kullanımdaki Python desteğinden yararlanırken onunla birlikte çalışan Celery tüketicisi Daemons’ın beta koşullarına bağlı kalıyor. Container da tek başına sürekli çalışan işçi demek değil: HTTP için kullanılan container bir Function olarak istek alıyor, Daemon ise işi dış sistemden çekiyor.

HTTP servisi ile kuyruk işçisi nasıl ayrılıyor?

Vercel Daemons örneğinde Python API’sinden ayrılan video işleme görevi, oynatma kopyası ve önizleme görseli üretiyor.

FastAPI veya Flask uygulamasının görevi isteği alıp yanıt üretmekse uygun yürütme modeli Vercel Functions ya da Services kapsamındaki HTTP servisidir. Uygulama özel sistem bağımlılıkları gerektiriyorsa container bu servisin paketleme biçimi olabilir. Örneğin HTTP çağrısıyla başlayan bir dönüştürme işleminin ilk aşaması, isteği doğrulayıp işi kuyruğa bırakmakla sınırlı tutulabilir.

Celery gibi bir işçi ise kullanıcıdan doğrudan istek beklemek yerine kendi döngüsünde yeni görevleri alır. Vercel Daemons’ın çekme temelli modeli kuyruk tüketicisine, bekleyen işleri veritabanından alan sürece veya harici bir sistemdeki görevi yoklayan işçiye uyuyor. Daemon gelen HTTP trafiğinin hedefi olarak çalışmadığı için aynı uygulamadaki API ile işçinin sorumlulukları ayrılıyor: API işi başlatıyor, işçi işi alıp tamamlıyor.

Bu ayrım kapasite planını da değiştiriyor. HTTP servisi gelen trafiğe göre ölçeklenirken Daemon için çalışacak örnek sayısını ekip belirliyor. Kuyruk boşken işçi yine çalışır durumda kalıyor; işler biriktiğinde de yeni örnek sayısı kendiliğinden artmıyor. Bu nedenle aynı Python kod tabanında yer almak, API ile tüketicinin aynı ölçekleme ve maliyet davranışına sahip olduğu anlamına gelmiyor.

Video işleme örneğinde hangi parça ne yapıyor?

Vercel Daemons işçisi dağıtım sırasında yeniden başladığında, tamamlanmamış kuyruk işi güvenli biçimde yeniden işlenmeyi bekliyor.

Bir video uygulaması bu modellerin birlikte kullanılmasını somutlaştırıyor. Kullanıcı klip yüklediğinde Python API işi kuyruğa gönderebilir; ayrı bir container içindeki Python süreci ise ffmpeg ile oynatma kopyası ve küçük önizleme görseli hazırlayabilir. Uzun süren işlem HTTP yanıtına bağlı kalmadığında kullanıcı isteği ile video dönüştürme işinin yaşam döngüleri ayrılmış olur.

Daemons bu örnekte container içindeki işlemciyi çalışır tutar ve işçinin Vercel Queues’dan yeni görevleri çekmesini sağlar. Container, ffmpeg gibi sistem aracını uygulamanın bağımlılıklarıyla birlikte taşır; Daemon ise sürecin sürekli çalışma biçimini tanımlar. Başka bir deyişle, paketleme tercihi ile yürütme modeli iki ayrı karardır. Aynı container yaklaşımı HTTP alan özel bir servis için de kullanılabilir, fakat o servis kuyruğu yoklayan bir Daemon gibi davranmaz.

Daemons işçisinin üretimdeki sınırları

Vercel’in Daemons rehberi, açık beta sırasında işçilerin yalnızca production dağıtımında başladığını, preview dağıtımlarında ve vercel dev içinde çalışmadığını, otomatik ölçeklenmediğini ve kapanışta SIGTERM sinyalinden sonra varsayılan olarak 10 saniye tanındığını belirtiyor. Rehbere göre Hobby planındaki Daemons kullanım hakkı ekip genelinde ayda 10 vCPU-saat; hak dolduğunda işçiler duruyor. Bu sınırlar, sürekli çalışması beklenen bir tüketicinin geliştirme ve işletme koşullarını HTTP servisinden ayırıyor.

Yeni production dağıtımı başladığında önceki sürümün işçileri durduruluyor. Kapanış anında bir video dönüştürme veya Celery görevi sürüyorsa süreç tamamlanmadan kesilebilir; yeniden başlayan işçi aynı görevi tekrar alabilir. Bu nedenle kuyruk mesajını yalnızca başarılı işlemden sonra onaylamak ve tekrar gelen görevin yan etkilerini güvenle ele almak, işin doğruluğunu belirleyen uygulama kararlarıdır. Sürecin yeniden başlatılması, yarım kalmış bir görevin sonucunu kendiliğinden düzeltmez.

Örnek sayısı bölge bazında yapılandırılabiliyor ve panelden yapılan kapasite değişikliği sonraki dağıtımlarda da geçerli kalabiliyor. Bu, yoğun saatlerde kuyruk birikimini yönetmek için ekip müdahalesi gerektirebilir; sakin saatlerde ise ayrılmış işçi kapasitesi çalışmayı sürdürür. Preview ortamında Daemon başlamadığı için API ile işçinin birlikte davranışı yerel container çalıştırmasıyla sınanabilir, ancak dağıtım değişimindeki durdurma ve yeniden başlatma etkisi production akışında önem kazanır. Python servisinin genel kullanım statüsü bu beta sınırlarını ortadan kaldırmıyor.

Ayrıca okuyun: