Kendi VPS Sunucunuzda sandboxd Kurulumu ve Yönetimi

sandboxd nedir ve kendi sunucunuzda çalıştırmanın avantajları

sandboxd uygulamasını kendi sunucunuzda barındırmak için Docker kurulu bir Linux sunucusuna ve bir alan adına ihtiyacınız vardır. Bir komut (prompt) gönderdiğinizde, kodlama ajanı izole bir container içerisinde gerçek bir uygulama oluşturur ve bu uygulama kendi önizleme URL'si üzerinden erişilebilir hale gelir. "Prompt-to-app" oluşturucular, 2026 yılının en popüler barındırılan hizmet kategorisidir; sandboxd ise MIT lisansı altında, kendi VPS'nizde çalışan ve oluşturulan kodları doğrudan kendi diskinizde tutan bir çözümdür.

Tasarım bilinçli olarak küçük tutulmuştur. Go tabanlı bir kontrol düzlemi Docker'ı yönetir, Traefik v3 her önizleme ana bilgisayar adını yönlendirir, SQLite durumu saklar ve her uygulama tek bir container içinde çalışır. Kubernetes veya harici bir veritabanı sunucusu bulunmadığından, 2 vCPU kapasiteli bir sunucu üzerinde dahi çalışabilir.

Modelin tamamı dört nesne üzerine kuruludur. app (uygulama), adını, git meta verilerini ve gizli anahtarlarını barındıran kalıcı projedir. sandbox, uygulamanın içinde çalıştığı Docker container'ıdır ve bir uygulama aynı anda tek bir sandbox'a işaret eder. workspace (çalışma alanı), ana makinede yaşayan ve container silinse dahi varlığını koruyan uygulama dosyalarıdır. task (görev), sandbox içindeki ajana iletilen tek bir komuttur. Bir sandbox'ı durdurmak belleği serbest bırakır ancak dosyaları korur. Sandbox'ı yok etmek ise container'ı tamamen kaldırır; uygulama daha sonra yeni bir tane başlatabilir.

sandboxd, Dify ve OpenHands'ten nasıl farklıdır?

Bu üç araç, sunucunuz üzerinde bir LLM (büyük dil modeli) çalıştırdıkları için birbirine karıştırılmaktadır; ancak ürettikleri çıktılar birbirinden farklıdır. Dify, LLM uygulamaları oluşturur: sohbet arayüzleri, veri getirme hatları ve kullanıcı her kullandığında bir modeli çağıran iş akışları geliştirir. Model, bitmiş ürünün bir parçasıdır. OpenHands, halihazırda sahip olduğunuz bir depo üzerinde çalışır: aracı kodunuza yönlendirirsiniz; o da dosyaları okur, komutları çalıştırır ve değişiklikler önerir. sandboxd ise her şeye sıfırdan başlar. Bir ön ayardan yola çıkarak bir proje iskeleti oluşturur, bunu temiz bir container içinde derler ve size incelemeniz için bir URL verir. Ortaya çıkan sonuç, çalışmak için herhangi bir modele ihtiyaç duymayan standart bir React veya FastAPI uygulamasıdır.

Bu nedenle, sonuçta ne elde etmek istediğinize göre seçim yapın. sandboxd, bir cümle ile başlayıp sonrasında kodu elinizde tutmak içindir. Diğer ikisi ise depo veya model destekli ürün halihazırda mevcut olduğunda kullanılır.

Diğer fark ise yaştır; üzerinde gerçek bir şey inşa etmeden önce dikkate alınması gereken husus budur.

[
  {
    "tool": "sandboxd",
    "github_stars": "875",
    "forks": "50"
  },
  {
    "tool": "OpenHands",
    "github_stars": "83,091",
    "forks": "10,711"
  },
  {
    "tool": "Dify",
    "github_stars": "151,320",
    "forks": "23,886"
  }
]

