Dormice ile Agent Sandbox'ını Kendi VPS'inde Çalıştırma

Dormice nedir, ne değildir

Dormice, self-hosted bir agent sandbox çözümüdür: Sahip olunan bir Linux VPS üzerinde çalışan tek bir daemon bulunur. Agent kodu, yalıtılmış bir container içinde güvenilmeyen kod çalıştırmak için bu daemon'a HTTP üzerinden istek gönderir. Program bir sandbox'ı adıyla ister, sandbox hangi durumda olursa olsun aynı sandbox'ı alır, içinde bir komut çalıştırır ve çıktıyı okur. Sandbox, programatik bir kaynaktır; oturum açılan bir makine değildir.

Bu yapı, bir agent'a bütün bir bilgisayar vermekten farklıdır. Bir coding agent için geçici bir VM, SSH ile bağlanılan, agent'ın bozmasına izin verilen ve ardından silinen bir kutudur. Dormice bir katman daha aşağıda yer alır: Programda kod zaten mevcutken ve bu kodu güvenli biçimde çalıştıracak bir yer gerektiğinde kullanılan execution API'sidir. Bütün makinenin iş birimi olduğu durumlarda geçici VM kullanılmalıdır. Tek bir exec çağrısının iş birimi olduğu ve günde yüz çağrı için yüz VM çalıştırmak istenmediği durumlarda Dormice kullanılmalıdır.

Proje kendisini E2B uyumlu olarak tanımlar. E2B, birçok agent framework'ünün client library'sini içe aktardığı, barındırılan bir sandbox hizmetidir. Dormice aynı protokolü kendi URL prefix'leri altında sunar. Böylece resmi e2b package'i temel alınarak yazılmış bir uygulama, istekler kişinin kendi sunucusuna yönlendirildiğinde çalışmaya devam eder. Uygulama kodu değiştirilmez. İki URL ve bir API key prefix'i değiştirilir.

Agent sandbox'larının "SQLite'ı" pratikte ne anlama gelir?

SQLite, işlettiğiniz bir servis yerine uygulamanın içine gömdüğünüz bir veritabanıdır. Dormice bu benzetmeyi doğrudan kullanır. Tek bir daemon, ledger için tek bir SQLite dosyası ve tek bir TCP portu bulunur. Kubernetes, ayrı bir veritabanı veya scheduler gerekmez. Daemon, ledger dosyasının yanında bir lock alır. Ledger ile bulduğu makinenin birlikte kullanılamayacağını tespit ederse başlatmayı reddeder. Böylece split-brain durumu sessizce oluşamaz. Tasarım tek makine içindir. Birden fazla host'a yayılan bir fleet gerekiyorsa README açıkça başka bir çözüm seçilmesini söyler. Bu uyarı dikkate alınmalıdır.

Fikrin ikinci bölümü maliyetle ilgilidir. Hosted sandbox, var olduğu her saniye için ücretlendirildiğinden hosted sandbox'lar tasarım gereği geçicidir. Dormice zaten ücretini ödediğiniz donanım üzerinde çalışır. Bu nedenle sandbox'ları kalıcıdır ve çalışmadan bekledikleri süre uzadıkça maliyetleri düşer. Bir sandbox kademeli olarak soğur: active, ardından frozen, sonra stopped ve son olarak archived olur. Her acquire işlemi, sandbox'ı ulaştığı kademeden yeniden çalışır duruma getirir.

Anlaşılması gereken bölüm freezing işlemidir. Her agent'ın sandbox'ını kalıcı olarak tutmayı uygun maliyetli hale getiren işlem budur. Aşağıdaki değerler projenin yayımladığı, kendi donanımı üzerinde ölçülmüş rakamlardır. Sizin donanımınız için geçerli olmayabilir.

[
  {
    "label": "Active, holding 1 GiB",
    "resident_memory_mib": 1024,
    "wake_ms": 0
  },
  {
    "label": "Frozen",
    "resident_memory_mib": 5,
    "wake_ms": 50
  }
]

