Vercel'de Python ve daemon, Fly ve Supabase'te MCP: backend ne zaman kendi sunucuda daha iyi

Vercel, 15 Ekim'deki Vercel Ship konferansında Python'un kendi platformunda genel kullanıma açıldığını, konteynerlerin fonksiyon gibi çalıştığını ve arka plan worker'ları için daemon'ların geldiğini duyurdu. Aynı hafta Fly.io kendi MCP sunucusunu gösterdi, Supabase de uygulamanıza kendi MCP sunucusunu nasıl vereceğinizi anlattı. Haberlerin ortak anlamı şu: platformlar bütün backend'in kendilerinde yaşamasını ve onu bir ajanın yönetmesini istiyor. İşletme sahibi için soru başka: sistem nerede duracak, ayda kaça mal olacak ve tarife değişince ne olacak.

Ne duyurdular

Vercel 15 Ekim'de blogunda Vercel'de backend'leri: Python, konteynerler ve daemon'lar anlattı. Kendi rakamlarına göre Vercel'de Python backend'lerini 150.000 ekip çalıştırıyor, konteyner betası boyunca da 5.000 ekip 150.000 dağıtım yaptı. Konteynerler Fluid compute üzerinde, Active CPU tarifesiyle fonksiyon gibi çalışıyor: veritabanından ya da modelden cevap beklemek ücretlendirilmiyor. Örnekte Delphi şirketi Python backend'ini AWS ECS'ten taşımış: altyapıya bakan ayrı biri olmadan on mühendis ve günde 100'den fazla yayın.

Aynı gün Vercel Python'un Vercel'de genel kullanıma açıldığını duyurdu: platform FastAPI, Flask ve Django'yu kendisi tanıyor, kuyruklar, depolama ve modeller için Python SDK veriyor. Yine aynı gün Vercel Daemons açık betaya çıktı: sürekli çalışan ve işi Vercel kuyruğundan, Celery, BullMQ, RabbitMQ, Kafka'dan ya da veritabanından kendisi alan konteynerler.

21 Ekim'de Vercel Python'da yönlendirme middleware'i ekledi: ana uygulamadan önce çalışıyor, isteği yeniden yazabiliyor ya da başka yere yönlendirebiliyor. 23 Ekim'de ise CLI'a harcama yönetimi geldi: vercel budgets komutu harcamaları ve bütçeyi gösteriyor, --pause bayrağı da harcama %100'e ulaşınca bütün projelerin production dağıtımlarını durduruyor.

Fly.io 23 Ekim'de Fly MCP Server'ı tanıttı: ajanın hem Sprites sandbox'larıyla hem de canlı Fly Machines ile çalıştığı tek bir MCP sunucusu. Sprite kendi diski olan bir Linux makinesi; onu Machine'e taşımak, bir Linux servisini iki Linux makinesi arasında taşımaya benziyor. Notta Databricks'in Neon telemetrisi raporundan bir rakam var: Ekim 2023'te veritabanlarının %0,1'ini ajanlar oluşturuyordu, Ekim 2025'te ise %80'ini.

Supabase 22 Ekim'de uygulamaya kendi MCP sunucusunun nasıl verileceğini gösterdi. Uygulamanızın müşterisi ChatGPT ya da Claude'dan kendi hesabıyla giriyor, her araç çağrısı onun adına çalışıyor ve neye izni olduğuna Postgres'teki RLS politikaları karar veriyor. Bu kısmı beğeniyorum: yetkiler uygulamadakiyle aynı ve hiçbir servis anahtarı yok.

Örnek: üretim ve ay sonu faturası

Bir üretim şirketi siparişleri hesaplıyor: program, tasarım dokümantasyonunun durduğu ağ klasörlerine VPN üzerinden SMB ile giriyor, malzemeleri 1C'deki stok kartlarıyla karşılaştırıyor ve dosyaları lazer için yeniden adlandırıyor. Anlatılan platformların hiçbiri bunu yapamaz: backend'in şirket ağının içinde durması gerekiyor.

