Jak hostować Dormice dla agentów AI na własnym VPS

Czym jest, a czym nie jest Dormice

Dormice to samodzielnie hostowane środowisko izolowane (sandbox) dla agentów: jeden demon na posiadanym serwerze Linux VPS, z którym kod agenta komunikuje się przez HTTP w celu uruchamiania niezaufanego kodu w odizolowanym kontenerze. Program żąda środowiska o określonej nazwie, otrzymuje to samo środowisko niezależnie od jego poprzedniego stanu, wykonuje w nim polecenie i odczytuje wynik. Środowisko to zasób programistyczny, a nie maszyna, do której loguje się użytkownik.

Jest to podejście odmienne od udostępniania agentowi całego komputera. Jednorazowa maszyna wirtualna dla agenta programistycznego to środowisko, do którego logujesz się przez SSH, pozwalasz agentowi na jego zniszczenie, a następnie usuwasz. Dormice znajduje się poziom niżej: to API wykonawcze, z którego korzysta program, gdy posiada już kod i potrzebuje bezpiecznego miejsca do jego uruchomienia. Użyj jednorazowej maszyny wirtualnej, gdy jednostką pracy jest cała maszyna. Użyj Dormice, gdy jednostką pracy jest pojedyncze wywołanie exec i chcesz wykonywać ich setki dziennie bez konieczności tworzenia setek maszyn wirtualnych.

Projekt jest kompatybilny z E2B. E2B to hostowana usługa typu sandbox, której biblioteki klienckie są już importowane przez wiele frameworków dla agentów. Dormice obsługuje ten sam protokół pod własnymi prefiksami URL, dzięki czemu aplikacja napisana z użyciem oficjalnego pakietu e2b działa nadal po przekierowaniu jej na własny serwer. Kod aplikacji nie ulega zmianie. Zmieniają się jedynie dwa adresy URL oraz prefiks klucza API.

Co w praktyce oznacza określenie "SQLite dla piaskownic agentów"

SQLite to baza danych, którą się osadza, a nie usługa, którą się zarządza, a Dormice bezpośrednio zapożycza to porównanie. Jeden demon, jeden plik SQLite dla rejestru, jeden port TCP. Brak Kubernetes, brak oddzielnej bazy danych, brak harmonogramu. Demon zakłada blokadę obok swojego rejestru i odmawia uruchomienia, gdy rejestr i maszyna, na której się znajduje, nie pasują do siebie, dzięki czemu nie może dojść do cichego wystąpienia problemu split-brain. Projekt zakłada działanie na jednej maszynie. Jeśli wymagana jest flota obejmująca wiele hostów, plik README wprost zaleca wybór innego rozwiązania i należy się do tego zastosować.

Druga część tej koncepcji dotyczy kosztów. Hostowana piaskownica nalicza opłaty za każdą sekundę istnienia, dlatego hostowane piaskownice są z założenia jednorazowe. Dormice działa na sprzęcie, za który już płacisz, więc jego piaskownice są trwałe i stają się tańsze, im dłużej pozostają nieaktywne. Piaskownica przechodzi w stan spoczynku stopniowo: aktywna, zamrożona, zatrzymana, zarchiwizowana. Każde żądanie dostępu przywraca ją z dowolnego poziomu, do którego dotarła.

Zamrażanie to mechanizm, który warto zrozumieć, ponieważ to on sprawia, że utrzymywanie piaskownicy każdego agenta na zawsze jest przystępne cenowo. Poniżej przedstawiono opublikowane dane projektu, zmierzone na jego sprzęcie, a nie na Twoim.

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

Bezczynna piaskownica zajmująca 1024 MiB pamięci po zamrożeniu ogranicza zużycie pamięci rezydentnej do 5 MiB i powraca do działania w około 50 ms. Procesy są zawieszane i wznawiane w miejscu, więc długo działający agent zachowuje stan powłoki i niedokończoną pracę po zamrożeniu. Przed zaplanowaniem wydajności na podstawie tych danych, należy przeprowadzić weryfikację na własnym hoście.

Wymagania wstępne dla hosta

Host musi działać pod kontrolą Ubuntu lub Debiana na architekturze x86_64, a instalator wymaga uprawnień root. Demon zachowuje uprawnienia root w czasie wykonywania, ponieważ wykonuje operacje loop mount oraz zapisuje cgroups.