1024 MiB bellek kullanan boşta bir sandbox frozen durumuna geçtiğinde resident bellek kullanımı 5 MiB seviyesine düşer ve yaklaşık 50 ms içinde geri gelir. Süreçler mevcut durumları korunarak duraklatılır ve devam ettirilir. Bu nedenle uzun süre çalışan bir agent, freeze işlemi boyunca shell durumunu ve yarım kalan işlerini korur. Kapasite planlamasını buna dayandırmadan önce işlemi kendi host'unuzda yeniden üretin.

Kurulumdan önce host üzerinde bulunması gerekenler

Host, x86_64 üzerinde çalışan Ubuntu veya Debian olmalıdır. Installer için root yetkisi gerekir. Daemon, loop mount işlemleri gerçekleştirdiği ve cgroup'lara yazdığı için çalışma zamanında root olarak çalışır.

Sandbox'lar, gVisor ile Docker üzerinde çalışır. gVisor, container ile host kernel'i arasına userspace kernel yerleştiren bir container runtime'dır. Her sandbox'ın kullandığı runsc runtime'ını sağlar. Daemon, Node 22 veya daha yeni bir sürümle çalışır. Installer kendi Node kopyasını içerdiğinden sistemdeki Node sürümü değiştirilmez.

Swap bulunmalıdır ve vm.swappiness değeri 100 olmalıdır. Bu bir performans ayarı önerisi değil, işlevsel bir gereksinimdir. Dondurma işlemi, boşta olan bir sandbox'ın belleğini swap alanına taşır. gVisor, sandbox belleğini shared memory olarak tutar. Kernel, varsayılan swappiness değerinde shared memory'yi swap alanına taşımaz. Proje, varsayılan değerde geri kazanılan belleğin 0 byte olduğunu, değer 100 olduğunda ise belleğin yüzde 99.5'inin geri kazanıldığını ölçmüştür. Kernel'in gerçekten kullandığı değeri kontrol edilmelidir. Bazı cloud image'ları vm.swappiness = 0 değerini, okunması genellikle düşünülmeyen bir dosyada tanımlar.

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness çıktısı vm.swappiness = 100 olmalı, swapon --show ise bir swapfile listelemelidir. Swappiness değeri 0 olarak görünüyorsa her freeze işlemi hiçbir şey yapmaz ve her boşta sandbox için tam bellek maliyeti devam eder.

Ubuntu üzerine Dormice kurulumu

Belgelenen kurulum yöntemi, bash komutuna tek bir pipe ile veri aktarmaktır:

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh | bash

Çalıştırmadan önce bu dosyayı indirin ve inceleyin. Bu script root olarak çalışır ve host üzerinde değişiklik yapar: eksikse Docker kurar, gVisor ve Caddy bileşenlerini checksum doğrulamasıyla indirir, bir swapfile oluşturur, systemd unit dosyaları yazar ve firewall kuralları ekler.

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh -o dormice-install.sh
less dormice-install.sh
sudo bash dormice-install.sh --swap-gb 8

--swap-gb swapfile boyutunu belirler ve varsayılan değer olarak 16 kullanır. Bu değer, küçük bir VPS için diskin büyük bir bölümünü ayırır. --mirror cn indirmeleri Çin ana karasından erişilebilen mirror adreslerine yönlendirir. Installer yeniden çalıştırıldığında kod yükseltilir ve mevcut yapılandırma ile beklenen durum arasındaki sapmalar düzeltilir. API token hiçbir zaman otomatik olarak yenilenmez.

Kod /opt/dormice konumuna, yapılandırma /etc/dormice/env konumuna, sandbox verileri /var/lib/dormice konumuna, dormice ve dor komutları ise /usr/local/bin konumuna yazılır. Installer, kurulum sırasında API token oluşturur ve bunu 600 moduyla /etc/dormice/env konumuna yazar.

