Paano i-self-host ang sandboxd AI app builder sa VPS

Ano ang sandboxd at ano ang makukuha mo sa pagpapatakbo nito

Para i-self-host ang sandboxd, kailangan mo ng isang Linux server na may Docker at isang domain name. Magpapadala ka ng prompt, bubuo ang coding agent ng aktuwal na application sa loob ng isolated container, at magiging available ang application na iyon sa sarili nitong preview URL. Pinakamalakas ang prompt-to-app builders sa hosted category noong 2026, at ang sandboxd ang bersyong tumatakbo sa sarili mong VPS, sa ilalim ng MIT licence, habang nasa sarili mong disk ang nabuong code.

Sadyang maliit ang design nito. Pinapatakbo ng Go control plane ang Docker, niruruta ng Traefik v3 ang bawat preview hostname, ginagamit ng SQLite ang state, at tumatakbo ang bawat app sa loob ng isang container. Walang Kubernetes at walang hiwalay na database server, kaya nitong tumakbo kahit sa isang 2 vCPU box.

Apat na object ang bumubuo sa buong model. Ang app ang persistent na project na naglalaman ng pangalan nito, git metadata, at mga secret. Ang sandbox ang Docker container kung saan tumatakbo ang app, at tumutukoy ang isang app sa isang sandbox sa bawat pagkakataon. Ang workspace ang mga file ng app na nasa host at nananatili kahit maalis ang container. Ang task ang isang prompt na ipinapasa sa agent sa loob ng sandbox. Kapag itinigil ang sandbox, nababakante ang memory at nananatili ang mga file. Kapag winasak ito, itinatapon ang container at maaaring mag-boot ang app ng bago.

Paano naiiba ang sandboxd sa Dify at OpenHands?

Napagkakamalan ang tatlong ito dahil lahat sila ay nagpapatakbo ng LLM (large language model) sa server mo, pero magkakaiba ang ginagawa nila. Gumagawa ang Dify ng mga LLM application: mga chat interface, retrieval pipeline, at workflow na tumatawag sa model sa tuwing ginagamit ang mga ito. Bahagi ng natapos na produkto ang model. Gumagana ang OpenHands sa repository na mayroon ka na: itinuturo mo ito sa iyong code, pagkatapos ay binabasa nito ang mga file, nagpapatakbo ng mga command, at nagmumungkahi ng mga pagbabago. Nagsisimula sa wala ang sandboxd. Gumagawa ito ng scaffold ng project mula sa preset, bina-build ito sa bagong container, at nagbibigay sa iyo ng URL na maaari mong tingnan. Ang nalilikha ay isang karaniwang React o FastAPI application na hindi nangangailangan ng model para tumakbo.

Kaya pumili batay sa gusto mong makuha sa huli. Para sa pagsisimula sa isang sentence at pagpapanatili ng code pagkatapos nito ang sandboxd. Ang dalawa pa ay para sa mga sitwasyong mayroon na ang repository o ang product na pinapagana ng model.

Ang isa pang pagkakaiba ay ang edad ng mga project. Ito ang dapat mong timbangin bago ka bumuo ng anumang aktuwal na system na nakabatay dito.

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

May 875 stars ang sandboxd, kumpara sa 83,091 para sa OpenHands at 151,320 para sa Dify. Ginawa ang repository noong 3 June 2026, kaya dalawang buwan pa lamang ito noong August 2026, samantalang nagmula ang OpenHands noong March 2024 at ang Dify noong April 2023. Inilabas ang release v0.1.0 noong 6 June 2026 at ang v0.3.6 noong 1 August 2026. Tinatawag ng project ang sarili nito na beta at sinasabing maaaring masira ang compatibility sa mga 0.x release. Ituring ang mga numerong ito bilang panganib sa dependency, hindi bilang hatol sa kalidad: ang project na dalawang buwan pa lamang ay dalawang buwan pa lamang nabibigyan ng pagkakataon ang ibang tao na matuklasan ang mga bug nito.

Mga kailangan ng server, at mga problemang lumilitaw kapag kulang ang mga ito

Ayon sa project, sapat na sa pagsisimula ang 2 vCPU at 4 GB ng RAM. Tama ito para sa control plane at isang maliit na sandbox, pero hindi ito sapat para sa dalawang taong sabay na nagbu-build. Hatiin ang paglalaan ng memory. Maliit ang Traefik at ang Go control plane. Ang bawat tumatakbong sandbox ay may buong Node o Python toolchain, at pinakamataas ang paggamit sa isang npm install na sinusundan ng production build. Maglaan ng 8 GB para sa server na magpapanatiling tumatakbo ng ilang app, at ituring ang swap bilang safety net, hindi dagdag na capacity, dahil ang build na gumagamit ng swap ay tumatagal ng ilang minuto sa halip na ilang segundo.