Piaskownice działają w środowisku Docker z wykorzystaniem gVisor (środowisko uruchomieniowe kontenerów, które umieszcza jądro w przestrzeni użytkownika pomiędzy kontenerem a jądrem hosta), co zapewnia runsc używane przez każdą piaskownicę. Demon wymaga Node 22 lub nowszego; instalator dostarcza własną kopię, więc systemowy Node pozostaje nienaruszony.

Wymagane jest istnienie partycji lub pliku wymiany (swap), a wartość vm.swappiness musi wynosić 100. Nie jest to zalecenie optymalizacyjne, lecz wymóg funkcjonalny. Mechanizm zamrażania działa poprzez przenoszenie pamięci bezczynnej piaskownicy do swap; gVisor przechowuje pamięć piaskownicy jako pamięć współdzieloną, a jądro nie przenosi pamięci współdzielonej przy domyślnej wartości swappiness. Projekt wykazał odzysk 0 bajtów przy wartości domyślnej oraz 99,5 procent przy wartości 100. Należy sprawdzić wartość faktycznie używaną przez jądro, ponieważ niektóre obrazy chmurowe dostarczają vm.swappiness = 0 w pliku, którego zazwyczaj się nie sprawdza.

sysctl vm.swappiness
swapon --show

Polecenie sysctl vm.swappiness powinno zwrócić vm.swappiness = 100, a swapon --show powinno wyświetlić plik wymiany. Jeśli swappiness zwraca 0, każda operacja zamrażania jest bezskuteczna, co powoduje pełne zużycie pamięci przez każdą bezczynną piaskownicę.

Instalacja Dormice na Ubuntu

Zalecana metoda instalacji polega na przekazaniu potoku do bash:

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

Pobierz skrypt i przeczytaj go przed uruchomieniem. Skrypt działa z uprawnieniami root i modyfikuje system: instaluje Docker, jeśli go brakuje, pobiera gVisor oraz Caddy z weryfikacją sumy kontrolnej, tworzy plik wymiany (swapfile), zapisuje jednostki systemd i dodaje reguły zapory sieciowej.

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 określa rozmiar pliku wymiany; domyślna wartość to 16, co stanowi znaczną ilość miejsca na małym serwerze VPS. --mirror cn przełącza pobieranie na serwery lustrzane dostępne z terenu Chin kontynentalnych. Ponowne uruchomienie instalatora aktualizuje kod i naprawia rozbieżności, nigdy nie zmieniając tokena API.

Kod trafia do /opt/dormice, konfiguracja do /etc/dormice/env, dane piaskownicy do /var/lib/dormice, a polecenia dormice i dor do /usr/local/bin. Instalator generuje token API podczas instalacji i zapisuje go w /etc/dormice/env z uprawnieniami 600.

Nie istnieją oznaczone wersje (tagged releases) do instalacji. Według stanu na 4 sierpnia 2026 repozytorium nie posiada tagów git ani wydań GitHub, więc instalator klonuje main, co oznacza pobranie wersji z danego dnia. Przypięcie wersji wymaga zatem zapisania identyfikatora commitu, który został zainstalowany.

git -C /opt/dormice rev-parse HEAD

Zapisz ten skrót w notatkach wdrożeniowych. Gdy aktualizacja spowoduje błędy, ten commit jest jedyną drogą powrotną, ponieważ nie ma numeru wersji, do którego można się odwołać.

Instalator kończy działanie uruchomieniem dor doctor, czyli testu hosta w trybie tylko do odczytu, który uruchamia rzeczywiste kontenery gVisor, aby potwierdzić działanie środowiska uruchomieniowego zamiast polegać na liście pakietów. Uruchom to polecenie ponownie, gdy demon działa nieprawidłowo.

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice powinno zwrócić active. Jeśli zwróci failed, journalctl -u dormice -n 50 zawiera przyczynę; nieudany start zazwyczaj wynika z problemów z plikiem wymiany lub wymaganiami wstępnymi gVisor, a nie z samego demona.

Instalator instaluje również Caddy, więc sprawdź, co nasłuchuje na portach, zanim uznasz konfigurację zapory za zakończoną.

sudo ss -lntp

Demon wiąże się z 127.0.0.1:3676 i zgodnie z założeniami nie posiada ustawień zmiany tego zachowania. Dostęp z laptopa wymaga celowego działania, a najprostszym rozwiązaniem jest tunel SSH.

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

