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 gereksinimleri ve yetersiz kaynak durumunda yaşanan sorunlar

Proje dokümantasyonu, başlangıç için 2 vCPU ve 4 GB RAM değerlerinin yeterli olduğunu belirtir. Bu değerler, kontrol düzlemi ve tek bir küçük sandbox için doğrudur; ancak aynı anda geliştirme yapan iki kişi için yetersiz kalır. Bellek bütçesini bölümlere ayırın. Traefik ve Go kontrol düzlemi düşük kaynak tüketir. Çalışan her sandbox, tam bir Node veya Python araç zinciri barındırır; kaynak kullanımı, bir npm install ve ardından gelen üretim derlemesi sırasında zirveye ulaşır. Birkaç uygulamayı aktif tutacak bir sunucu için 8 GB RAM planlayın. Swap alanını kapasite olarak değil, bir güvenlik ağı olarak değerlendirin; çünkü swap kullanan bir derleme işlemi saniyeler yerine dakikalar sürer.

Bellek tükendiğinde, birbirinden tamamen farklı iki tür hata ile karşılaşırsınız. Sandbox içerisinde, 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 durumda derleme işlemi, aracıdan hiçbir anlamlı hata mesajı almadan başarısız olur. docker ps -a komutu ilgili container için 137 çıkış kodunu gösterir ve üzerindeki docker inspect komutu "OOMKilled": true raporlar. 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 basınç temizleyici (pressure reaper) çalıştırır. Bu nedenle, küçük bir sunucuda önizlemeyi izlerken bir sandbox aniden kaybolabilir. Dosyalar güvendedir ve önizleme URL'sine gelen bir sonraki istek sandbox'ı 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, imajlar hesaba katılmadan önce birkaç gigabaytlık bağımlılık demektir. Başlangıç için 40 GB ile başlayın ve disk kullanımını izleyin:

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

Bu kılavuzun temel aldığı sürüm olan v0.3.6'da, varsayılan veri dizini fazladan e karakteri içeren /var/lib/sandboxed yoludur. Buraya /var/lib/sandboxd yazmak hiçbir sonuç vermez ve beş dakikalık kafa karıştırıcı bir sürece neden olur. Bu durum v0.3.9 (25 Ağustos 2026) sürümünde değişmiştir. Daha yeni yükleyiciler, temiz kurulumları /var/lib/sandboxd dizinine yapar ve /var/lib/sandboxed yolunu yalnızca halihazırda orada bulunan kurulumlar için korur. Daha sonraki bir sürümle kurulan bir sunucuda, aşağıdaki her komutta e içermeyen yolu kullanın.

Sabitlenmiş bir sandboxd sürümü kurun

Docker Engine, Compose eklentisi ve git öncelikle sunucuda bulunmalı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 hatası, Compose v2 eklentisinin eksik olduğu anlamına gelir. Yükleyici, eklentiyi tercih eder ancak yüklü olması durumunda bağımsız bir docker-compose ikili dosyasına geri döner; yalnızca her ikisi de mevcut olmadığında Docker Compose not found ile durur. Bu kılavuzdaki komutlar docker compose kullandığından, eklentiyi yüklemek en basit çözümdür.

Yükleyici, ağ üzerinden çekilen bir kabuk betiğidir; bu nedenle çalıştırmadan önce okuyun 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 şeklindedir. Bu değeri boş bırakmak, kurulumunuzun o sabah birleştirilen kodla yapılmasına neden olur; bu durum, sadece Temmuz 2026 içinde altı sürüm yayınlayan bir proje için önemlidir. Sürümü sabitleyin ve değişiklik günlüğünü okuduktan sonra bilinçli olarak yükseltin. 12 Ekim 2026 itibarıyla en yeni sürüm v0.3.22'dir; bu, burada sabitlenen v0.3.6 sürümünden on altı sürüm sonrasıdır.

Betik, kaynak kodunu klonlar, imajları oluşturur, yığını docker compose up -d ile 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 bir API'nin kimlik bilgisidir.

curl http://127.0.0.1:9090/healthz

Bu komut, kontrol düzlemi ayağa kalktığında ok çıktısını verir. Eğer hiçbir şey yazdırmazsa yığın başlamamış demektir: hangi servisin kapalı olduğunu görmek için ~/.sandboxd/src dizininden docker compose ps komutunu, nedenini anlamak için ise docker compose logs sandboxd komutunu çalıştırı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ı, bir A kaydı ile sunucunun IP adresine yönlendirin. Ardından ~/.sandboxd/src içindeki .env değişkenlerini 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ı kapsar. HTTP-01 ile her yeni sandbox kendi sertifika düzenleme sürecine ihtiyaç duyar ve yoğun bir geliştirme gününde Let's Encrypt hız sınırlarına (rate limits) takılabilirsiniz. DNS-01 sınaması ile wildcard sertifikaları bölümü bu sürecin DNS tarafını açıklar.

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.

