Cursor 2026'da editör satırından altyapı satırına doğru gözle görülür bir eksen kayması yaşıyor: Mart ayında self-hosted cloud agent'larla başlayan hat, Ağustos'ta repo'suz başlangıçla (Start from scratch + Origin) ve Eylül'de pool'larla genişleyen self-hosted machines'le (Cursor cloud agents self-hosted) olgun bir platforma dönüştü. Bu yazı üç parçayı — Origin, self-hosted machines ve team pools — tek bir karar çerçevesinde birleştiriyor: ne zaman yönetilen buluta güvenmeli, ne zaman kodu kendi ağında tutmalı, ne zaman da takım ölçeğinde paylaşımlı bir kapasite kurmalısın.
💡 Pro Tip: Self-hosted machines'i "gizli tünel" gibi düşünme — worker, Cursor'a doğru outbound HTTPS bağlantısı açar; içeri açılan bir port yoktur, bu da NAT arkasındaki ya da sıkı perimeter kuralına bağlı ağlarda bile çalışmasını mümkün kılar.
İçindekiler
- Cursor'ın ekseni neden editörden altyapıya kaydı
- Mart'tan Eylül'e: self-hosted cloud agent'ların kısa tarihi
- Cloud Agents ve repo'suz başlangıç: Start from scratch ve Origin
- Origin repo nasıl çalışır, sınırları neler
- Self-hosted machines: kod, build çıktısı ve secret'lar kendi ağında kalır
- Neyin sorumluluğu sende kalıyor
- Team pools ve dinamik ölçekleme: hazırda makine bekletmeden kapasite
- Hazırda bekletmeden kapasite: hibernate + reconnect
- Kendi sandbox'ında koşturma: dokuz partner entegrasyonu
- Linux ve Mac worker'larda computer-use: ne açılıyor, ne riskli
- Claude Code kullanıcısı için okuma: yerel oturum vs bulut ajanı karar tablosu
- Sırada ne var: Cursor Projects ve bir sonraki katman
- SSS
- Cursor Cloud Agents nedir, self-hosted machines nasıl çalışır?
- Kod ve secret'lar kendi ağımda kalacak şekilde ajan çalıştırabilir miyim?
- Cursor Origin repo nedir, GitHub olmadan başlanabilir mi?
- Bulut ajanı mı yerel ajan mı — hangisi bana uygun?
- Sonuç
- Kaynaklar
Cursor'ın ekseni neden editörden altyapıya kaydı
2026'nın ilk yarısında Cursor'ın rekabet katmanı editör-içi tamamlama ve chat'ten, "kodu kim, nerede, hangi makinede çalıştırıyor" sorusuna kaydı. Bu kayışın somut ilk adımı 25 Mart 2026'da atıldı: Cursor, self-hosted cloud agent'ları ilk kez duyurdu — agent'ın planlama katmanı Cursor'ın bulutunda kalırken, araç çağrıları (dosya okuma/yazma, terminal, build) kullanıcının kendi worker'ına devredilebiliyordu. Eylül ayındaki self-hosted machines genişlemesi bu temelin üzerine pool'lar, hibernasyon, resmi partner entegrasyonları ve Linux/Mac'te computer-use ekledi; yani 2 Eylül 2026 bir ilk lansman değil, beş ay önce açılan bir hattın olgunlaşma turu.
Mart'tan Eylül'e: self-hosted cloud agent'ların kısa tarihi
Üç changelog girdisi birbirini tamamlıyor: 27 Ağustos'ta Start from scratch (repo'suz başlangıç + Origin), 2 Eylül'de self-hosted machines'in pool/hibernasyon/partner/computer-use genişlemesi, 10 Eylül'de ise bu altyapının üzerine oturan yeni bir koordinasyon katmanı: Cursor Projects.
Cloud Agents ve repo'suz başlangıç: Start from scratch ve Origin
27 Ağustos 2026 itibarıyla Cloud Agents'ın önündeki en büyük sürtünme kalktı: agent'ı başlatmak için artık bağlı bir GitHub ya da başka bir üçüncü taraf SCM sağlayıcısı gerekmiyor. Repo seçicide "Start from scratch" seçip prompt'u yazdığında Cursor arka planda senin için bir Origin repo oluşturuyor; beğendiğin sonucu "Create repo" ile tam donanımlı bir Origin repo'suna kaydedebiliyorsun.
Origin repo nasıl çalışır, sınırları neler
Origin, Cursor'ın kendi git forge'u — kod depolamak ve paylaşmak için tasarlanmış, erken beta aşamasında bir ürün. Repo oluşturma, push/pull, GitHub mirror'lama, PR ve arama gibi temel işlevleri destekliyor ama Origin kod depolama yalnızca Pro, Teams ve Enterprise planlarında var; ücretsiz planda kullanılamıyor. Start from scratch akışının bir diğer pratik faydası: Cursor artık cloud agent'ın canlı ortamını doğrudan tarayıcına port-forward ediyor, böylece "design mode" gibi araçlarla anlık önizleme yapabiliyorsun; Vercel hesabını bağlayıp yayınlayarak da çalışan şey için gerçek bir canlı URL alabiliyorsun (yayın özelliği için Vercel hesabı şart).
bash
1# Kavramsal akış — Start from scratch (cursor.com/changelog/start-from-scratch)2# 1) Repo seçicide "Start from scratch" seç, prompt'u yaz3# 2) Cursor arka planda bir Origin repo oluşturur (henüz görünmez)4# 3) Sonuç beğenilirse "Create repo" -> tam donanımlı Origin repo5# 4) Canlı ortam tarayıcıya port-forward edilir (design mode dahil)6# 5) (opsiyonel) Vercel hesabı bağla -> "publish" -> gerçek URLBu akışın editördeki "AI-first" verimlilik anlatısıyla karıştırılmaması gerekiyor — Cursor AI'nin editör-içi 10x verimlilik hattı tamamen farklı bir katman; burada anlatılan repo/altyapı hattı, tamamlama/chat deneyiminden bağımsız ilerliyor.
Start from scratch'in erken-beta durumu birkaç somut sınır getiriyor: Origin kod depolama ücretsiz planda yok, yalnız Pro/Teams/Enterprise'da açık; dokümantasyon Origin'i "erken beta" olarak nitelendiriyor, yani repo yönetimi (görünürlük, Issues gibi ek özellikler) zamanla genişleyebilir. Pratik sonuç şu: Origin'i GitHub'ın tam ikamesi değil, "prompt'tan başlayıp hızlı bir çalışan taslağı kaydetme" için bir ilk-durak olarak görmek daha isabetli — büyük bir takım repo'sunu buraya taşımak henüz olgunlaşmış bir senaryo değil.
Self-hosted machines: kod, build çıktısı ve secret'lar kendi ağında kalır
2 Eylül 2026 changelog'una göre self-hosted machines, araç yürütmeyi tamamen kendi ağında tutmanı sağlıyor: kod tabanın, build çıktıların ve secret'ların, kendi altyapında çalışan internal makinelerde kalıyor. Mekanizma her partner için aynı: Cursor CLI, Cursor'a doğru bir outbound HTTPS bağlantısı açıyor ve Cursor agent'ın tool call'larını bu bağlantı üzerinden gönderiyor — yani dışarıdan içeri açılan bir port'a ihtiyaç yok.
Neyin sorumluluğu sende kalıyor
Cursor, açık kaynak referans şablonları da sağlıyor: anysphere/aws-lambda-workers, anysphere/cloudflare-workers, anysphere/k8s-workers gibi repo'lar, bekleyen pool isteklerini üstlenen ve her istek için bir worker başlatan bir "worker controller" çalıştırıyor. Buradan başlayıp kendi imajını, ağ politikanı ve ölçeklendirme kurallarını sen tanımlıyorsun — yani self-hosted machines "sorumluluğu sıfırlamak" değil, "sorumluluğu kendi ağına taşımak" anlamına geliyor.
Cursor'ın resmi karar ağacına göre bu tercih varsayılan değil: Cursor-hosted Cloud Agents zaten müşterilerin %80'inden fazlasının ihtiyacını karşılıyor. Karar ağacının üç kapısı var: yazılı bir politikanın repo checkout'unu ve araç yürütmesini perimeter içinde tutmayı şart koşması; agent'ların Tailscale, PrivateLink ya da egress allowlist üzerinden erişilemeyen iç servislere ihtiyaç duyması; ve özel işletim sistemi, özel donanım ya da büyük bir repo için kalıcı yerel disk gerekmesi. Özel donanımın somut karşılığını pool dokümantasyonu veriyor: GPU gerektiren işler için gpu, Mac gerektiren işler için ios gibi ayrı pool'lar tanımlıyorsun.
Bu üç referans repo'nun (aws-lambda-workers, cloudflare-workers, k8s-workers) ortak deseni önemli: her biri "worker controller" adı verilen bir arka plan sürecini çalıştırıyor, bu süreç bekleyen pool isteklerini dinliyor ve her istek için tek bir worker başlatıyor. Yani mimari olarak sen bir "her zaman açık sunucu" değil, "istek geldiğinde ayağa kalkan, işi bitince kapanan" bir worker havuzu işletiyorsun — bu da hem maliyeti hem de saldırı yüzeyini, sürekli çalışan bir makineye göre küçültüyor. Referans şablonlardan birini klonlamak, sıfırdan bir worker controller yazmaktan daha az hataya açık bir başlangıç noktası sunuyor; özellikle ağ politikan ve imaj sertleştirmen zaten netse, değiştirmen gereken kısım genelde yalnızca deploy hedefinin kimlik bilgileri oluyor.
Team pools ve dinamik ölçekleme: hazırda makine bekletmeden kapasite
Self-hosted machines'in tek başlı kullanımı "My Machines" iken, takım/kurum senaryosu için Cursor "team pools" adında adlandırılmış worker kuyrukları sunuyor. Bir pool tek bir repo'ya bağlı değil — pool'u adlandırıyorsun ve uygun herhangi bir worker isteği üstlenebiliyor. Dokümantasyon iki yapılandırma tanımlıyor: repo-backed pool bir ya da daha fazla repo'ya bağlanır, any-repo pool ise yalnız pool adıyla eşleşir. Kapasite istek geldikçe büyüyor, worker'lar bağlantıyı kestiğinde küçülüyor; boşta kalan makineler uyutuluyor (hibernate) ve bir takip isteği geldiğinde yeniden bağlanma penceresi içinde geri getiriliyor. Bu kapının bir giriş şartı var: Team Pools bir Cursor Enterprise planı, admin tarafında açılmış self-hosted ayarı ve worker kimlik doğrulaması için bir service account API anahtarı gerektiriyor (cursor.com/docs/cloud-agent/self-hosted/pool).
Bu model, özellikle çok-repo'lu kurumlarda önemli bir operasyonel farklılık yaratıyor: tek tek repo'lara özel worker havuzları kurmak yerine, donanım profiline göre (örneğin "GPU'lu build worker'ları" ya da "Mac tabanlı iOS worker'ları") tek bir pool tanımlayıp, o pool'u ihtiyacı olan her repo'nun agent isteğine açabiliyorsun. Bu da worker sayısını repo sayısına göre değil, gerçek eşzamanlı iş yüküne göre ölçeklendirmeni sağlıyor.
Hazırda bekletmeden kapasite: hibernate + reconnect
Bu tasarımın pratik sonucu şu: sabit sayıda makineyi 7/24 açık tutmak zorunda kalmadan, talebe göre nefes alan bir kapasite havuzu kurabiliyorsun. Ama Cursor'ın kendi dokümantasyonu önemli bir sınırı da açıkça belirtiyor: pool'lar bir altyapı-sahipliği tercihi — agent döngüsünü Cursor'ın bulutundan çıkarmıyor; planlama katmanı hâlâ Cursor tarafında kalıyor.
Ölçüt | My Machines (tekil) | Team Pools |
|---|---|---|
Kapsam | Tek kullanıcı | Takım/kurum |
Repo bağı | Genelde tek repo/proje | Adlandırılmış kuyruk, repo'ya bağlı değil |
Ölçekleme | Manuel | Talebe göre büyür/küçülür |
Boşta kalma | Sürekli açık | Hibernate + reconnect penceresi |
Worker limiti | Self-Hosted Machines geneli: 200/kullanıcı + 1000/takım | aynı |
Kendi sandbox'ında koşturma: dokuz partner entegrasyonu
Cursor cloud agent'ları artık zaten kullandığın altyapı üzerinde çalışabiliyor. Her partner kendi platformunda Self-Hosted Machines worker'ı çalıştırmak için ayrı bir rehber tutuyor; liste dokümantasyona göre şöyle: AWS Lambda, Cloudflare, Namespace, Modal, Daytona, E2B, Vercel, Tensorlake ve Coder. Bir terminoloji nüansı var: Coder'ın rehberi kendi tarafında "Agent Relay for Cursor" adını taşıyor. Sayım da kaynağa göre değişiyor: 2 Eylül changelog duyurusu sekiz platform sayıyor (AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel, E2B), dokümantasyondaki partner rehberi listesi ise Tensorlake ile birlikte dokuza çıkıyor — bu yazıdaki "dokuz" sayımı dokümantasyon listesine dayanıyor.
Bu listenin çeşitliliği kendi başına bir sinyal: serverless (Lambda, Cloudflare, Vercel), sandbox-odaklı (Modal, Daytona, E2B, Namespace) ve remote-development (Coder) kategorilerinin hepsini kapsıyor. Pratik anlamı şu — hangi kategoriden bir altyapı kullanırsan kullan (kısa ömürlü serverless fonksiyon mu, uzun ömürlü sandbox mı, yoksa kurumsal remote-dev ortamı mı), Cursor'ın self-hosted worker mekanizması aynı outbound-HTTPS deseniyle üzerine oturabiliyor; entegrasyon başına özel bir protokol öğrenmen gerekmiyor.
json
1{2 "self_hosted_worker_partners": [3 "AWS Lambda",4 "Cloudflare",5 "Namespace",6 "Modal",7 "Daytona",8 "E2B",9 "Vercel",10 "Tensorlake",11 "Coder (rehber adi: Agent Relay for Cursor)"12 ],13 "kaynak": "cursor.com/docs/cloud-agent/self-hosted/integrations"14}Bu geniş partner yelpazesi, agentic çalışma biçimlerini incelerken faydalı bir referans noktası: agentic AI tool-use ve planner-loop deseni üzerine yazımızda anlattığımız "planlama ile yürütmeyi ayırma" fikri, Cursor'ın burada worker'ı Lambda'ya, planlamayı kendi bulutuna koyma tercihiyle örtüşüyor.
Linux ve Mac worker'larda computer-use: ne açılıyor, ne riskli
2 Eylül changelog'u ayrıca self-hosted worker'lara Linux ve Mac'te computer-use desteği getirdi: doğru masaüstü paketleri kuruluysa agent tıklayabiliyor, yazabiliyor, ekran görüntüsü alabiliyor ve tarayıcıyı sürebiliyor; sen de agent'ın masaüstünü izleyebilir ya da kontrolü devralabilirsin. Dokümantasyon burada net bir güvenlik çizgisi koyuyor: hem computer-use hem desktop-sharing özellikleri sunucu tarafından hiçbir zaman otomatik açılmıyor, ikisi de açık opt-in gerektiriyor. Desktop sharing (--share-desktop) yalnızca Linux'ta destekleniyor; Linux tarafında ayrıca bu masaüstü paketlerini worker imajına gömmen gerekiyor, böylece her makine hazır ayağa kalkıyor. macOS'ta ise worker, oturum açık masaüstü oturumunu "Cursor Computer Use" adlı ayrı bir yardımcı uygulama üzerinden sürüyor ve bunun için Accessibility ile Screen Recording izinleri gerekiyor.
Bu, Claude'un computer-use API'si üzerine yazdığımız production rehberiyle karşılaştırıldığında tanıdık bir güvenlik deseni: ekran/masaüstü kontrolü veren her ajan katmanında opt-in zorunluluğu ve izin diyaloğu, kazara-tetiklenen otomasyonun önündeki asgari bariyer olarak duruyor. Riskli taraf da açık: macOS'ta Accessibility izni veren bir hesap, teoride masaüstündeki her uygulamaya erişebilen bir agent anlamına geliyor — bu yüzden opt-in'i yalnızca güvendiğin, izole worker imajlarında açmak mantıklı.
bash
1# Cursor CLI kurulumu (macOS, Linux ve WSL) ve surum dogrulamasi2curl https://cursor.com/install -fsS | bash3agent --version4 5# Pool worker'i bir service account API anahtariyla kimliklendir6export CURSOR_API_KEY="your-service-account-api-key"7 8# gpu pool'una katilan, isi bitince 600 saniyede temiz cikan worker9agent worker --pool gpu --idle-release-timeout 600 start10 11# Ayni worker'i computer-use opt-in'i acik baslatmak12agent worker --pool gpu --computer-use startBayrakların sırası önemli: worker seçenekleri start komutundan önce geliyor. --idle-release-timeout bayrağını hiç geçmezsen varsayılan 3600 saniye devreye giriyor, yani worker oturum bittikten sonra bir saat daha takip mesajları için ayakta kalıyor. Tek worker'a birden çok repo kökü bağlamak istersen --worker-dir bayrağını her kök için bir kez veriyorsun; bayrak en fazla 20 yola kadar tekrarlanabiliyor ve her yolun önceden var olan bir dizin olması gerekiyor.
Claude Code kullanıcısı için okuma: yerel oturum vs bulut ajanı karar tablosu
Claude Code'da günlük olarak yerel oturumla çalışan bir geliştiriciysen, Cursor'ın bu üç parçalı hattını (Origin, self-hosted machines, team pools) kendi karar çerçevene oturtmak için aşağıdaki tablo faydalı bir başlangıç noktası.
Senaryo | Öneri | Neden |
|---|---|---|
Hassas kod/iç ağ bağımlı build, secret izolasyonu şart | Self-hosted machines (My Machines/Team Pools) | Kod ve secret kendi ağında kalır, yalnız outbound bağlantı açılır |
Hız/sürtünmesizlik önceliği, altyapı yönetmek istemiyorsan | Cursor-hosted Cloud Agents | Müşterilerin %80'inden fazlasının ihtiyacını zaten karşılıyor |
Takım genelinde paylaşılan, talebe göre büyüyen kapasite | Team Pools (Enterprise planı şart) | Hibernate + reconnect ile boşta-makine maliyeti düşük |
GPU ya da Mac gibi özel donanım gerekiyor (örn. iOS build) | Self-hosted machines | Karar ağacının 3. kapısı özel OS/donanım/kalıcı disk ihtiyacını buraya yönlendiriyor (ARM için kurumsal hesap ekibi) |
Repo yok, hızlı prototip/prompt-tan-başlama | Start from scratch + Origin | GitHub/SCM bağlamadan başlayıp sonradan kaydedebiliyorsun |
Yalnızca yerel, tek makinede, tam kontrol isteniyor | Yerel Claude Code oturumu | Bulut worker/relay katmanı gerekmiyor |
Bu tabloyu Cursor vs GitHub Copilot karşılaştırmamızla ve Claude Code vs Cursor karşılaştırmamızla birlikte okumak, editör-katmanı farklarını altyapı-katmanı farklarından ayırmana yardımcı olur — ikisi karışınca "hangisi daha iyi" sorusu yanlış katmanda cevaplanmış olur.
Burada dikkat edilmesi gereken nokta şu: hiçbir satır "editör deneyimi hangisinde daha iyi" sorusuna cevap vermiyor, çünkü bu tamamen ayrı bir katman. Altyapı kararı verirken sorduğun soru "kod nerede çalışıyor ve kim erişebiliyor" iken, editör kararında sorduğun soru "tamamlama/chat/refactor deneyimi ne kadar iyi" oluyor. İki soruyu aynı tabloda karıştırmak, örneğin "self-hosted machines kullanıyorum, o yüzden editörüm de daha güvenli" gibi yanlış bir çıkarıma götürebilir — self-hosted machines yalnızca araç yürütme ağını değiştiriyor, editör deneyimini değil.
Sırada ne var: Cursor Projects ve bir sonraki katman
10 Eylül 2026'da Cursor, bu altyapı hattının üzerine yeni bir koordinasyon katmanı ekledi: Cursor Projects (beta). Resmi changelog'a göre bir Project kendi bulut bilgisayarında çalışıyor — dizüstünü kapatman onu durdurmuyor; koordinatör agent kodu kendisi yazmak yerine işi planlıyor ve uygulayacak agent'lara delege ediyor. Bu, otonom yazılım mühendisi ajanları kategorisiyle aynı yöne işaret eden bir adım: tek-oturumluk agent'tan, kalıcı-çalışan/delege-eden koordinatöre geçiş. 10 Eylül 2026 itibarıyla Projects beta olarak tüm kullanıcılara açılmaya başladı; bu yüzden burada yalnız mimari yönü önemli.
Bu üç katmanı (Origin/repo, self-hosted machines/ağ, Projects/koordinasyon) üst üste koyduğunda ortaya çıkan resim şu: Cursor artık tek bir agent oturumu değil, birbirine bağlı üç bağımsız katman sunuyor — nereden başlayacağını (Origin), nerede çalışacağını (self-hosted machines/pools) ve kimin koordine edeceğini (Projects) ayrı ayrı seçebiliyorsun. Bu ayrıştırma, multi-agent koordinasyon ve LangGraph gibi agent framework'leri üzerine yazdığımız içeriklerdeki "planlama katmanını yürütme katmanından ayır" prensibiyle aynı yöne işaret ediyor; farkı, burada bu ayrımı kendi kod yazmadan, ürün seviyesinde bir yapılandırmayla elde ediyor olman.
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Self-hosted machines'e geçmeden önce kendine sorabileceğin, Cursor'ın resmi karar ağacından ve dokümantasyonundan derlenmiş bir kontrol listesi hazırladık. Bu liste, "yönetilen bulutta mı kalmalıyım yoksa kendi ağıma mı taşımalıyım" sorusunu somut kriterlere indiriyor.
SSS
Cursor Cloud Agents nedir, self-hosted machines nasıl çalışır?
Cloud Agents, agent'ın planlama katmanını Cursor'ın bulutunda tutarken araç çağrılarını (dosya/terminal/build) bir worker'a devreden yürütme modelidir. Self-hosted machines'te bu worker, kendi altyapında çalışır ve Cursor'a doğru bir outbound HTTPS bağlantısı açar; Cursor agent'ın tool call'larını bu bağlantı üzerinden gönderir — içeri açılan bir port gerekmez. Bu tasarım, worker'ı firewall arkasında, NAT arkasında ya da tamamen izole bir subnet'te tutmana rağmen agent'ın çalışmasını mümkün kılıyor; tek koşul, worker'ın Cursor'a doğru giden trafiği açabilmesi.
Kod ve secret'lar kendi ağımda kalacak şekilde ajan çalıştırabilir miyim?
Evet. Cursor'ın kendi ifadesiyle kod tabanın, build çıktıların ve secret'ların kendi altyapındaki internal makinelerde kalır. Ancak worker imajının güvenliği, ağ politikası ve ölçeklendirme kuralları sana ait bir sorumluluktur; Cursor yalnızca açık kaynak referans şablonları (aws-lambda-workers, cloudflare-workers, k8s-workers) sağlar.
Cursor Origin repo nedir, GitHub olmadan başlanabilir mi?
Evet. 27 Ağustos 2026'dan beri Cloud Agents'ı başlatmak için bağlı bir GitHub veya başka bir SCM sağlayıcısı gerekmiyor; "Start from scratch" ile prompt yazarak başlayıp beğendiğin sonucu bir Origin repo'ya kaydedebilirsin. Origin, Cursor'ın erken beta aşamasındaki git forge'u ve yalnızca Pro, Teams ve Enterprise planlarında kullanılabiliyor.
Bulut ajanı mı yerel ajan mı — hangisi bana uygun?
Cursor'ın kendi karar ağacına göre yönetilen Cursor-hosted Cloud Agents müşterilerin %80'inden fazlasının ihtiyacını karşılıyor; self-hosted machines'e geçiş yalnızca perimeter politikası, Tailscale/PrivateLink/egress allowlist ile erişilemeyen iç servisler ya da özel işletim sistemi, özel donanım (GPU/Mac) veya büyük repo için kalıcı yerel disk gibi somut kısıtların varsa öneriliyor. Tamamen yerel, tek-makine kontrolü istiyorsan Claude Code gibi bir yerel oturum daha basit bir başlangıç noktasıdır.
Sonuç
Cursor'ın 2026 hattı tek bir özellik değil, üç parçanın birlikte okunması gereken bir hikaye: Start from scratch + Origin repo'suz başlangıcı kolaylaştırıyor, self-hosted machines kod/secret egemenliğini kendi ağına taşıyor, team pools ise bunu takım ölçeğinde talebe duyarlı bir kapasiteye dönüştürüyor. Editör-içi verimlilik anlatısıyla (Cursor AI'nin 10x verimlilik yazısı) karıştırmadan, bu üçünü kendi altyapı kısıtlarına göre değerlendirmek en doğru yaklaşım.
Pratik bir başlangıç sırası öneriyoruz: önce Cursor-hosted Cloud Agents ile başla (kurulum gerektirmiyor, müşterilerin çoğunluğu için yeterli); ağ/donanım/disk kısıtın netleştiğinde My Machines ile tek makinede self-hosted dene; takım genelinde paylaşım ihtiyacı doğduğunda Team Pools'a geç (Enterprise planı şart). Bu sıralama, dokümantasyonun kendi karar ağacıyla da örtüşüyor ve gereksiz erken karmaşıklıktan kaçınmanı sağlıyor.
Editör-katmanı karşılaştırmaları için Cursor vs GitHub Copilot ve Claude Code vs Cursor yazılarımıza, agent-orkestrasyon deseni için agentic AI tool-use ve planner-loop yazımıza, otonom ajan kategorisinin genel resmi için ise Devin: otonom yazılım mühendisi yazımıza bakabilirsin.
Kaynaklar
- Cursor Changelog: Self-hosted Cloud Agents — self-hosted cloud agent'ların ilk duyurusu (25 Mart 2026).
- Cursor Changelog: Self-hosted machines — pool, hibernasyon, partner listesi ve Linux/Mac computer-use duyurusu (2 Eylül 2026).
- Cursor Changelog: Start from scratch — GitHub/SCM olmadan başlama ve Origin repo'ya kaydetme akışı (27 Ağustos 2026).
- Cursor Changelog: Projects — koordinatör-agent katmanı, bulutta kalıcı çalışan Project kavramı (10 Eylül 2026).
- Cursor Docs: Origin — Origin git forge'un beta durumu ve plan kısıtları.
- Cursor Docs: Self-hosted integrations — partner listesi ve outbound bağlantı mekanizması.
- Cursor Docs: Computer use — opt-in kuralları, Linux/Mac farkları, izin gereksinimleri.
- Cursor Docs: Self-hosted pool — worker limitleri (200/kullanıcı, 1000/takım) ve pool'ların kapsamı.
- Cursor Docs: Choose runtime — resmi karar ağacı ve %80 istatistiği.