Po otwarciu tunelu http://127.0.0.1:3676/console na laptopie otwiera konsolę internetową. Zaloguj się tokenem raz, a stanie się on sesyjnym plikiem cookie httpOnly, dzięki czemu sam token nie jest przechowywany w miejscu dostępnym dla strony. Strona Connect wyświetla fragmenty kodu klienta gotowe do skopiowania, skierowane na Twój punkt końcowy.

Tworzenie piaskownicy i wykonywanie w niej kodu

Operacja acquire tworzy piaskownicę. Jest ona idempotentna, co oznacza, że ten sam klucz zawsze zwraca tę samą piaskownicę, tworząc ją, wybudzając, uruchamiając lub przywracając w razie potrzeby. Każde inne polecenie zwraca błąd 404 dla klucza, którego wcześniej nie napotkało. Interfejs dor nie posiada polecenia acquire, dlatego pierwszą piaskownicę należy utworzyć za pomocą konsoli lub biblioteki klienckiej.

Metoda przez konsolę jest najszybsza. Otwórz /console przez tunel i utwórz piaskownicę o nazwie my-agent. Następnie interfejs CLI będzie mógł na niej pracować.

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'

Polecenie dor sandbox ls wyświetla listę wszystkich piaskownic wraz z ich stanem cyklu życia, co pozwala monitorować przejście ze stanu aktywnego do zamrożonego. Polecenie dor sandbox exec wypisuje wersję Python 3.12, ponieważ domyślny obraz to Ubuntu 24.04 z zainstalowanym środowiskiem Python 3.12, Node 24, git oraz ripgrep. Błąd uwierzytelniania oznacza, że skopiowana linia z tokenem zawierała nazwę zmiennej.

Pliki przesyła się za pomocą dor sandbox push my-agent ./script.py, które umieszcza je w /home/user/script.py, natomiast dor sandbox pull my-agent notes.txt służy do ich pobierania. Natywne operacje na plikach mają limit 16 MiB na plik, podczas gdy interfejs plików E2B obsługuje strumieniowanie, dzięki czemu jedynym ograniczeniem jest przydział miejsca na dysku piaskownicy.

Zniszczenie piaskownicy to jedyna operacja powodująca utratę danych. Jest to również dobry przykład wieku projektu: główny plik README oraz dołączone umiejętności agenta dokumentują dor sandbox destroy <key>, podczas gdy plik README pakietu CLI dokumentuje dor sandbox release <key>. Należy uruchomić dor sandbox --help na własnej kompilacji i polegać na tej informacji.

Skierowanie istniejącego kodu E2B na własny serwer

To jest główny powód, dla którego warto się tym zainteresować. Oficjalna paczka e2b z npm, bez żadnych modyfikacji, komunikuje się z Dormice. Uruchom to ze swojego laptopa przy otwartym tunelu SSH, aby na serwerze nie nasłuchiwały żadne nowe usługi.

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

Poprawne wykonanie kończy się kodem wyjścia 0 oraz komunikatem 42. Kluczem API jest Twój token Dormice z prefiksem e2b_, ponieważ takiej formy oczekuje warstwa kompatybilności.

Ta kompatybilność nie jest jedynie atrapą. Strumieniowanie stdout i stderr, polecenia działające w tle, interaktywny PTY, podpisane adresy URL do przesyłania i pobierania plików, monitorowanie katalogów oraz proxy portów – wszystko to jest obsługiwane przez oficjalną paczkę w oparciu o rzeczywistego demona Docker i gVisor, co potwierdza zestaw testów end-to-end projektu. Przed migracją jakichkolwiek rzeczywistych rozwiązań należy wziąć pod uwagę kilka różnic:

• Budowanie szablonów nie jest zaimplementowane. Szablon to obraz docker, który budujesz samodzielnie i rejestrujesz za pomocą dor template add, a Sandbox.create('name') dokonuje jego rozpoznania. Niezarejestrowana nazwa zwraca błąd 404 zamiast udawać, że operacja się powiodła.
• Piaskownice utworzone przez interfejs E2B otrzymują rzeczywiste limity czasowe, ponieważ wymagają tego semantyka E2B. Limity czasowe nigdy nie są narzucane piaskownicom utworzonym przez natywne API.
• Zamrożona piaskownica zachowuje swoje procesy i wznawia je w miejscu, w którym zostały przerwane, więc pauza i wznowienie w tym przypadku nie oznaczają zatrzymania i zimnego startu, do których możesz być przyzwyczajony.