Kurulum için kullanılabilecek etiketlenmiş bir release yoktur. 4 August 2026 itibarıyla repository herhangi bir git tag veya GitHub release içermemektedir. Bu nedenle installer main repository'sini clone eder ve o sabah eklenen içerik kurulur. Dolayısıyla bir sürümü sabitlemek, gerçekten kurduğunuz commit değerini kaydetmek anlamına gelir.

git -C /opt/dormice rev-parse HEAD

Bu hash değerini deploy notlarıyla birlikte kaydedin. Bir upgrade sonrasında bir şey bozulduğunda geri dönüş için tek başvurabileceğiniz değer bu commit olur. İstenebilecek bir version number yoktur.

Installer, işlemin sonunda dor doctor komutunu çalıştırır. Bu komut, host üzerinde salt okunur bir kontrol gerçekleştirir ve runtime'ın çalıştığını doğrulamak için gerçek gVisor container'larını başlatır. Yalnızca package listesine güvenmez. Daemon düzgün çalışmadığında bu komutu yeniden çalıştırın.

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice çıktısında active görülmelidir. Çıktı failed ise journalctl -u dormice -n 50 nedeni içerir. Başlatma hatasının nedeni genellikle daemon'ın kendisi değil, swap veya gVisor ön koşuludur.

Installer ayrıca host üzerine Caddy kurar. Bu nedenle firewall yapılandırmasının tamamlandığına karar vermeden önce hangi servislerin listening durumda olduğunu kontrol edin.

sudo ss -lntp

Daemon 127.0.0.1:3676 adresine bind olur ve tasarım gereği bunu değiştirecek bir ayarı yoktur. Laptop üzerinden erişim sağlamak bilinçli bir işlem olmalıdır. En basit yöntem SSH tunnel kullanmaktır.

ssh -L 3676:127.0.0.1:3676 root@your-server

Tunnel açıkken laptop üzerindeki http://127.0.0.1:3676/console web console olarak kullanılabilir. Token ile bir kez oturum açıldığında token, httpOnly session cookie haline gelir. Böylece token'ın kendisi sayfanın okuyabileceği bir yerde saklanmaz. Buradaki Connect sayfası, kendi endpoint'inize yönlendirilmiş, kopyalanıp yapıştırılmaya hazır client snippet'ları görüntüler.

Korumalı alan oluşturma ve kod çalıştırma

Tek bir işlem korumalı alan oluşturur: acquire. İşlem idempotent davranır; aynı anahtar her zaman aynı korumalı alanı döndürür. Gerektiğinde korumalı alan oluşturulur, uyandırılır, başlatılır veya geri yüklenir. Diğer tüm fiiller, daha önce hiç görülmemiş bir anahtar için 404 döndürür. dor CLI bileşeninde acquire fiili yoktur. Bu nedenle ilk korumalı alan konsoldan veya bir istemci kitaplığından oluşturulur.

Konsol yolu en hızlı seçenektir. Tünel üzerinden /console adresini açın ve my-agent adlı bir korumalı alan oluşturun. Ardından CLI üzerinde bu korumalı alanla çalışılabilir.

sudo grep DORMICE_API_TOKEN /etc/dormice/env
export DORMICE_ENDPOINT=http://127.0.0.1:3676
export DORMICE_API_TOKEN=paste-the-value-here
dor sandbox ls
dor sandbox exec my-agent 'python3 --version'

dor sandbox ls her korumalı alanı yaşam döngüsü durumuyla birlikte listeler. Böylece bir korumalı alanın active durumundan frozen durumuna geçişi izlenebilir. dor sandbox exec, Python 3.12 sürümünü yazdırır. Bunun nedeni, stock image içinde Ubuntu 24.04, Python 3.12, Node 24, git ve ripgrep bileşenlerinin önceden kurulu olmasıdır. Kimlik doğrulama hatası, kopyalanan token satırında değişken adının da yer aldığını gösterir.