sandboxd, OpenHands için 83,091 ve Dify için 151,320 yıldıza karşılık 875 yıldıza sahiptir. Depo 3 Haziran 2026 tarihinde oluşturulmuştur, yani Ağustos 2026 itibarıyla iki aylıktır; OpenHands Mart 2024, Dify ise Nisan 2023 tarihlidir. v0.1.0 sürümü 6 Haziran 2026'da, v0.3.6 sürümü ise 1 Ağustos 2026'da yayınlanmıştır. Proje kendisini beta olarak tanımlamakta ve 0.x sürümlerinin uyumluluğu bozabileceğini belirtmektedir. Bu rakamları kaliteye dair bir hükümden ziyade bağımlılık riski olarak değerlendirin: iki aylık bir proje, hatalarının başkaları tarafından bulunması için yalnızca iki aylık bir süreye sahip olmuştur.

Sunucunun ihtiyaçları ve yetersizlik durumunda yaşanan aksaklıklar

Proje, başlangıç için 2 vCPU ve 4 GB RAM'in yeterli olduğunu belirtir. Bu, kontrol düzlemi ve küçük bir sandbox için doğrudur; ancak aynı anda geliştirme yapan iki kişi için yetersiz kalır. Belleği bölümlere ayırarak planlayın. Traefik ve Go kontrol düzlemi küçük boyutludur. Çalışan her sandbox, tam bir Node veya Python araç zinciri barındırır; zirve noktası ise bir npm install ve ardından gelen üretim derlemesidir. Birkaç uygulamayı canlı tutacak bir sunucu için 8 GB RAM planlayın ve swap alanını kapasite olarak değil, bir güvenlik ağı olarak görün; çünkü swap kullanan bir derleme saniyeler yerine dakikalar sürer.

Bellek tükendiğinde birbirinden tamamen farklı iki hata türüyle karşılaşırsınız. Sandbox içinde, container sandboxd tarafından belirlenen katı --memory sınırına ulaşır ve çekirdek en büyük süreci sonlandırır; bu nedenle derleme, aracıdan gelen anlamlı bir mesaj olmadan başarısız olur. docker ps -a, ilgili container için 137 çıkış kodunu gösterir ve üzerinde docker inspect çalıştırıldığında "OOMKilled": true raporlanır. Bu şekilde sonlanan bir Node derlemesi genellikle öncesinde JavaScript heap out of memory çıktısı verir.

İkinci hata türü ana makinede gerçekleşir. sandboxd, ana makine belleği azaldığında sandbox'ları durduran bir baskı temizleyici (pressure reaper) çalıştırır; bu nedenle küçük bir sunucuda, siz önizlemeyi izlerken bir sandbox aniden kaybolabilir. Dosyalar güvendedir ve önizleme URL'sine gelen bir sonraki istek onu uyandırır, ancak container durdurulduğunda çalışan bir görev kaldığı yerden devam etmez.

Disk alanı daha sessiz bir sorundur. Her uygulama ana makinede kendi çalışma alanını tutar ve bir JavaScript projesi yüzlerce megabaytlık bir node_modules ağacı taşır. On uygulama, görüntüler hesaba katılmadan önce birkaç gigabaytlık bağımlılık demektir. 40 GB ile başlayın ve şu komutla izleyin:

docker system df
sudo du -sh /var/lib/sandboxed/workspaces

Varsayılan veri dizini, fazladan bir e ile yazılan /var/lib/sandboxed dizinidir. /var/lib/sandboxd yazmak sizi boş bir dizine götürür ve beş dakikalık kafa karıştırıcı bir sürece neden olur.

Sabitlenmiş bir sandboxd sürümünün kurulması

Öncelikle sunucuda Compose eklentisiyle birlikte Docker Engine ve git kurulu olmalıdır. VPS üzerinde Docker kurulumu bu süreci kapsamaktadır.

docker compose version
git --version

Her iki komut da bir sürüm numarası döndürmelidir. docker: 'compose' is not a docker command çıktısı, eski bağımsız docker-compose ikili dosyasının yüklü olduğunu gösterir; yükleyici ise v2 eklentisini beklemektedir.

Yükleyici, ağ üzerinden çekilen bir kabuk betiğidir; bu nedenle çalıştırmadan önce içeriğini inceleyin ve sürümü sabitleyin.

curl -fsSL https://raw.githubusercontent.com/tastyeffectco/sandboxd/v0.3.6/install.sh -o install-sandboxd.sh
less install-sandboxd.sh
SANDBOXD_REF=v0.3.6 bash install-sandboxd.sh

