Cursor Build Live Apps: Neler Sunuyor, Fiyatı Ne, Sınırları Nerede?

Çalışan pek çok uygulamanın kaderi localhost'tan öteye geçememek. Cursor'ın 5 Kasım tarihli Build Live Apps duyurusu bu boşluğu kapatmayı hedefliyor: bulut ajanına ne istediğinizi anlatıyor, uygulamayı hazırlatıp bağlantı üzerinden yayımlıyorsunuz. değişiklik kaydı, dokümantasyon ve ilk kullanıcı sorularına bakınca sonuç net: Cursor SSO arkasındaki iç araçlar ve prototipler için güçlü; karmaşık ya da uyumluluk hassasiyeti olan üretim backend'leri için ise henüz yeterince olgun değil.

Build Live Apps ile neler geliyor?

Build Live Apps, doğal dilde yazılmış bir isteği yayına alınmış web uygulamasına dönüştüren bir bulut ajanı akışı. Cursor, özelliği 5 Kasım 2026'da değişiklik kaydında duyurdu. Apps dokümanlarındaki süreç de aynı: bulut ajanına komut verin, uygulamayı tepside önizleyin, bir URL seçin, güvenlik kontrollerinden geçin ve canlı bağlantıyı yayımlayın.

İstekte açık olmak gerekiyor. Cursor dokümanları, ajana özellikle build an app denmesini öneriyor. Uygulamalar Cursor Origin üzerinde sıfırdan başlayabilir; bu seçenek yeni bir depo oluşturuyor. Alternatif olarak Cursor'ın dağıtacağı mevcut bir GitHub deposu kullanılabiliyor. Uygulama oluşturabilenler yalnızca bulut ajanları.

Uygulamanın depolamaya ihtiyacı olduğunda Cursor bir PostgreSQL veritabanı sağlıyor. Barındırma, her kullanıcı veya ekip için ayrılmış ve yalıtılmış bir hosting hesabında yapılıyor. Ekip uygulamalarında kimlik doğrulama Cursor SSO üzerinden işliyor; yani alıcıların uygulamayı açmadan önce Cursor ile oturum açması gerekiyor. Bireysel plan kullanıcıları ise oturum açma gerektirmeyen herkese açık uygulamalar da yayımlayabiliyor.

İlk günden dikkate alınması gereken sınırlamalar var. GitLab desteği planlanmış olsa da henüz sunulmuyor. Özel alan adı desteği de doğrulanmış değil. Cursor, yayımlayan kişinin benzersiz bir alan adı seçtiğini; dokümanlar ise URL'nin sonradan değiştirilebildiğini söylüyor. Ancak iki kaynakta da özel alan adı bağlama akışı gösterilmiyor.

Hiçbir sayfada desteklenen framework'ler, çalışma ortamları, bölgeler, Postgres sürümü, yedekler, ölçekleme davranışı, bant genişliği kotaları veya SLA bilgisi yer almıyor. Hosting, hukuken Cursor hizmetlerinden ayrı ve "as is" ve "as available" esasına göre sağlanıyor; Cursor bir alt alan adını veya uygulamayı iptal etme ya da askıya alma hakkını saklı tutuyor.

Yayın öncesi kapı: Kapatılamayan 4 kontrol ve AI incelemesi

Kullanıcı açıkça yayımlama işlemini onaylamadan hiçbir şey canlıya çıkmıyor. Uygulamayı hazırlamak tek başına erişime açmıyor. Ekip ayrı AI incelemesini kapatsa bile, her yayınlama işleminde zorunlu olarak çalışan dört kontrol var:

• Uygulama dosyalarında API anahtarı veya erişim token'ı varsa yayını engeller.
• Özel anahtarlar ya da hizmet hesabı anahtarları gibi kimlik bilgisi dosyalarını engeller.
• .env dosyalarını yayımlanan paketin dışında bırakır.
• Ziyaretçilerin tarayıcı üzerinden özgün kaynak kodu yeniden oluşturmasını önlemek için source map'leri kaldırır.

Bir kontrol başarısız olursa Cursor sorunu listeliyor; kullanıcı ajandan düzeltmesini isteyip yeniden deneyebiliyor.

Ek AI güvenlik incelemesi uygulama dosyalarını okuyor ve ciddi sorunları yayın öncesinde engelleyebiliyor. Ekip yöneticileri bu incelemenin istemine kuruma özel talimatlar ekleyebiliyor. Özel talimatlar yeni kurallar koyabiliyor, fakat Cursor'ın yerleşik kontrollerini kaldıramıyor veya zayıflatamıyor. Yöneticiler bazı yayın engellerini geçersiz kılabiliyor; ancak kötü amaçlı kod, sabit kodlanmış gizli bilgiler veya açığa çıkmış kimlik bilgileriyle ilgili engelleri geçersiz kılamıyor. Bu ayarlardaki değişiklikler ekip denetim günlüğüne işleniyor.

Bu kapının neyi yakaladığından çok, neyi garanti etmediği önemli:

"The catch: passing security checks doesn't prove your app gives the right people the right access." — @0node0, gerçek kullanıcı

Cursor, örnek olarak gizli bilgileri ve açığa çıkmış kimlik bilgilerini anıyor. Ancak her uygulamanın yetkilendirme testinden, satır düzeyinde izin testinden, SQL injection kapsamından, bağımlılık taramasından veya iş mantığı incelemesinden geçtiğini söylemiyor. TechRepublic'in 6 Kasım tarihli analizi de aynı noktaya dikkat çekiyor: farklı izin seviyelerindeki birden fazla hesapla test yapın; çünkü oturum açmış bir kullanıcının başka bir kullanıcının kayıtlarını okuyabilmesinin bu kontroller kapsamında olduğu gösterilmiyor.

Kullanıcıların üç temel sorusu: ücret, Vercel ve gizli bilgiler

Hosting için ayrıca ücret ödeniyor mu? Cursor, hosting veya veritabanı için ayrı bir fiyat açıklamadı. Build Live Apps'ın bağımsız bir aboneliği de yok. Özellik, bulut ajanı erişimi sunan ücretli planlara dahil. Eldeki somut rakamlar Cursor'ın özellik sayfalarından değil, TechRepublic'in plan tablosundan geliyor:

Cursor ortak bir haftalık AI kullanım kotası kullanıyor (TechRepublic'in plan dökümü), ancak Cursor bu sayfalarda plan başına token, istek veya işlem gücü rakamı yayımlamıyor. Üçüncü taraf modeller ayrı ücret doğurabilir (TechRepublic). Veritabanı, depolama, trafik ve eşzamanlılık sınırları da açıklanmamış. Bu nedenle $30 alt sınırını toplam işletme maliyeti değil, giriş bileti olarak görün; müşteriye açık bir iş yükünü yerleşik hostinge taşımadan önce kotaları doğrulayın.

Build Live Apps, Vercel'in yerini alır mı? Karmaşık veya uyumluluk hassasiyeti bulunan üretim backend'leri için henüz hayır. Yerleşik akış; Postgres, SSO ve paylaşılabilir bağlantı ihtiyacına uygun. GitHub'dan Vercel, Netlify, Railway, Render veya VPS'e uzanan geleneksel yol ise özel mimariler ve regülasyona tabi veriler için hâlâ daha uygun; aşağıdaki tablo senaryolara göre ayrımı detaylandırıyor. Reddit'teki hosting başlıkları aynı sınıflandırmaya dönüp duruyor: iş yükünün ne kadar stateful veya uzun süreli olduğu, hosting seçimini belirliyor.

"Most cursor demos I see on my timeline are focused on the UI… most aren't deployed to live paying users." — @mayowaoshin, gerçek kullanıcı

Gizli bilgiler nerede tutuluyor, ajan bunları görebiliyor mu? Cursor dokümanları, kodlama ajanının gizli bilgi değerlerini hiçbir zaman görmediğini belirtiyor. Veri ambarına veya harici API'ye ihtiyaç duyan uygulamalar, kullanıcıdan gizli bilgileri istiyor. Ekip gizli bilgileri normalde ekip yöneticisi tarafından Apps panosundan oluşturuluyor veya aynı panel üzerinden sonradan ekleniyor.

Ekip yöneticileri her ekip uygulamasını ve her ekip gizli bilgisini görebiliyor. Bu hem bir yönetişim imkânı hem de üretim anahtarlarını yapıştırmadan önce anlaşılması gereken bir güven sınırı. Script'ler, CI işleri ve Grok Bot gibi otomatik istemciler korumalı uygulamalara çerez ya da sorgu parametresiyle değil, başlık tabanlı bir anahtarla (x-cursor-app-token) erişiyor.

Hangi senaryoda Live Apps, hangi senaryoda klasik dağıtım?

Elbette geleneksel yolun da kendi kurulum yükü var: MCP yapılandırması, hosting kimlik bilgileri, ortam değişkenleri ve RLS sertleştirmesi. Bir geliştiricinin landing page'den Vercel'e, oradan Supabase auth'a uzanan dört haftalık süreci bunu gösteriyor.

Paylaşmadan önce: üretime hazırlık kontrol listesi

Cursor'ın kontrolleri sızan gizli bilgileri ve kimlik bilgisi dosyalarını yakalıyor. Geriye izinler, ortam yapılandırması, asenkron yan etkiler ve kimsenin okumadığı kod gibi riskler kalıyor. İç araç olsa bile ilk paylaşım öncesinde bu listeyi uygulayın.

1. Temiz ortamdan build alın, ardından diff'i okuyun. Ajanın geliştirme sunucusunu değil, gerçek üretim build'ini çalıştırmasını isteyin. Ödeme, kimlik doğrulama ve veri yazma işlemleriyle ilgili her değiştirilmiş dosyayı açın. Proje artık diff'in incelenemeyeceği kadar şiştiyse, karmaşanın üstüne yeni istemler yazmak yerine bir checkpoint'e dönün ve işi parçalara ayırın.
2. İzinleri iki hesapla test edin. Yönetici ve kısıtlı üye olarak oturum açın. A kullanıcısıyla kayıt oluşturun; ardından B kullanıcısı olarak bu kaydı okumayı, düzenlemeyi ve silmeyi deneyin. Güvenlik raporunun başarılı olması, satır sahipliğinin doğru olduğuna dair kanıt değildir.
3. Gizli bilgileri uçtan uca denetleyin. Hiçbir anahtarın frontend koduna paketlenmediğini, hiçbir .env dosyasının gönderilmediğini ve her harici kimlik bilgisinin çalışmaya yetecek en dar kapsama sahip olduğunu doğrulayın. Üretim veritabanının doğrudan URL'lerini ajanın erişebileceği ortamdan kaldırın. Bir r/cursor paylaşımı, Cursor'ın GitHub üzerinden geçmek yerine doğrudan üretim Supabase ortamına dağıtım yaptığını anlatıyor.
4. Asenkron akışları zorlayın. Gerçek bir webhook tetikleyin, yeniden deneyin ve işlem ortasındayken sonlandırın. Eşzamanlı kullanım altında bağlantı havuzunun davranışını kontrol edin. Kullanıcıların ancak yayından sonra fark ettiğini bildirdiği sorunlar arasında sessiz webhook hataları ve tükenen havuzlar var.
5. Güncelleme ve geri alma sürecini tanımlayın. Kimin yayın yapabileceğini, engellenen yayını kimin geçersiz kılabileceğini, kimin yayından kaldırabileceğini ve denetim günlüğünün nereye gittiğini doğrulayın. Hatalı bir yayının nasıl geri alınacağını ve şema migration'ının nasıl çalışacağını kaydedin; çünkü dokümanlar yayınlamayı anlatıyor, sürüm geçmişini veya geri alma mekanizmasını değil.

"Once an app leaves localhost, its secrets come with it." — @1PasswordDev, uygulama başına gizli bilgi yalıtımı hakkında gerçek kullanıcı

Yukarıdaki adımlardan herhangi birinin yanıtı yoksa — örneğin staging projesi, ikinci test hesabı veya geri alma planı bulunmuyorsa — uygulamayı ekip içi bağlantıda ya da bunlar çözülene kadar geleneksel stack üzerinde tutun.

Sık sorulan sorular

Build Live Apps için ücretli Cursor planı gerekiyor mu?

Evet. Build Live Apps yalnızca bulut ajanları etkin olan ücretli planlarda çalışıyor. $8/ay fiyatlı Plus uygun değil. $30/ay fiyatlı Premium, uygun en düşük bireysel plan.

Cursor, mevcut depomdan uygulama oluşturabilir mi?

Evet; mevcut bir GitHub deposundan veya Cursor Origin üzerinde sıfırdan başlayabilir. GitLab planlanmış olsa da kullanıma açık değil ve yerel ajanlar uygulama oluşturamıyor.

Ekip uygulaması herkese açık olabilir mi?

Team ve Enterprise planlarında herkese açık paylaşım varsayılan olarak kapalı. Bir yönetici bunu Apps panosundan etkinleştirebilir. Bireysel planlar herkese açık uygulamaları doğrudan yayımlayabilir.

Cursor özel alan adlarını destekliyor mu?

Cursor, yayımlayan kişinin benzersiz bir alan adı seçtiğini ve bunu sonradan değiştirebildiğini söylüyor; fakat ne değişiklik kaydı ne de dokümanlar özel alan adı eşlemesini doğruluyor. Cursor aksi yönde dokümantasyon yayımlayana kadar Cursor tarafından yönetilen bir URL varsayın.

Script'ler veya bot'lar özel bir uygulamaya nasıl erişir?

Bir Cursor API anahtarı oluşturun ve bunu her istekte x-cursor-app-token başlığı olarak gönderin. Kişisel anahtarlar, sahibinin açabildiği her şeyi açar. Ekip anahtarları ise yalnızca açıkça izin verilmiş ekip uygulamalarını açar.

Bir uygulamayı yayından kaldırdıktan sonra ne olur?

Yöneticiler herhangi bir ekip uygulamasını yayından kaldırabilir; herkese açık uygulamaları devre dışı bırakmak da mevcut herkese açık uygulamaları yalnızca ekip görünürlüğüne döndürür. Cursor, yayından kaldırma sonrasında veri saklama, yedekleme veya dışa aktarma davranışını dokümante etmiyor.

Build Live Apps, çalışan bir prototiple kullanılabilir bir bağlantı arasındaki hosting kurulum yükünü azaltıyor. Ancak sonucu başka kişilerin güvenle kullanıp kullanamayacağını belirleyen kod incelemesi, izin testi ve sahiplik çalışmalarını ortadan kaldırmıyor.

İlgili okumalar: Best LLM for Coding Agents 2026 · Cursor Projects Beta Review · Cursor Router Explained