Dosyalar dor sandbox push my-agent ./script.py ile gönderilir ve /home/user/script.py konumuna yerleştirilir. dor sandbox pull my-agent notes.txt ise bir dosyayı geri getirir. Yerel dosya fiillerinde dosya başına 16 MiB sınırı vardır. E2B file surface ise akış aktarımını destekler ve tek sınır olarak korumalı alan disk kotasını kullanır.

Destroying, veri kaybına yol açan tek fiildir. Bu durum projenin ne kadar eski olduğuna da iyi bir örnektir: ana README ve paketle birlikte gelen agent skill dor sandbox destroy <key> komutunu belgelerken CLI package README dor sandbox release <key> komutunu belgeler. Bunun yerine kendi derlemenizde dor sandbox --help komutunu çalıştırın ve bu çıktıyı esas alın.

Mevcut E2B kodunu kendi sunucunuza yönlendirin

Bunun önemli olmasının nedeni budur. npm üzerindeki resmi e2b paketi, herhangi bir değişiklik yapılmadan Dormice ile iletişim kurar. SSH tüneli açıkken bunu dizüstü bilgisayarınızdan çalıştırın. Böylece sunucuda yeni bir port dinlemeye başlamaz.

npm init -y
npm i e2b tsx

import { Sandbox } from 'e2b';

const sbx = await Sandbox.create({
  apiKey: `e2b_${process.env.DORMICE_API_TOKEN}`,
  apiUrl: 'http://127.0.0.1:3676/e2b/api',
  sandboxUrl: 'http://127.0.0.1:3676/e2b/envd',
});

const result = await sbx.commands.run('python3 -c "print(6 * 7)"');
console.log(result.exitCode, result.stdout);

await sbx.kill();

DORMICE_API_TOKEN=paste-the-value-here npx tsx index.ts

Başarılı bir çalıştırmada çıkış kodu 0 ve 42 görüntülenir. API anahtarı, başına e2b_ eklenmiş Dormice token'ınızdır. Uyumluluk katmanı bu biçimi bekler.

Uyumluluk bir stub uygulamasından ibaret değildir. Streaming stdout ve stderr, arka plan komutları, etkileşimli PTY, imzalı upload ve download URL'leri, dizin izleme ve port proxy özelliklerinin tümü, projenin uçtan uca test paketi tarafından gerçek bir Docker ve gVisor daemon'ı üzerinden resmi paket kullanılarak test edilir. Gerçek bir geçiş yapmadan önce birkaç farklılık dikkate alınmalıdır:

• Template build işlemleri uygulanmamıştır. Template, kendiniz oluşturup dor template add ile kaydettiğiniz bir Docker image'ıdır ve Sandbox.create('name') bunu çözümler. Kaydedilmemiş bir ad, varmış gibi davranılmak yerine 404 döndürür.
• E2B arayüzü üzerinden oluşturulan sandbox'lara gerçek deadline değerleri uygulanır. Bunun nedeni E2B semantiğinin bunları gerektirmesidir. Native API üzerinden oluşturulan sandbox'lara hiçbir zaman deadline uygulanmaz.
• Dondurulan bir sandbox, süreçlerini korur ve onları çalışmanın ortasından devam ettirir. Bu nedenle buradaki pause ve resume işlemleri, alışık olabileceğiniz stop ve cold start işlemleri değildir.

Sandbox'ın durdurduğu ve durdurmadığı şeyler

gVisor, container system call'larını userspace içinde intercept eder ve bunları kendisi işler. Bu nedenle sandbox içindeki kod, doğrudan host kernel ile iletişim kurmaz. Sandbox içinde her şey, uid 1000 olan ayrıcalıksız bir kullanıcı olarak çalışır. Bu birleşim olağan durumları yönetir: `rm -rf /` çalıştıran, diski dolduran veya bir şey çökene kadar fork eden oluşturulmuş bir script, yalnızca kendi sandbox'ına zarar verir ve orada durur.

Ancak durdurmadığı durumlar da vardır. Bunların her biri sizin sorumluluğunuzdadır.