Co piaskownica blokuje, a czego nie

gVisor przechwytuje wywołania systemowe kontenera w przestrzeni użytkownika i samodzielnie je obsługuje, dzięki czemu kod w piaskownicy nie komunikuje się bezpośrednio z jądrem systemu hosta. Wewnątrz piaskownicy wszystko działa jako użytkownik bez uprawnień, uid 1000. Takie połączenie sprawdza się w typowych sytuacjach: wygenerowany skrypt, który uruchamia rm -rf /, zapełnia dysk lub tworzy procesy potomne aż do wyczerpania zasobów, uszkadza jedynie własną piaskownicę i na tym kończy działanie.

Oto czego piaskownica nie blokuje. Każdy z poniższych punktów wymaga samodzielnej konfiguracji.

• Piaskownica posiada dostęp do sieci zewnętrznej. Wygenerowany kod może pobrać dowolne dane i przesłać dalej wszystko, co znajdzie. Mechanizmy zabezpieczające sieć w instalatorze obejmują dwie kwestie: blokują ruch kontenera do usługi metadanych chmury pod adresem 169.254.0.0/16 (skąd instancje chmurowe pobierają poświadczenia) oraz wyłączają komunikację między kontenerami za pomocą "icc": false w pliku daemon.json Dockera. Nic innego nie jest blokowane. Należy zapoznać się z sudo iptables -S DOCKER-USER i dodać własne reguły DROP dla zakresów prywatnych, do których piaskownica nie powinna mieć dostępu.
• Docker wstawia własne reguły przed regułami zapory sieciowej, więc opublikowany port kontenera może być dostępny z Internetu, mimo że ufw wskazuje na jego zamknięcie. Przed wystawieniem jakiejkolwiek usługi na hoście należy przeczytać jak Docker publikuje porty z pominięciem ufw oraz podstawy zapory ufw dla VPS.
• gVisor to jądro działające w przestrzeni użytkownika, a nie hiperwizor. Jest to świadomy kompromis, ponieważ zamrażanie procesów wymaga, aby piaskownice były procesami, a wymóg KVM uniemożliwiłby instalację na wielu systemach. Jeśli model zagrożeń wymaga wirtualizacji sprzętowej, należy zastosować izolację klasy Firecracker i zaakceptować związane z tym koszty operacyjne.
• Token API stanowi pełną granicę bezpieczeństwa po stronie klienta. Każdy, kto posiada DORMICE_API_TOKEN, może tworzyć, odczytywać i niszczyć każdą piaskownicę na maszynie. Procesowi agenta należy przypisać własnego użytkownika z minimalnymi uprawnieniami na VPS, a z tokenem należy postępować tak samo, jak z kluczem SSH. Zasady opisane w bezpiecznym uruchamianiu Claude Code na VPS mają tutaj bezpośrednie zastosowanie.

Sam demon działa jako root na hoście. gVisor chroni hosta przed kodem wewnątrz piaskownicy, jednak nic nie chroni hosta przed samym demonem ani przed osobą posiadającą jego token. Maszyna z uruchomionym Dormice powinna być dedykowana wyłącznie do tego celu. Jeśli agent korzysta również z narzędzi poprzez MCP (model context protocol), z tego samego powodu należy uruchamiać serwery MCP na oddzielnym VPS.

Ile piaskownic mieści się w 4 GB i 8 GB pamięci RAM?

Pamięć zużywają dwa elementy: bazowe zapotrzebowanie systemu hosta oraz zestaw roboczy każdej aktywnej piaskownicy. Należy zarezerwować około 1 GB na system Ubuntu, Docker oraz demona, a następnie podzielić pozostałą ilość przez rzeczywiste zużycie jednej piaskownicy. Piaskownica uruchamiająca skrypt Python, który odczytuje kilka plików, zajmuje od 200 do 300 MiB. Piaskownica kompilująca kod lub wykonująca pełny zestaw testów może przekroczyć jeden gibibajt.

[
  {
    "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
  }
]