SANDBOXD_REF, yükleyicinin $HOME/.sandboxd/src dizinine çektiği git referansıdır ve varsayılan değeri main olarak belirlenmiştir. Bu değişkenin ayarlanmaması, kurulumun o sabah birleştirilen en güncel kodla yapılmasına neden olur; sadece 2026 yılının Temmuz ayında altı sürüm yayınlayan bir projede bu durum risklidir. Sürümü sabitleyin ve değişiklik günlüğünü okuduktan sonra yükseltme işlemini bilinçli olarak gerçekleştirin.

Betik kaynak kodunu kopyalar, imajları oluşturur, docker compose up -d ile yığını başlatır ve sonunda konsol URL'si ile bir API anahtarı yazdırır. Bu anahtarı güvenli bir yerde saklayın. Bu anahtar, Docker'ı root yetkileriyle yöneten API için gerekli kimlik bilgisidir.

curl http://127.0.0.1:9090/healthz

Kontrol düzlemi ayağa kalktığında bu komut ok çıktısını verir. Eğer hiçbir çıktı alınmıyorsa yığın başlatılamamıştır: hangi servisin kapalı olduğunu görmek için ~/.sandboxd/src dizininden docker compose ps komutunu çalıştırın, ardından nedenini anlamak için docker compose logs sandboxd komutunu kullanın.

Uzak bir sunucudaki konsola erişim

Konsol, varsayılan olarak 80 olan HTTP_PORT portu üzerinden ve http://console.localhost ana makine adı ile Traefik aracılığıyla sunulur. Traefik yönlendirmeyi ana makine adına göre yaptığı için, tarayıcıya sunucunuzun IP adresini yazmak hiçbir kural ile eşleşmez ve 404 hatası döndürür. Gerçek bir alan adı ayarlayana kadar portu yönlendirin ve ana makine adını koruyun:

ssh -L 8080:127.0.0.1:80 you@your-vps

Ardından dizüstü bilgisayarınızda http://console.localhost:8080 adresini açın. Linux ve macOS üzerinde .localhost ile biten her isim 127.0.0.1 adresine çözümlenir, böylece istek doğru Host başlığı ile tünelden geçer. İlk ziyarette konsol parolasını ayarlayın.

Ajanı bir modele atama

Temel imaj içerisinde OpenCode ve Claude Code olmak üzere iki kodlama ajanı sunulur. SANDBOXD_DEFAULT_AGENT, belirli bir isim belirtilmeyen görevleri hangi ajanın çalıştıracağına karar verir ve varsayılan olarak opencode kullanılır. Herhangi bir anahtar bağlı değilken görevler, OpenCode Zen'in anahtarsız ücretsiz modelleri üzerinde çalışır; böylece ilk derlemeniz ücretsiz olur ve herhangi bir harcama yapmadan önce tüm döngüyü test edebilirsiniz.

Daha güçlü bir model kullanmak istediğinizde kendi anahtarınızı bağlayın. Anahtarlar kontrol düzlemine gider, asla sandbox ortamına girmez: veriler veri dizini altında şifrelenmiş olarak saklanır ve bir kimlik bilgisi proxy'si tarafından ağ üzerinden iletilir; bu sayede ne ajan ne de yazdığı kod anahtarları okuyabilir.

export API=http://127.0.0.1:9090
export SANDBOXD_TOKEN=sk_...                       # printed by the installer
export AUTH="Authorization: Bearer $SANDBOXD_TOKEN"

curl -s -XPOST $API/v1/agents/claude-code/api-key -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"api_key":"sk-ant-..."}'

Konsol üzerinde aynı işlem Settings, AI Agents menüsü altından yapılır; burada bir API anahtarı yerine Claude aboneliği kullanmak isterseniz rehberli bir OAuth akışı da mevcuttur. Ajan başına varsayılan model aynı panelde yer alır ve tek bir görev için bu ayar geçersiz kılınabilir.

Uçtan uca küçük bir uygulama oluşturun