• Sandbox'ın dışarıya açık network erişimi vardır. Oluşturulan kod istediği dosyayı indirebilir ve bulduğu her şeyi gönderebilir. Installer'ın network hardening yapılandırması iki belirli işlemi kapsar: Container trafiğini, cloud'un instance credentials bilgilerini erişebilen her şeye ilettiği yer olan 169.254.0.0/16 cloud metadata service adres aralığına düşürür ve Docker'ın `daemon.json içindeki "icc": false ile container'lar arası trafiği devre dışı bırakır. Bunun dışında hiçbir şey engellenmez. sudo iptables -S DOCKER-USER` dosyasını okuyun ve sandbox'ın erişmemesi gereken private range'ler için kendi DROP kurallarınızı ekleyin.
• Docker, kendi kurallarını firewall kurallarınızın önüne ekler. Bu nedenle yayınlanmış bir container port'u internetten yanıt verebilirken ufw bu portun kapalı olduğunu varsayabilir. Bu host üzerinde herhangi bir portu dışarı açmadan önce Docker'ın portları ufw üzerinden nasıl yayınladığını ve VPS için ufw firewall temellerini okuyun.
• gVisor, hypervisor değil userspace kernel'dir. Bu bilinçli bir tercihtir. Freeze işlemi için sandbox'ların process olması gerekir. KVM zorunluluğu getirilmesi, kurulumun her yerde yapılmasını engeller. Threat model donanım sanallaştırması gerektiriyorsa Firecracker sınıfı izolasyon kullanın ve bunun getirdiği operasyonel maliyeti kabul edin.
• API token, client tarafındaki güvenlik sınırının tamamıdır. `DORMICE_API_TOKEN` değerine sahip olan her şey, makinedeki tüm sandbox'ları oluşturabilir, okuyabilir ve silebilir. Agent process'i için kendi VPS üzerinde en az ayrıcalıklı kullanıcı hesabınızı oluşturun ve token'ı bir SSH key'e gösterdiğiniz özenle koruyun. VPS üzerinde Claude Code'u güvenli şekilde çalıştırma konusundaki alışkanlıklar doğrudan geçerlidir.

Daemon'ın kendisi host üzerinde root olarak çalışır. gVisor, host'u sandbox içindeki koddan korur. Ancak host'u daemon'dan veya token'ı elinde bulunduran kişiden koruyan hiçbir şey yoktur. Bu nedenle Dormice'ı çalıştıran makine yalnızca bu iş için kullanılmalıdır. Agent, MCP (model context protocol) üzerinden araçlara da erişiyorsa aynı nedenle bu MCP sunucularını ayrı bir VPS üzerinde tutun.

4 GB ve 8 GB kapasiteye kaç sandbox sığar?

Belleği iki unsur tüketir: ana makinenin kendi temel bellek kullanımı ve o anda çalışan her sandbox'ın çalışma kümesi. Ubuntu, Docker ve daemon için yaklaşık 1 GB ayırın. Ardından kalan belleği bir sandbox'ın gerçekte kullandığı bellek miktarına bölün. Birkaç dosya okuyan Python betiğini çalıştıran sandbox yaklaşık 200 ila 300 MiB bellek kullanır. Derleyici veya tam bir test paketi çalıştıran sandbox ise 1 gibibaytı aşabilir.

[
  {
    "host": "4 GB VPS",
    "active_at_512_mib": 6,
    "active_at_1_gib": 3,
    "frozen_on_16gb_swap": 16
  },
  {
    "host": "8 GB VPS",
    "active_at_512_mib": 14,
    "active_at_1_gib": 7,
    "frozen_on_16gb_swap": 16
  }
]

Her biri 512 MiB kullanıyorsa 4 GB VPS aynı anda yaklaşık 6 sandbox'ı çalışır durumda tutabilir. Her biri tam 1 gibibayt kullanıyorsa bu sayı 3 olur. 8 GB VPS'te bu değerler sırasıyla 14 ve 7 olur. Bunlar eşzamanlı çalışma için üst sınırlardır ve benchmark sonucuna değil aritmetik hesaba dayanır. Bu nedenle kendi yükünüz çalışırken free -m değerini izleyin.