Serwer VPS z 4 GB pamięci RAM pozwala na utrzymanie jednocześnie 6 aktywnych piaskownic, jeśli każda z nich zużywa 512 MiB, lub 3, jeśli każda zużywa pełny gibibajt. W przypadku serwera VPS z 8 GB pamięci wartości te wzrastają odpowiednio do 14 oraz 7. Są to limity dla pracy współbieżnej, wyliczone matematycznie, a nie na podstawie benchmarków, dlatego należy monitorować free -m podczas rzeczywistego obciążenia.

Zamrożone piaskownice są ograniczone przez przestrzeń wymiany (swap), a nie przez pamięć RAM, co stanowi istotę tego projektu. Zamrożona piaskownica, która zajmowała jeden gibibajt, utrzymuje w pamięci swap mniej więcej taką samą ilość danych, przy niemal zerowym wykorzystaniu pamięci operacyjnej. Domyślny plik swap o rozmiarze 16 GB pozwala na przechowywanie około 16 takich piaskownic. Po przekroczeniu tego limitu piaskownice muszą zostać zatrzymane, co ogranicza ich koszt wyłącznie do zajętego miejsca na dysku. Dysk jest w dłuższej perspektywie głównym ograniczeniem: każda piaskownica przechowuje własny system plików, a kilkadziesiąt agentów, z których każdy posiada katalog node_modules, zapełni mały wolumin znacznie szybciej, niż stanie się to problemem dla pamięci RAM.

Zamrożenie, zatrzymanie, archiwizacja: parametry cyklu życia

Domyślne ustawienia to zamrożenie po 10 minutach bezczynności, zatrzymanie po 3 dniach oraz archiwizacja po 7 dniach, jeśli została skonfigurowana. Ustawienie stopAfterSeconds na null tworzy agenta rezydentnego: może on zamarznąć w stanie bezczynności, ale nigdy nie wykonuje zimnego startu.

Archiwizacja jest opcjonalna, a demon informuje o niej w sposób przejrzysty. Należy ustawić cztery zmienne DORMICE_S3_*, aby dysk zatrzymanej piaskownicy został spakowany za pomocą tar i zstd, wysłany do dowolnego zasobnika zgodnego z S3 i zwolniony lokalnie. Zasobnikiem tym może być hostowany samodzielnie zasobnik MinIO na innej posiadanej maszynie. Pozostawienie zmiennych nieustawionych powoduje, że piaskownice pozostają w stanie zatrzymania na stałe, a próba wymuszenia archiwizacji zostanie odrzucona zamiast być cicho ignorowana. Przywracanie jest widoczne, a nie ukryte: kolejne żądanie acquire natychmiast zwraca status przywracania wraz z wartością postępu, a po odzyskaniu dysku zmienia status na gotowy.

Czy warto już na tym polegać?

Krótka odpowiedź: nie w przypadku systemów, których nie można odtworzyć od zera. Pierwszy commit w repozytorium pochodzi z 8 lipca 2026 roku. Na dzień 4 sierpnia 2026 roku projekt posiada 446 gwiazdek, 37 forków, licencję Apache-2.0 i brak jakiegokolwiek otagowanego wydania. Sama sekcja statusu w pliku README informuje, że żadna część projektu nie jest gotowa do zastosowań produkcyjnych.

Takie połączenie cech niesie ze sobą określony rodzaj ryzyka. Kod zmienia się dynamicznie, ponieważ instalator śledzi main. Interfejs wciąż ewoluuje, co potwierdza fakt, że operacja usuwania posiada dwie różne nazwy w dwóch plikach w tym samym repozytorium. Projekt mający cztery tygodnie może zostać w każdej chwili porzucony, gdyż żadna klauzula licencyjna nie zobowiązuje nikogo do dalszego rozwoju.

Ryzyko to jest akceptowalne dzięki kompatybilności z E2B. Aplikacja komunikuje się z protokołem, który posiada hostowaną implementację, więc w przypadku wstrzymania prac nad Dormice wystarczy zmienić dwa adresy URL, aby zachować ciągłość działania. Pisząc agenta w oparciu o interfejs E2B, a nie natywne API, zachowuje się możliwość łatwej migracji. Natywny pakiet @dormice/sdk nie jest jeszcze dostępny w npm, co oznacza konieczność budowania go bezpośrednio z repozytorium – jest to kolejny powód, by rozpocząć pracę od ścieżki kompatybilnej.