Uygulamayı oluşturun, sandbox'ını başlatın ve ardından bir istem gönderin. Kimlikler JSON formatında döner; hızlı başlangıç kılavuzu bunları sed ile çeker, bu nedenle jq yüklü olmasına gerek yoktur.

APP=$(curl -s -XPOST $API/v1/apps -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"name":"todo","runtime_preset":"react-vite"}' \
  | sed -E 's/.*"id":"([^"]+)".*/\1/')

SB=$(curl -s -XPOST $API/v1/apps/$APP/sandbox -H "$AUTH" \
  -H 'content-type: application/json' -d '{"ports":[3000]}' \
  | sed -E 's/.*"id":"([^"]+)".*/\1/')

echo "app=$APP sandbox=$SB"

Her iki değişken de bir kimlik tutmalıdır. Boş bir $SB, sandbox'ın hiçbir zaman başlatılmadığı anlamına gelir; bunun yaygın nedeni temel imajın hala oluşturuluyor olması veya ana makinenin belleğinin tükenmiş olmasıdır. Kimlik yerine bir 401 dönmesi, taşıyıcı belirtecin (bearer token) hatalı olduğunu gösterir.

curl -s -XPOST $API/v1/sandboxes/$SB/tasks -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"prompt":"Add a todo list with a text input, an add button, and a delete button on each row. Keep the list in localStorage.","agent":"opencode"}'

Yanıt bir görev kimliği taşır. GET /v1/sandboxes/$SB/tasks/<task id> sonucunu döndürür ve aynı görev üzerindeki /events yolu, aracın ne yaptığını gösteren canlı bir SSE (server sent events) akışıdır. Konsol, sohbet ile aynı akışı gösterir.

Uygulama daha sonra http://s-<sandbox id>-3000.preview.localhost adresindedir; burada 3000 talep ettiğiniz porttur. Sandbox uyku modundaysa, ilk istek Traefik'in genel yakalayıcısına (catch-all) düşer, sandboxd container'ı başlatır, portun yanıt vermesini bekler ve uygulamanıza yönlendiren kısa bir ısınma sayfası sunar. Bu sayfadan hiç çıkmayan bir önizleme, içerideki sürecin uygulamanın sandbox.yaml dosyasında belirtilen portu dinlemediği anlamına gelir.

Önizlemeleri HTTPS ile gerçek bir alan adına taşıma

Her sandbox kendi ana makine adına (hostname) sahiptir, bu nedenle tek bir wildcard DNS kaydı hepsini kapsar. *.preview.yourdomain.com kaydını, sunucunun IP adresine bir A kaydı ile yönlendirin. Ardından .env içindeki önizleme değişkenlerini ~/.sandboxd/src dosyasında ayarlayın:

PREVIEW_DOMAIN=yourdomain.com
PREVIEW_ENTRYPOINT=websecure
PREVIEW_TLS=true
SANDBOXD_API_AUTH_DISABLED=false

Traefik tarafında eşleşen yapılandırma gereklidir: traefik/traefik.yml dosyasında websecure giriş noktasını etkinleştirin ve bir sertifika çözümleyici (certificate resolver) ekleyin. DNS-01 sınamasını kullanın; çünkü tek bir wildcard sertifikası tüm önizleme ana makine adlarını kapsayacaktır. HTTP-01 ile her yeni sandbox için ayrı bir sertifika düzenlenmesi gerekir; bu da yoğun bir çalışma gününde Let's Encrypt hız sınırlarına (rate limits) takılmanıza neden olur. DNS-01 sınaması ile wildcard sertifikaları bölümü, bu sürecin DNS tarafını ele almaktadır.

cd ~/.sandboxd/src
docker compose up -d

Önizleme URL'leri https://s-<id>-3000.preview.yourdomain.com biçimini alır. Güvenlik duvarında 80 ve 443 numaralı portları açın ve 9090 numaralı portu dış dünyaya kapalı tutun: temel ufw güvenlik duvarı kuralları bölümüne bakın. Bir önizleme ana makine adını tahmin edebilen herkesin uygulamayı yükleyebileceğini unutmayın; bu nedenle önizlemeleri herkese açık olarak değerlendirin.

Oluşturulan kod nereye kaydedilir ve dışa aktarılabilir mi?