Kapag naubusan ng memory, dalawang magkaibang failure ang maaaring mangyari, at magkaiba ang hitsura ng mga ito. Sa loob ng sandbox, naaabot ng container ang hard --memory ceiling na itinatakda ng sandboxd, at pinapatay ng kernel ang pinakamalaking process. Dahil dito, namamatay ang build nang walang kapaki-pakinabang na mensahe mula sa agent. Ipinapakita ng docker ps -a ang exit code 137 para sa container na iyon, at iniuulat ng docker inspect para rito ang "OOMKilled": true. Madalas munang ipinapakita ng Node build na namamatay sa ganitong paraan ang JavaScript heap out of memory.

Sa host naman nangyayari ang ikalawang failure. Nagpapatakbo ang sandboxd ng pressure reaper na humihinto sa mga sandbox kapag mababa na ang memory ng host. Kaya sa maliit na server, maaaring mawala ang isang sandbox habang mino-monitor mo ang preview nito. Ligtas ang mga file, at gigisingin ito ng susunod na request sa preview URL, pero hindi magpapatuloy ang task na tumatakbo noong huminto ang container.

Mas tahimik na problema ang disk. May sariling workspace sa host ang bawat app, at ang JavaScript project ay may node_modules tree na umaabot sa daan-daang megabyte. Ang 10 app ay kumokonsumo ng ilang gigabyte ng dependencies bago pa isama ang images. Magsimula sa 40 GB at bantayan ito:

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

Ang default data directory ay /var/lib/sandboxed, na may dagdag na e. Kapag nag-type ka ng /var/lib/sandboxd, makakakuha ka ng walang laman na directory at malilito nang limang minuto.

Mag-install ng naka-pin na sandboxd release

Dapat munang naka-install sa server ang Docker Engine na may Compose plugin, pati git. Saklaw ito ng Pag-install ng Docker sa isang VPS.

docker compose version
git --version

Dapat parehong mag-print ang mga ito ng version. Ang docker: 'compose' is not a docker command ay nangangahulugang mayroon kang lumang standalone na docker-compose binary, samantalang v2 plugin ang inaasahan ng installer.

Shell script ang installer na kinukuha sa network, kaya basahin muna ito bago patakbuhin at i-pin ang version.

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

Ang SANDBOXD_REF ang git ref na kino-checkout ng installer sa $HOME/.sandboxd/src, at ang default nito ay main. Kapag iniwan itong unset, ang mai-install mo ay kung ano ang na-merge noong umagang iyon. Mahalaga ito sa proyektong nag-release ng anim na bersyon noong Hulyo 2026 lamang. I-pin ito, pagkatapos ay mag-upgrade nang sinasadya matapos basahin ang changelog.

Kino-clone ng script ang source, bina-build ang images, sinisimulan ang stack gamit ang docker compose up -d, at ipinapakita sa dulo ang console URL at API token. I-save ang token sa ligtas na lugar. Credential ito para sa isang API na kumokontrol sa Docker bilang root.

curl http://127.0.0.1:9090/healthz

Ipi-print nito ang ok kapag up na ang control plane. Kung walang nai-print, hindi nagsimula ang stack: patakbuhin ang docker compose ps mula sa ~/.sandboxd/src upang makita kung aling service ang down, pagkatapos ay docker compose logs sandboxd upang malaman kung bakit.

Pag-access sa console sa remote box

Ibinibigay ng Traefik ang console sa HTTP_PORT, na 80 bilang default, gamit ang hostname na http://console.localhost. Nagro-route ang Traefik batay sa hostname. Kaya kapag IP address ng server ang inilagay sa browser, walang tumutugmang rule at 404 ang ibinabalik. Hangga't hindi ka pa nagse-set up ng totoong domain, i-forward ang port at panatilihin ang hostname:

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

Pagkatapos, buksan ang http://console.localhost:8080 sa iyong laptop. Sa Linux at macOS, ang anumang name na nagtatapos sa .localhost ay nagre-resolve sa 127.0.0.1. Kaya dumadaan ang request sa tunnel gamit ang tamang Host header. I-set ang password ng console sa unang pagbisita.

Bigyan ng model ang agent