Należy uruchamiać to rozwiązanie tylko w środowiskach, których utrata nie stanowi problemu. Host powinien być odtwarzalny za pomocą skryptu, tokeny nie mogą pojawiać się w monitach ani commitach, a wszelkie istotne dane należy kopiować z piaskownic zgodnie z własnym harmonogramem tworzenia kopii zapasowych.

FAQ

Czy Dormice jest gotowe do zastosowań produkcyjnych?

Nie, co potwierdza sama dokumentacja projektu. Status w pliku README wskazuje, że żadne z rozwiązań nie jest jeszcze gotowe do produkcji. Na dzień 4 sierpnia 2026 repozytorium ma około czterech tygodni, nie posiada tagów git ani wydań, więc nie ma numeru wersji, do którego można by się przypiąć. Instalator klonuje gałąź main, co oznacza, że każde uruchomienie pobiera najnowszy commit. Należy odnotować git -C /opt/dormice rev-parse HEAD po każdej instalacji i przechowywać wszelkie cenne dane poza piaskownicami.

Czym Dormice różni się od udostępnienia agentowi tymczasowej maszyny wirtualnej?

Tymczasowa maszyna wirtualna to instancja z dostępem SSH, którą tworzy się na czas sesji i usuwa po jej zakończeniu. Dormice to API wykonawcze: program wywołuje funkcję acquire, następnie exec, otrzymując w odpowiedzi stdout oraz kod wyjścia, bez pośrednictwa sesji powłoki. Maszyna wirtualna jest odpowiednia dla człowieka lub agenta, który potrzebuje całego komputera na dłuższy czas. Dormice jest przeznaczone dla aplikacji, która wielokrotnie w ciągu dnia uruchamia wygenerowany kod i nie wymaga pełnej konfiguracji oraz usuwania środowiska przy każdym uruchomieniu.

Czy oficjalny E2B SDK naprawdę działa bez zmian w kodzie?

Tak, pod warunkiem wprowadzenia zmian w konfiguracji. Należy skierować apiUrl oraz sandboxUrl na /e2b/api i /e2b/envd w swoim demonie, a jako klucz API przekazać token Dormice z prefiksem e2b_. Wykonywanie poleceń, sesje PTY, przesyłanie plików, podpisane adresy URL oraz proxy portów są obsługiwane przez zestaw testów end-to-end projektu, działający za pośrednictwem oficjalnego pakietu. Budowanie szablonów jest istotnym brakiem: e2b template build nie jest zaimplementowane, więc szablonem jest obraz docker, który należy zbudować i zarejestrować za pomocą dor template add.

Ile piaskownic mieści się na serwerze VPS z 4 GB pamięci RAM?

Około 6 aktywnych jednocześnie, jeśli każda piaskownica zużywa 512 MiB, lub 3, jeśli każda zużywa pełny gibibajt, po zarezerwowaniu około 1 GB na system operacyjny, Docker oraz demona. Zamrożone piaskownice są ograniczone przez swap, więc domyślny plik wymiany o rozmiarze 16 GB pozwala na zaparkowanie około 16 piaskownic, z których każda zajmowała gibibajt. Należy przeprowadzić własne pomiary za pomocą free -m pod rzeczywistym obciążeniem, ponieważ piaskownica uruchamiająca zestaw testów zużywa kilkukrotnie więcej zasobów niż ta uruchamiająca prosty skrypt.

Dlaczego Dormice wymaga ustawienia vm.swappiness na 100?

Zamrożenie piaskownicy oznacza przeniesienie jej nieaktywnej pamięci do pliku wymiany. gVisor przechowuje pamięć piaskownicy jako pamięć współdzieloną, a jądro Linux nie przenosi pamięci współdzielonej do swap przy domyślnych ustawieniach swappiness. W rezultacie przy ustawieniach domyślnych zamrożenie nie odzyskuje żadnych zasobów, a piaskownica nadal zajmuje pełną ilość pamięci. Projekt wykazał 0 bajtów odzyskanych przy ustawieniach domyślnych i 99,5 procent przy wartości 100. Należy sprawdzić efektywną wartość za pomocą sysctl vm.swappiness zamiast polegać na plikach konfiguracyjnych, ponieważ niektóre obrazy chmurowe mają domyślnie ustawioną wartość 0.