Alan adı, DNS ve sertifika süreçlerini tamamen atlamak isterseniz, geliştiriciler artık sandboxd Cloud hizmetini sunmaktadır. Bu hizmet, Ekim 2026 itibarıyla sunucu başına aylık 9.99 dolar veya lansman indirimiyle 4.99 dolar karşılığında sandboxd.io altında genel bir HTTPS adresi sağlar. v0.3.6 sürüm sabitlemesi ile kullanmadan önce hangi sürümün gerekli olduğunu kontrol edin.

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

Kod, ana makinede veri dizini altında tutulur. v0.3.6 kurulumunda her çalışma alanı /var/lib/sandboxed/workspaces/<id>/ konumunda düz bir dizindir ve container içine bind mount edilir; uygulamanın dosyaları ise sandbox içinde /home/sandbox/workspace/app konumunda yer alır. Kontrol düzlemi durumu state/sandboxd.db konumundaki tek bir SQLite dosyasında, şifrelenmiş aracı kimlik bilgileri ise agent-auth/ konumunda saklanır. Hiçbir veri container katmanları içinde gizli tutulmaz; bu nedenle yedekleme, dizinin kopyalanması ve ilgili veritabanı dosyasının alınmasından ibarettir. VPS üzerinde restic yedeklemeleri 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, sistemin yerleşik bir parçası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":"todo-first-pass"}'

Push işlemi her zaman yeni bir dala (branch) yapılır. branch parametresini belirtmezseniz, varsayılan olarak sandboxd/<slug>-<shortsha> kullanılır. main, master ve içe aktarma yaptığınız dal (branch) reddedilir; bu nedenle birleştirme (merge) işlemini uzak tarafta yapmalısınız.

Özel bir uzak depo (private remote), konsolda Ayarlar (Settings) ve Git kimlik bilgileri (Git credentials) altında bir kez tanımlanan kişisel bir erişim belirteci (personal access token) gerektirir. 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 gerçekleştiremez. 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 onu 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.

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

Her sandbox, yetkisiz 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ç limitiyle çalışır. Proje, bu sınırın ne anlama geldiği konusunda şeffaftır: Paylaşımlı çekirdekli bir Linux container yapısı, güçlü bir izolasyon sınırı olsa da zayıf bir güvenlik sınırıdır. 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 kodda bir nftables çıkış 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 root yetkisine 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 kullanıcı alanında çalışan bir çekirdek yerleştiren gVisor ve SANDBOXD_RUNTIME=runsc kullanımını önermektedir. Projenin kendi ölçümlerine göre bu yapı, paket kurulumlarını yaklaşık 1,7 kat, sistem çağrısı yoğun işleri ise yaklaşık 4 kat yavaşlatmaktadır. Daha güçlü çözüm, her kullanıcı için ayrı bir makine kullanmaktır; bu, kodlama ajanlarını tek kullanımlık bir VM içinde çalıştırmak ile aynı mantıktır.

İki aylık bir proje üzerine inşaat yapılmalı mı?

Kişisel bir derleme sunucusu için evet, ancak bariz önlemleri almanız şartıyla: SANDBOXD_REF sürümünü sabitleyin, veri dizinini yedekleyin (v0.3.6 sürümünde /var/lib/sandboxed, v0.3.9 veya sonraki temiz kurulumlarda /var/lib/sandboxd), ve önemsediğiniz her uygulamayı bir git uzak deposuna gönderin. Müşterinin eriştiği herhangi bir şey için 1.0 sürümünü bekleyin veya bozulma ihtimaline 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 yönetilen bir kurulum hizmeti de sunmaktadır; Ekim 2026 itibarıyla kurulum için 199 dolar ve aylık 79 dolar işletim ücreti talep edilmektedir. Projenin varlığını sürdürmek için bir nedeni olup olmadığını değerlendirirken bu bilgiyi göz önünde bulundurmak 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 durum, projenizin mülkiyetini elinde tutan barındırılan bir derleyiciden çok daha iyi bir konumdur. Bu yıl sunucunuzda yer almayı hak eden projelerin daha geniş bir görünümü için 2026 yılında self-host etmeye değer olanlar bölümüne bakın.

FAQ

sandboxd için minimum sunucu özellikleri nelerdir?

Proje, kontrol düzlemi, Traefik ve bir adet 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, mevcut 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, bir önizleme URL'si üzerinden sunar ve sonuçta ortaya model gerektirmeyen standart bir web uygulaması çıkar.

Ajanın yazdığı kod gerçekte nerede barınır?

Konteyner imajı içinde değil, ana makine dosya sisteminde. Her uygulama, v0.3.6 kurulumunda /var/lib/sandboxed/workspaces/<id>/ dizininde (v0.3.9 veya sonraki sürümlerin temiz kurulumunda /var/lib/sandboxd/workspaces/<id>/ dizininde) bir klasör alır; bu klasör sandbox'a bind mount edilir 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ı aracılığıyla bir git uzak deposundaki yeni bir dala commit ve push yapabilirsiniz; özel uzak depolar 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 açın, ancak kontrol düzlemi API'sini asla açmayın. Bu API, ana makinede 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 kurulumlarda 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 makine güvenlik duvarı kuralları ekleyin. Güvenmediğiniz kişilerden gelen istemler için, konteyner sınırına güvenmek yerine her kiracı için ayrı bir ana makine çalıştırın.