May dalawang coding agent sa base image: OpenCode at Claude Code. Tinutukoy ng SANDBOXD_DEFAULT_AGENT kung alin ang tatakbo para sa task na walang tinukoy na agent, at ang default nito ay opencode. Kung walang nakakonektang key, tatakbo ang mga task gamit ang keyless free models ng OpenCode Zen. Dahil dito, walang gastos ang unang build at masusubukan mo ang buong workflow bago gumastos.

Ikonekta ang sarili mong key kapag kailangan mo ng mas malakas na model. Napupunta ang mga key sa control plane, hindi sa sandbox. Naka-encrypt ang mga ito sa data directory at ipinapadala sa wire ng credential proxy, kaya hindi mababasa ng agent o ng code na sinusulat nito ang mga key.

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-..."}'

Pareho ang ginagawa ng console sa Settings, AI Agents. May guided OAuth flow din ito kung gusto mong gumamit ng Claude subscription sa halip na API key. Nasa parehong panel ang default model ng bawat agent, at maaaring palitan ito ng isang task.

Bumuo ng isang maliit na app mula simula hanggang dulo

Bumuo ng app, i-boot ang sandbox nito, at magpadala ng prompt. Babalik ang mga ID bilang JSON, at kinukuha ng quickstart ang mga ito gamit ang sed kaya hindi mo kailangang naka-install ang jq.

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"

Dapat parehong may ID ang dalawang variable. Ang walang laman na $SB ay nangangahulugang hindi kailanman nag-boot ang sandbox. Karaniwang sanhi nito ang base image na ginagawa pa o ang host na kapos sa memory. Ang 401 sa halip na ID ay nangangahulugang mali ang bearer token.

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"}'

May task ID ang response. Ibinabalik ng GET /v1/sandboxes/$SB/tasks/<task id> ang resulta nito, at ang /events path sa parehong task ay isang live SSE (server sent events) stream ng ginagawa ng agent. Ipinapakita rin ng console ang parehong stream bilang chat.

Nasa http://s-<sandbox id>-3000.preview.localhost na ang app, kung saan ang 3000 ang port na hiniling mo. Kung naka-sleep ang sandbox, napupunta ang unang request sa catch-all ng Traefik. Sinisimulan ng sandboxd ang container, hinihintay na tumugon ang port, at naghahatid ng maikling warming page na nagre-refresh papunta sa app mo. Kung hindi umaalis ang preview sa page na iyon, hindi nakikinig ang process sa loob sa port na idineklara sa sandbox.yaml ng app.

Ilagay ang mga preview sa totoong domain na may HTTPS

May sariling hostname ang bawat sandbox, kaya isang wildcard DNS record ang sumasaklaw sa lahat ng ito. Ituro ang *.preview.yourdomain.com sa IP address ng server gamit ang A record. Pagkatapos, itakda ang mga variable para sa preview sa .env sa ~/.sandboxd/src:

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

Kailangan ng Traefik ang katugmang bahagi: i-enable ang websecure entrypoint sa traefik/traefik.yml at magdagdag ng certificate resolver. Gamitin ang DNS-01 challenge dahil isang wildcard certificate ang sasaklaw sa lahat ng preview hostname. Sa HTTP-01, kailangang humiling ng sariling certificate ang bawat bagong sandbox. Kapag maraming build sa isang hapon, mabilis nitong maaabot ang rate limit ng Let's Encrypt. Tinalakay sa Wildcard certificates gamit ang DNS-01 challenge ang bahagi para sa DNS.

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

Magiging https://s-<id>-3000.preview.yourdomain.com ang mga preview URL. Buksan ang 80 at 443 sa firewall at panatilihing sarado sa publiko ang 9090: tingnan ang mga pangunahing ufw firewall rule. Tandaan na maaaring i-load ng sinumang makakahula ng preview hostname ang app, kaya ituring na public ang mga preview.

Saan napupunta ang generated code, at maaari ba itong i-export?

Sa host, nasa data directory ito. Ang bawat workspace ay isang plain directory sa /var/lib/sandboxed/workspaces/<id>/ na bind-mounted sa container, at nasa /home/sandbox/workspace/app ang mga file ng app sa loob ng sandbox. Ang state ng control plane ay nasa iisang SQLite file sa state/sandboxd.db, at nasa agent-auth/ ang encrypted agent credentials. Walang nakatagong data sa container layer, kaya ang backup ay directory copy kasama ang database file na iyon. Parehong hinahawakan ng restic backups sa isang VPS ang mga ito.

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

Built in ang Git export at hindi ito idinagdag bilang hiwalay na workaround. Nagbibigay ang API ng status at diff para sa pagbasa, at pagkatapos ay commit at push:

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"}'