Duraklatmalı bütçe yararlı bir düğme, ama ne yaptığına bakın: %100'de production dağıtımları duruyor. Bir hizmet şirketi için bu, reklamın her zamankinden fazla kişi getirdiği gün başvuru formlu sitenin durması demek. Kendi sunucunuzda fatura her ay aynı, yükteki sıçramayı da log'larda görürsünüz.

Bende nasıl çalışıyor

kononov.dev sitesi ve şirket içi bir servis olan “Birlikte Kahve”, 2 GB bellekli tek bir sunucuda, Docker'da, Nginx arkasında duruyor. Konteynerlerin katı bellek limitleri var. Güncellemede eski kopya, yenisi başlamadan önce durduruluyor; derlemeye bellek yetmezse imajı sunucu dışında derleyip hazır halde yüklüyorum. “Birlikte Kahve” ayrıca Cloudflare Workers runtime'ı için yazıldı ve Docker volume'daki yerel SQLite üzerinde D1 API ile çalışıyor: kendi donanımımda bir platform runtime'ı, üstelik ücretsiz araçlarla.

Güney Afrika'daki araç kiralama şirketine kendi sunucusunu kurmayı önerdim, çünkü rezervasyon ve teslim mantığı AmoCRM ayarlarını aşmıştı. Fikir desteklendi ve 2025 boyunca sistem entegrasyonlardan tam rezervasyon döngüsü olan bir siteye, yöneticiler için bir uygulamaya ve bir belge zincirine dönüştü. Her durumda kod, veritabanı, sunucu ve erişimler müşteriye ait.

Platform her değişiklik için önizleme ve kadroda sistem yöneticisi olmadan tek tuşla geri alma sağlıyor. Delphi'deki gibi günde yüz yayın yapan on mühendislik bir ekip için bu mantıklı. Vercel Daemons'ı, Fly MCP'yi ve Supabase'in MCP bölümünü kendimde kurmadım, açıklamalarına göre değerlendiriyorum.

Ben ne yapardım

Bir yıl ilerisini hesaplayın: platform tarifesi artı Active CPU artı daemon'lar, karşısında da sunucu kirası artı bakım saatleri. Tek seferlik geliştirmeler bende saatte yaklaşık 80 dolar, sürekli bakım ayrı bir anlaşmayla yapılıyor; bu hesapta sunucuya giden saatleri dürüstçe saymak gerekiyor.

Backend'in, platformun vermediği neye ihtiyacı olduğunu yazın: yerel ağa VPN, SMB, telefon sistemi, durum tutan uzun süreçler.

Dockerfile'ı platform ve kendi sunucunuz için aynı tutun.

Kendi uygulamanıza MCP erişimini Supabase'in yolundan kurun: çağrılar kullanıcı adına ve uygulamadakiyle aynı yetki kontrolleriyle. 2023'te Londra'daki bir danışmanlık şirketi için modelin fonksiyon çağırmasıyla deneyler yaptım; bugün ortaya çıkana bir MCP sunucusunun prototipi derdim.

Durumu tutan ve süreci yürüten sistem merkezi hakkında sistemin çekirdeği olarak sunucu yazısı var. Bu incelemedeki projeler: “Birlikte Kahve” ve Güney Afrika'da araç kiralama. Kod ve sunucunun kime ait olduğunu basitçe dijital egemenlik incelemesinde ele alıyorum, Docker Compose ile Kubernetes karşılaştırması burada, gerçek zamanlı veri WebSocket incelemesinde, şema migration'ları Supabase dalları ve D1 incelemesinde. Ağır raporu ve çalışan veritabanını daha önce birbirinden ayırmıştım. Hizmet alanları: altyapı ve DevOps ve senaryonuza göre uygulama. Backend'in nerede yaşayacağını seçiyorsanız ne yapması gerektiğini yazın, ben olsam neyi seçerdim söyleyeyim. Görevi konuşalım.