Ana makinede, veri dizininin altındadır. Her çalışma alanı /var/lib/sandboxed/workspaces/<id>/ konumunda düz bir dizindir ve konteyner içine bind mount yöntemiyle bağlanır; uygulama dosyaları ise sandbox içinde /home/sandbox/workspace/app konumunda bulunur. Kontrol düzlemi durumu state/sandboxd.db konumundaki tek bir SQLite dosyasında tutulur ve şifrelenmiş aracı kimlik bilgileri agent-auth/ içindedir. Hiçbir veri konteyner katmanında gizli tutulmaz; bu nedenle yedekleme işlemi, bir dizin kopyası ve ilgili veritabanı dosyasından ibarettir. VPS üzerinde restic yedekleri her ikisini de yönetir.

sudo ls /var/lib/sandboxed/workspaces
sudo du -sh /var/lib/sandboxed/workspaces/*

Git dışa aktarma özelliği sonradan eklenmiş bir eklenti değil, yerleşik bir yapıdır. API, okuma için durum ve fark (diff) bilgilerini sunar; ardından commit ve push işlemleri gerçekleştirilebilir.

curl -s $API/v1/apps/$APP/git/status -H "$AUTH"

curl -s -XPOST $API/v1/apps/$APP/git/commit -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"message":"todo list, first pass"}'

curl -s -XPOST $API/v1/apps/$APP/git/push -H "$AUTH" \
  -H 'content-type: application/json' -d '{"branch":"main"}'

Özel bir uzak depo için, konsolda Ayarlar (Settings) ve Git kimlik bilgileri (Git credentials) altında bir kez tanımlanan kişisel erişim belirteci (personal access token) gerekir. Bu belirteç şifrelenmiş olarak saklanır ve sandbox dışında tutulur; böylece aracı (agent) bunu okuyamaz veya sizin bilginiz dışında push işlemi yapamaz. Erken ve sık push yapın. Siz yapana kadar çalışma alanı dizini kodun tek kopyasıdır ve DELETE /v1/apps/<id> komutu, bu dizini geri dönüşü olmayacak şekilde siler.

Bir derleme işlemine ait model token maliyeti nedir?

sandboxd harcamalarınızı ölçümlemez; bu nedenle dikkate almanız gereken rakam, kullandığınız sağlayıcının panelinde yer alan veridir. Ücretsiz OpenCode Zen modelleri herhangi bir maliyet oluşturmaz ancak ücretli modellere kıyasla daha yavaş ve daha zayıftır; bu durum, basit bir uygulama dışındaki her türlü projede daha fazla düzeltme döngüsü gerektireceği anlamına gelir.

Faturanın yapısı, bir aracı döngüsünün (agent loop) çalışma şekline göre belirlenir. Her adımda ihtiyaç duyulan bağlam yeniden gönderilir; bu nedenle maliyet, uygulama sayısına değil, döngü sayısına göre hesaplanır. Tek seferde sonuç veren bir komut ucuzdur. Elli dosyadan oluşan bir projede "şimdi boşlukları düzelt" şeklinde on beş kez tekrarlanan bir süreç ise maliyetlidir, çünkü dosya içerikleri her seferinde tekrar gönderilir. Girdi ve çıktı tokenları farklı şekilde fiyatlandırılır ve bir kodlama aracısının oturum başına maliyeti gerçekçi aralığı sunar. Denetimsiz çalışan bir döngüye yetki vermeden önce sağlayıcı tarafında katı bir harcama limiti belirleyin.

Eski sandbox ortamlarının temizlenmesi

Boşta duranları temizleme mekanizması (idle reaper), SANDBOXD_IDLE_THRESHOLD_SECONDS değerini aşan, varsayılan olarak 2100 saniye yani 35 dakika boyunca işlem görmeyen tüm sandbox ortamlarını durdurur. Bu işlem RAM kaynaklarını serbest bırakır ancak dosyaları korur; önizleme URL'sine gelen bir sonraki istek konteyneri tekrar uyandırır. Küçük bir sunucuda bu süreyi düşürün, çünkü boşta duran konteynerler için geçen 35 dakika, kullanamadığınız 35 dakikalık bellek demektir.

Durdurma işlemi silme değildir ve disklerin sessizce dolmasına neden olan durum budur. Durdurulmuş bir sandbox, çalışma alanını ve konteynerini sahiplenmeye devam eder. Sandbox ortamını silmek ancak uygulamayı tutmak, sandbox üzerinde bir DELETE işlemidir; bu işlem konteyneri ve çalışma alanını da beraberinde kaldırır. Uygulamayı silmek ise her şeyi kalıcı olarak temizler.

curl -s -XPOST $API/v1/sandboxes/$SB/stop -H "$AUTH"     # frees RAM, keeps files
curl -s -XDELETE $API/v1/sandboxes/$SB -H "$AUTH"        # container and workspace gone
curl -s -XDELETE $API/v1/apps/$APP -H "$AUTH"            # app and everything under it

Birkaç haftalık denemeden sonra docker system df, beklediğinizden daha fazla geri kazanılabilir imaj alanı gösterecektir; çünkü kendi araç setini (toolchain) çeken her uygulama geride katmanlar bırakır. docker image prune, bağlantısı kopmuş (dangling) katmanları temizler. Uyuyan bir sandbox tarafından hala referans verilen bir imaj çöp sayılmayacağı için önce GET /v1/apps komutunu kontrol edin.

Konteyner sınırının sağladığı ve sağlamadığı özellikler

Her sandbox, ayrıcalıksız bir kullanıcı olarak, salt okunur bir kök dosya sistemiyle, tüm Linux yetenekleri (capabilities) kaldırılmış, no-new-privileges ayarlanmış, bellek sınırı ve süreç limiti belirlenmiş şekilde çalışır. Proje, bu sınırın doğası konusunda şeffaftır: Paylaşımlı çekirdekli bir Linux konteyneri, güçlü bir yalıtım sınırı oluştururken zayıf bir güvenlik sınırı sunar. Bir çekirdek hatası, ana makinenin ele geçirilmesi anlamına gelir.

İki gerçek, aksiyon alınmasını gerektirir. Self-hosted yapıda sandbox içinden dış ağa erişim (egress) açıktır; bu nedenle oluşturulan kod internete, yerel ağınıza ve bulut meta veri uç noktalarına ulaşabilir. Kaynak kod içerisinde bir nftables egress alt sistemi mevcuttur ancak taşınabilir Docker Compose yapısında derleme dışı bırakılmıştır; bu da kısıtlamaların ana makine güvenlik duvarınız tarafından uygulanması gerektiği anlamına gelir. Kontrol düzlemi API'si, Docker soketini yönettiği için fiilen ana makine kök (root) yetkilerine sahiptir. Varsayılan olarak 127.0.0.1:9090 adresine bağlanır, SANDBOXD_API_AUTH_DISABLED değeri mutlaka false olarak kalmalıdır ve asla internete açılmamalıdır.

Eğer başka insanların kutunuza istem göndermesine izin vermeyi planlıyorsanız, bu model tek başına yetersizdir. Proje, sandbox ile ana makine arasına bir kullanıcı alanı çekirdeği yerleştiren ve sistem çağrısı yoğun işlerde yaklaşık 1.7 ila 4 kat yavaşlamaya neden olan SANDBOXD_RUNTIME=runsc ile gVisor kullanımını işaret eder. Daha güçlü çözüm, her kullanıcı için ayrı bir makine kullanmaktır; bu, kodlama ajanlarını geçici bir VM içinde çalıştırmak ile aynı mantıksal temele dayanır.

İki aylık bir proje üzerine inşa yapmalı mısınız?

Kişisel bir geliştirme sunucusu için evet, ancak şu bariz önlemleri almalısınız: SANDBOXD_REF sürümünü sabitleyin, /var/lib/sandboxed yedeğini alın ve önemsediğiniz her uygulamayı bir git uzak deposuna gönderin. Müşterilerin eriştiği herhangi bir şey için 1.0 sürümünü bekleyin veya bozulma durumuna karşı bütçe ayırın; çünkü geliştiriciler 0.x sürümlerinin her an değişebileceğini açıkça belirtmektedir. Geliştiriciler ayrıca Ağustos 2026 itibarıyla aylık 79 dolar karşılığında yönetilen bir kurulum hizmeti de sunmaktadır; projenin varlığını sürdürmek için bir nedeni olup olmadığını değerlendirirken bunu bilmek faydalıdır.

Bu riskin kabul edilebilir olmasının nedeni çıktıdır. sandboxd, sıradan bir git deposunda sıradan bir uygulama üretir; bu nedenle proje durursa kodu elinizde tutarsınız ve yalnızca sarmalayıcıyı kaybedersiniz. Bu, projenizin mülkiyetine sahip olan barındırılan bir oluşturucuya kıyasla çok daha iyi bir durumdur. Bu yıl sunucunuzda neyin yer almayı hak ettiğine dair daha geniş bir bakış için 2026 yılında neleri self-host etmeye değer bölümüne bakın.

FAQ

sandboxd için minimum sunucu özellikleri nelerdir?

Proje, kontrol düzlemi, Traefik ve bir küçük sandbox'ı çalıştırmak için 2 vCPU ve 4 GB RAM'in yeterli olduğunu belirtmektedir. Aynı anda birden fazla uygulama çalıştırmak istiyorsanız 8 GB RAM ve 40 GB disk alanı kullanın; çünkü çalışan her sandbox tam bir Node veya Python araç zinciri barındırır ve her çalışma alanı kendi bağımlılık ağacını diskte tutar. Sunucu kaynakları tükendiğinde, sandboxd'nin basınç temizleyicisi (pressure reaper) bellek açmak için sandbox'ları durdurur; konteynerin bellek sınırını aşan bir derleme işlemi ise çekirdek tarafından sonlandırılır: docker ps -a bu durum için 137 çıkış kodunu gösterir.

sandboxd, Dify veya OpenHands'ten nasıl farklıdır?

Bu araçlar farklı çıktılar üretir. Dify, sohbet arayüzleri ve veri getirme hatları gibi çalışma zamanında bir modele başvuran uygulamalar oluşturur. OpenHands, halihazırda sahip olduğunuz bir depoyu düzenler, komutlar çalıştırır ve mevcut kod üzerinde değişiklikler önerir. sandboxd ise bir istemden yola çıkarak sıfırdan yeni bir proje iskeleti oluşturur, bunu kendi konteyneri içinde derler ve bir önizleme URL'si üzerinden sunar; sonuçta ortaya çıkan ürün, çalışmak için bir modele ihtiyaç duymayan standart bir web uygulamasıdır.

Ajanın yazdığı kod aslında nerede barınır?

Konteyner imajı içinde değil, ana bilgisayarın dosya sisteminde barınır. Her uygulama, sandbox'ına bind mount edilen /var/lib/sandboxed/workspaces/<id>/ dizininde bir klasör alır ve dosyalar içeride /home/sandbox/workspace/app konumunda görünür. Kontrol düzlemi durumu, aynı veri dizini altındaki state/ konumunda bulunan tek bir SQLite dosyasında tutulur. Konsolun Git sekmesinden veya /v1/apps/<id>/git/commit ve /git/push uç noktaları üzerinden bir git uzak sunucusuna commit ve push yapabilirsiniz; özel uzak sunucular için kullanılan bir token, sandbox'a verilmek yerine kontrol düzlemi tarafından şifrelenmiş olarak saklanır.

sandboxd'yi internete açmak güvenli midir?

Önizleme URL'lerini ve konsolu dış dünyaya açın, ancak kontrol düzlemi API'sini asla açmayın. Bu API, ana bilgisayarda Docker'ı yönetir ve root yetkisine eşdeğerdir; bu nedenle varsayılan olarak 127.0.0.1:9090 adresine bağlanır. Ayrıca, self-hosted kurulumda sandbox'ların dış ağa erişimi açıktır; yani ajanın yazdığı kod yerel ağınıza ve bulut meta veri uç noktalarınıza ulaşabilir. Bu nedenle, sunucunun korunması gereken komşuları varsa ana bilgisayar üzerinde güvenlik duvarı kuralları uygulayın. Güvenmediğiniz kişilerden gelen istemler için, konteyner sınırına güvenmek yerine her kiracı için ayrı bir ana bilgisayar kullanın.