Kailangan ng private remote ng personal access token. Itakda ito nang isang beses sa console, sa Settings, Git credentials. Naka-encrypt itong naka-store at nananatili sa labas ng sandbox, kaya hindi ito mababasa ng agent at hindi ito magagamit sa push nang hindi mo nalalaman. Mag-push nang maaga at madalas. Bago mo ito gawin, ang workspace directory lamang ang kopya ng code, at tuluyan itong inaalis ng DELETE /v1/apps/<id> nang walang paraan para maibalik.

Magkano ang gastos ng isang build sa model tokens?

Hindi sinusukat ng sandboxd ang iyong gastos, kaya ang mahalagang bilang ay nasa console ng provider mo. Walang bayad ang mga libreng OpenCode Zen model, pero mas mabagal at mas mahina ang mga ito kaysa sa paid model. Makikita ito sa mas maraming correction round para sa anumang lampas sa toy app.

Ang kabuuang bill ay nakabatay sa paraan ng pagtakbo ng agent loop. Sa bawat turn, ipinapadala muli ang context na kailangan nito. Kaya ang gastos ay nakabatay sa bilang ng turns, hindi sa bilang ng apps. Murang-mahal ang isang prompt na agad nagtagumpay. Hindi mura ang 15 round ng “ayusin naman ang spacing” sa project na may 50 files, dahil ipinapadala muli ang laman ng mga file sa bawat round. Magkaiba ang presyo ng input at output tokens, at ipinapakita ng gastos ng coding agent bawat session ang makatotohanang range. Magtakda ng hard spend limit sa provider bago mo ipagamit ang mga credential sa loop na tatakbo nang unattended.

Paglilinis ng mga lumang sandbox

Itinitigil ng idle reaper ang anumang sandbox na idle lampas sa SANDBOXD_IDLE_THRESHOLD_SECONDS, na default na 2100 segundo o 35 minuto. Ibinabalik nito ang RAM habang pinananatili ang mga file, at ginigising ng susunod na request sa preview URL ang container. Bawasan ang value na ito sa maliit na server, dahil ang 35 minutong idle containers ay 35 minutong memory na hindi mo magagamit.

Ang pag-stop ay hindi pag-delete, at dito tahimik na napupuno ang mga disk. Pagkatapos i-stop, pagmamay-ari pa rin ng sandbox ang workspace at container nito. Ang pag-remove ng sandbox habang pinananatili ang app ay isang DELETE sa sandbox, na kasama nitong inaalis ang container at workspace. Kapag inalis ang app, lahat ay permanenteng mabubura.

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

Pagkaraan ng ilang linggo ng mga experiment, magpapakita ang docker system df ng mas maraming reclaimable image space kaysa sa inaasahan mo, dahil ang bawat app na nag-pull ng sarili nitong toolchain ay nag-iwan ng mga layer. Inaalis ng docker image prune ang mga dangling layer. Suriin muna ang GET /v1/apps, dahil hindi garbage ang image na ginagamit pa ng isang sleeping sandbox.

Ano ang ibinibigay at hindi ibinibigay ng boundary ng container

Tumatakbo ang bawat sandbox bilang unprivileged user na may read-only root filesystem, inalis ang lahat ng Linux capabilities, naka-set ang no-new-privileges, at may memory ceiling at process limit. Tapat ang proyekto tungkol sa limitasyong ito: ang Linux container na may shared kernel ay isang matibay na isolation boundary ngunit mahinang security boundary. Ang bug sa kernel ay maaaring humantong sa compromise ng host.

May dalawang fact na nangangailangan ng aksyon. Bukas ang network egress mula sa sandbox sa self-hosted build, kaya maaaring kumonekta ang generated code sa internet, sa iyong local network, at sa mga cloud metadata endpoint. May nftables egress subsystem sa source, pero naka-compile ito bilang off sa portable Docker Compose build. Ibig sabihin, dapat manggaling sa host firewall ang mga limitasyon. Ang control plane API ay epektibong host root dahil kinokontrol nito ang Docker socket. Nagbi-bind ito sa 127.0.0.1:9090 bilang default, dapat manatiling SANDBOXD_API_AUTH_DISABLED ang false, at hindi ito dapat kailanman i-publish sa internet.

Kung plano mong payagang magpadala ng prompts ang ibang tao sa iyong machine, masyadong mahina ang modelong ito kapag nag-iisa. Itinuturo ng proyekto ang gVisor gamit ang SANDBOXD_RUNTIME=runsc. Naglalagay ito ng userspace kernel sa pagitan ng sandbox at host, ngunit nagdudulot ng humigit-kumulang 1.7 hanggang 4 na beses na pagbagal sa syscall-heavy na trabaho. Ang mas matibay na sagot ay isang machine para sa bawat tenant. Ito rin ang parehong dahilan para sa pagpapatakbo ng coding agents sa disposable VM.