Dondurulmuş sandbox'lar RAM yerine swap ile sınırlanır. Tasarımın temel amacı budur. 1 gibibayt tutan dondurulmuş bir sandbox, yaklaşık aynı miktarda swap alanı kullanmaya devam eder ve RAM'de neredeyse hiç yer kaplamaz. Bu nedenle yükleyicinin varsayılan 16 GB swapfile'ı yaklaşık 16 sandbox'ı bekletebilir. Bu sınır aşıldığında sandbox'ların durdurulmuş aşamaya geçmesi gerekir; bu aşamada yalnızca disk alanı kullanırlar. Buradaki gerçek uzun vadeli sınır disktir: her sandbox kendi dosya sistemini korur ve her biri bir node_modules dizini içeren birkaç düzine agent, bellek kullanımı önem kazanmadan çok önce küçük bir volume'ü doldurur.

Dondurma, durdurma, arşivleme: yaşam döngüsü ayarları

Varsayılan ayarlar, 10 dakika boyunca boşta kaldıktan sonra dondurma, 3 gün sonra durdurma ve arşivleme yapılandırılmışsa 7 gün sonra arşivlemedir. stopAfterSeconds değerinin null olarak ayarlanması, sürekli hazır bir agent sağlar: boşta kaldığında donabilir, ancak hiçbir zaman cold start yapmaz.

Arşivleme isteğe bağlıdır ve daemon bu konuda açık davranır. Dört DORMICE_S3_* değişkenini ayarladığınızda, durdurulmuş bir sandbox'ın diski tar ve zstd ile paketlenir, S3 uyumlu herhangi bir bucket'a aktarılır ve yerel olarak serbest bırakılır. Bu bucket, başka bir makinenizde self-host ettiğiniz bir MinIO bucket'ı olabilir. Değişkenleri ayarlamazsanız sandbox'lar sonsuza kadar durdurulmuş durumda bekler. Arşivleme isteyen bir policy de sessizce yok sayılmak yerine reddedilir. Geri yükleme işlemleri sessiz gerçekleşmez: sonraki acquire isteği hemen restoring durumunu ve bir ilerleme değerini döndürür. Disk geri yüklendiğinde durum ready olarak değişir.

Henüz buna güvenilmeli mi?

Kısa cevap: Yeniden oluşturamayacağınız hiçbir iş için henüz güvenilmemelidir. Depodaki ilk commit tarihi 8 July 2026'dır. 4 August 2026 itibarıyla 446 yıldız, 37 fork ve Apache-2.0 lisansı görünmektedir; ayrıca hiç etiketlenmiş sürüm bulunmamaktadır. README içindeki durum satırında da üretim kullanımı için hiçbir şeyin hazır olmadığı belirtilir.

Bu birleşim belirli bir risk profili oluşturur. Yükleyici main öğesini izlediği için kod değişebilir. Arayüz henüz kararlılığa ulaşmamıştır. Aynı repository içindeki iki dosyada delete fiilinin iki farklı adla kullanılması bunun açık bir örneğidir. Ayrıca dört haftalık bir proje basitçe durabilir. Çünkü hiçbir lisans hükmü projenin sürdürülmesini zorunlu kılmaz.

E2B uyumluluğu bu riski yönetilebilir hale getirir. Uygulamanız, arkasında barındırılan bir uygulama bulunan bir protokolle iletişim kurar. Bu nedenle Dormice durursa iki URL'yi değiştirerek çalışmaya devam edebilirsiniz. Agent'ınızı native API yerine E2B yüzeyine göre yazarsanız bu çıkış seçeneğini korursunuz. Native @dormice/sdk paketi de henüz npm üzerinde değildir. Kullanılması, paketin repository'den derlenmesini gerektirir. Bu da uyumlu yolla başlamanın ikinci nedenidir.

Kaybetmeyi göze alabileceğiniz bir ortamda çalıştırın. Host'u bir script ile yeniden oluşturun. Token'ı her prompt'tan ve her commit'ten uzak tutun. Saklamaya değer verileri kendi yedekleme takviminize göre sandbox'ların dışına çıkarın.

FAQ

Dormice üretim kullanımı için hazır mı?

Hayır. Proje de bunu açıkça belirtiyor. README içindeki durum satırında henüz hiçbir şeyin üretim kullanımı için hazır olmadığı yazıyor. Ayrıca 4 August 2026 itibarıyla repository yaklaşık dört haftalık; git tag veya release bulunmuyor. Bu nedenle sabitlenebilecek bir sürüm numarası yok. Installer, main branch'ini clone ediyor. Bu da her çalıştırmada en yeni commit'in alınacağı anlamına gelir. Her kurulumdan sonra git -C /opt/dormice rev-parse HEAD değerini kaydedin. Değerli verileri sandbox'ların dışında tutun.

Dormice, agent'a disposable VM vermekten nasıl farklıdır?

Disposable VM, bir oturum için oluşturulan ve ardından silinen, SSH erişimli bir makinedir. Dormice ise bir execution API'dir. Programınız önce acquire, ardından exec çağrısı yapar ve arada shell session olmadan stdout ile exit code alır. VM, bir süre boyunca bütün bir bilgisayara ihtiyaç duyan insan veya agent için uygundur. Dormice ise günde birçok kez generated code çalıştıran ve her çalıştırmada makine ölçeğinde kurulum ve kaldırma işlemleri yapmak istemeyen uygulamalar için uygundur.

Official E2B SDK gerçekten kod değişikliği olmadan çalışıyor mu?

Evet, configuration değişiklikleriyle çalışıyor. apiUrl ve sandboxUrl değerlerini daemon üzerindeki /e2b/api ve /e2b/envd değerlerine yönlendirin. Dormice token'ını e2b_ prefix'iyle API key olarak gönderin. Command execution, PTY sessions, file transfer, signed URLs ve port proxy işlemlerinin tamamı, official package üzerinden çalışan projenin end-to-end suite'i tarafından kapsanır. Template building önemli bir eksikliktir: e2b template build uygulanmamıştır. Bu nedenle template, oluşturup dor template add ile register ettiğiniz bir docker image'dır.

4 GB VPS üzerinde kaç sandbox çalışabilir?

Her sandbox 512 MiB kullanıyorsa, işletim sistemi, Docker ve daemon için yaklaşık 1 GB ayrıldıktan sonra aynı anda yaklaşık 6 sandbox awake durumda tutulabilir. Her sandbox tam bir gibibyte kullanıyorsa bu sayı 3 olur. Frozen sandbox'lar ise swap ile sınırlıdır. Installer'ın varsayılan 16 GB swapfile'ı, her biri bir gibibyte kullanmış olan yaklaşık 16 sandbox'ı park edebilir. Gerçek yük altında free -m ile kendi ölçümünüzü yapın. Çünkü bir test suite çalıştıran sandbox, küçük bir script çalıştıran sandbox'ın kullandığı belleğin birkaç katını kullanabilir.

Dormice neden vm.swappiness değerinin 100 olmasını gerektiriyor?

Bir sandbox'ı freeze etmek, kullanılmayan belleğini swap alanına taşımak anlamına gelir. gVisor, sandbox belleğini shared memory olarak tutar. Linux kernel, varsayılan swappiness değerinde shared memory'yi swap alanına taşımaz. Bu nedenle varsayılan değerde freeze işlemi hiçbir belleği geri kazanamaz ve sandbox tam bellek tüketimi oluşturmaya devam eder. Proje, varsayılan değerde 0 byte, 100 değerinde ise yüzde 99.5 bellek geri kazanıldığını ölçmüştür. Config dosyalarını okumak yerine effective değeri sysctl vm.swappiness ile kontrol edin. Bazı cloud image'lar 0 değerini kullanıma hazır olarak sağlayabilir.