Dapat ka bang bumuo gamit ang project na dalawang buwan pa lamang?

Para sa personal na build box, oo, basta gawin ang mga karaniwang pag-iingat: i-pin ang SANDBOXD_REF, mag-back up ng /var/lib/sandboxed, at i-push sa git remote ang bawat app na mahalaga sa iyo. Para sa anumang hinahawakan ng customer, hintayin ang 1.0 o maglaan ng budget para sa mga posibleng failure, dahil malinaw na sinasabi ng maintainers na maaaring magbago ang 0.x habang ginagamit mo ito. Nagbebenta rin ang maintainers ng managed install sa halagang 79 dollars bawat buwan noong August 2026. Mahalaga itong malaman kapag sinusuri mo kung may sapat na dahilan para magpatuloy ang project.

Katanggap-tanggap ang risk dahil sa output. Gumagawa ang sandboxd ng karaniwang application sa karaniwang git repository. Kaya kung huminto ang development ng project, mananatili sa iyo ang code at ang wrapper lamang ang mawawala. Mas mabuting posisyon ito kaysa sa isang hosted builder na nagmamay-ari ng project mo. Para sa mas malawak na pananaw kung ano ang sulit i-self-host sa server mo ngayong taon, tingnan ang ano ang sulit i-self-host sa 2026.

FAQ

Ano ang minimum na server specs para sa sandboxd?

Ayon sa project, sapat na ang 2 vCPU at 4 GB ng RAM para makapagsimula. Kasama na rito ang control plane, Traefik, at isang maliit na sandbox. Gumamit ng 8 GB ng RAM at 40 GB ng disk kung gusto mong sabay-sabay na panatilihing aktibo ang ilang app, dahil may buong Node o Python toolchain ang bawat tumatakbong sandbox at may sariling dependency tree sa disk ang bawat workspace. Kapag kapos ang host sa memory, pinapahinto ng pressure reaper ng sandboxd ang mga sandbox upang magpalaya ng memory. Kapag lumampas naman ang build sa memory ceiling ng container nito, pinapatay ito ng kernel: ipinapakita ng docker ps -a ang exit code 137 para rito.

Paano naiiba ang sandboxd sa Dify o OpenHands?

Magkakaiba ang artifact na ginagawa ng mga ito. Gumagawa ang Dify ng mga application na tumatawag sa isang model habang tumatakbo, gaya ng mga chat interface at retrieval pipeline. Ine-edit ng OpenHands ang isang repository na mayroon ka na, nagpapatakbo ng mga command, at nagmumungkahi ng mga pagbabago sa kasalukuyang code. Gumagawa ang sandboxd ng bagong project mula sa prompt, bina-build ito sa sarili nitong container, at sine-serve ito sa isang preview URL. Ang resulta ay isang ordinaryong web application na hindi nangangailangan ng model upang tumakbo.

Saan talaga naka-store ang code na sinusulat ng agent?

Sa filesystem ng host, hindi sa loob ng container image. Binibigyan ang bawat app ng directory sa /var/lib/sandboxed/workspaces/<id>/ na naka-bind mount sa sandbox nito, at lumalabas ang mga file sa /home/sandbox/workspace/app sa loob nito. Ang state ng control plane ay isang SQLite file sa ilalim ng state/, sa parehong data directory. Maaari kang mag-commit at mag-push sa isang git remote mula sa Git tab ng console o sa pamamagitan ng mga endpoint na /v1/apps/<id>/git/commit at /git/push. Ang token para sa mga private remote ay ine-encrypt at ini-store ng control plane sa halip na ibigay sa sandbox.

Ligtas bang ilantad sa internet ang sandboxd?

Ilantad ang mga preview URL at ang console, ngunit huwag ang control plane API. Kinokontrol ng API na iyon ang Docker sa host, kaya katumbas nito ang root access. Nagbi-bind ito sa 127.0.0.1:9090 bilang default dahil dito. May bukas ding network egress ang mga sandbox sa self-hosted build. Ibig sabihin, maaaring maabot ng code na sinusulat ng agent ang iyong local network at ang mga cloud metadata endpoint. Magdagdag ng host firewall rules kung may ibang system sa network na dapat protektahan. Para sa mga prompt mula sa mga taong hindi mo pinagkakatiwalaan, gumamit ng isang host bawat tenant sa halip na umasa lamang sa container boundary.