가이드

작성자 Matt Connor 2026-08-04 · 업데이트됨 2026-08-07

sandboxd 직접 호스팅 방법: VPS 구축 가이드

Q: 에이전트가 작성한 코드는 실제로 어디에 저장됩니까?

컨테이너 이미지가 아닌 호스트 파일 시스템에 저장됩니다. 각 앱은 /var/lib/sandboxed/workspaces/ /에 디렉터리를 할당받아 샌드박스에 바인드 마운트되며, 파일은 내부의 /home/sandbox/workspace/app에 나타납니다. 제어 평면 상태는 동일한 데이터 디렉터리 내의 state/에 있는 단일 SQLite 파일로 관리됩니다. 콘솔의 Git 탭이나 /v1/apps/ /git/commit 및 /git/push 엔드포인트를 통해 원격 git 저장소로 커밋 및 푸시할 수 있습니다. 비공개 원격 저장소를 위한 토큰은 샌드박스에 전달되지 않고 제어 평면에 의해 암호화되어 저장됩니다.

Docker와 Traefik을 사용하여 sandboxd를 VPS에 직접 설치하는 과정을 설명합니다. 모델 키 설정, HTTPS 미리보기 URL 구성, RAM 및 디스크 용량 최적화, 그리고 불필요한 샌드박스 정리 등 안정적인 운영을 위한 필수 설정 정보를 확인하십시오.

sandboxd의 정의와 직접 실행 시 얻는 이점

sandboxd를 직접 호스팅하려면 Docker가 설치된 Linux 서버 한 대와 도메인 이름이 필요합니다. 프롬프트를 전송하면 코딩 에이전트가 격리된 컨테이너 내부에서 실제 애플리케이션을 빌드하며, 해당 애플리케이션은 고유한 미리보기 URL에서 실행됩니다. 프롬프트 기반 앱 빌더는 2026년 가장 주목받는 호스팅 분야이며, sandboxd는 MIT 라이선스를 따르고 생성된 코드가 사용자의 디스크에 저장되는 VPS 기반 솔루션입니다.

이 설계는 의도적으로 간소화되었습니다. Go 제어 평면이 Docker를 구동하고, Traefik v3가 모든 미리보기 호스트 이름을 라우팅하며, SQLite가 상태를 유지하고, 각 앱은 하나의 컨테이너 안에서 실행됩니다. Kubernetes나 별도의 데이터베이스 서버가 없으므로 2 vCPU 사양의 서버에서도 충분히 운영할 수 있습니다.

전체 모델은 네 가지 객체로 구성됩니다. app은 지속적인 프로젝트로, 이름과 git 메타데이터, 보안 정보를 담고 있습니다. sandbox는 앱이 실행되는 Docker 컨테이너이며, 앱은 한 번에 하나의 샌드박스를 가리킵니다. workspace는 호스트에 저장되어 컨테이너가 종료되어도 유지되는 앱의 파일들입니다. task는 샌드박스 내부의 에이전트에게 전달되는 하나의 프롬프트입니다. 샌드박스를 중지하면 메모리는 해제되지만 파일은 유지됩니다. 샌드박스를 삭제하면 컨테이너는 제거되지만, 앱은 언제든 새로운 컨테이너를 부팅할 수 있습니다.

sandboxd는 Dify 및 OpenHands와 어떻게 다른가?

이 세 가지 도구는 모두 서버에서 LLM(거대 언어 모델)을 구동한다는 공통점 때문에 혼동하기 쉽지만, 결과물은 서로 다릅니다. Dify는 LLM 애플리케이션을 구축합니다: 사용자가 서비스를 이용할 때마다 모델을 호출하는 채팅 인터페이스, 검색 파이프라인, 워크플로우를 만듭니다. 모델 자체가 완성된 제품의 일부입니다. OpenHands는 이미 존재하는 저장소에서 작업합니다: 코드 저장소를 지정하면 파일을 읽고, 명령을 실행하며, 변경 사항을 제안합니다. sandboxd는 아무것도 없는 상태에서 시작합니다. 미리 설정된 템플릿으로 프로젝트의 뼈대를 만들고, 격리된 컨테이너에서 빌드한 뒤 접속 가능한 URL을 제공합니다. 결과물은 모델 없이도 실행되는 일반적인 React 또는 FastAPI 애플리케이션입니다.

따라서 최종적으로 무엇을 원하는지에 따라 선택하십시오. sandboxd는 문장 하나로 시작해 이후 코드를 직접 유지 관리하려는 경우에 적합합니다. 나머지 두 도구는 이미 저장소가 존재하거나 모델 기반의 제품을 운영하려는 경우에 사용합니다.

또 다른 차이점은 프로젝트의 연식이며, 실제 서비스를 구축하기 전에 반드시 고려해야 할 요소입니다.

ChartGitHub stars and forks, read from the GitHub API on 4 August 2026

tool

github_stars

forks

sandboxd

875

OpenHands

83,091

10,711

Dify

151,320

23,886

The data behind this chart

[
  {
    "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는 875개의 스타를 보유하고 있으며, OpenHands는 83,091개, Dify는 151,320개를 기록하고 있습니다. sandboxd 저장소는 2026년 6월 3일에 생성되어 2026년 8월 기준으로 2개월 된 프로젝트입니다. 반면 OpenHands는 2024년 3월, Dify는 2023년 4월부터 시작되었습니다. 릴리스 v0.1.0은 2026년 6월 6일에, v0.3.6은 2026년 8월 1일에 배포되었습니다. 이 프로젝트는 스스로를 베타 버전으로 정의하며 0.x 릴리스에서는 호환성이 깨질 수 있다고 명시합니다. 이러한 수치는 품질에 대한 평가라기보다 의존성 위험으로 해석해야 합니다. 2개월 된 프로젝트는 다른 사용자들이 버그를 발견할 시간이 2개월밖에 없었다는 점을 의미합니다.

서버 요구 사항 및 리소스 부족 시 발생하는 문제

프로젝트 문서에 따르면 2 vCPU와 4 GB RAM이면 시작하기에 충분합니다. 이는 컨트롤 플레인과 하나의 작은 샌드박스를 실행할 때 정확한 수치이며, 두 명 이상의 사용자가 동시에 빌드를 수행하기에는 부족합니다. 메모리 예산을 나누어 계획하십시오. Traefik과 Go 컨트롤 플레인은 가볍습니다. 실행 중인 각 샌드박스는 전체 Node 또는 Python 툴체인을 포함하며, 피크 시점에는 npm install와 프로덕션 빌드가 이어집니다. 몇 개의 앱을 유지할 서버라면 8 GB를 계획하고, 스왑은 용량이 아닌 안전장치로 간주하십시오. 스왑을 사용하는 빌드는 수 초가 아닌 수 분이 소요되기 때문입니다.

메모리가 고갈되면 서로 다른 두 가지 형태의 오류가 발생하며, 증상은 전혀 다릅니다. 샌드박스 내부에서 컨테이너가 sandboxd가 설정한 엄격한 --memory 제한에 도달하면 커널이 가장 큰 프로세스를 종료하므로, 에이전트로부터 유용한 메시지 없이 빌드가 중단됩니다. docker ps -a은 해당 컨테이너에 대해 종료 코드 137을 표시하며, docker inspect에서 확인하면 "OOMKilled": true 상태로 나타납니다. 이런 방식으로 종료되는 Node 빌드는 종종 사전에 JavaScript heap out of memory를 출력합니다.

두 번째 오류는 호스트에서 발생합니다. sandboxd는 호스트 메모리가 부족해지면 샌드박스를 중지시키는 압력 리퍼(pressure reaper)를 실행하므로, 사양이 낮은 서버에서는 미리보기를 확인하는 도중 샌드박스가 사라질 수 있습니다. 파일은 안전하며 미리보기 URL에 다시 요청을 보내면 샌드박스가 깨어나지만, 컨테이너가 중지될 당시 실행 중이던 작업은 재개되지 않습니다.

디스크는 더 조용하게 발생하는 문제입니다. 각 앱은 호스트에 자체 작업 공간을 유지하며, JavaScript 프로젝트는 수백 MB 크기의 node_modules 트리를 포함합니다. 앱 10개만 운영해도 이미지 용량을 제외하고 수 GB의 의존성 파일이 쌓입니다. 40 GB에서 시작하여 다음 명령어로 모니터링하십시오.

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

기본 데이터 디렉터리는 /var/lib/sandboxed이며, 철자에 e가 추가되어 있습니다. /var/lib/sandboxd으로 입력하면 빈 디렉터리만 나타나 5분간 혼란을 겪게 될 수 있습니다.

고정된 sandboxd 릴리스 설치

Compose 플러그인이 포함된 Docker Engine과 git이 서버에 먼저 설치되어 있어야 합니다. VPS에 Docker 설치하기 문서에서 해당 과정을 다룹니다.

docker compose version
git --version

두 명령 모두 버전 정보가 출력되어야 합니다. docker: 'compose' is not a docker command가 출력된다면 구형 독립 실행형 docker-compose 바이너리가 설치된 상태이며, 설치 프로그램은 v2 플러그인을 요구합니다.

설치 프로그램은 네트워크를 통해 가져오는 셸 스크립트이므로, 실행하기 전에 내용을 확인하고 버전을 고정하십시오.

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은 설치 프로그램이 $HOME/.sandboxd/src로 체크아웃할 git 참조(ref)이며, 기본값은 main입니다. 이 값을 설정하지 않으면 그날 아침에 병합된 최신 코드가 설치됩니다. 2026년 7월 한 달 동안에만 6번의 릴리스가 있었던 프로젝트에서는 이는 중요한 문제입니다. 버전을 고정하고, 변경 로그를 읽은 뒤 의도적으로 업그레이드하십시오.

이 스크립트는 소스 코드를 복제하고, 이미지를 빌드하며, docker compose up -d를 사용하여 스택을 시작한 뒤 마지막에 콘솔 URL과 API 토큰을 출력합니다. 해당 토큰을 안전한 곳에 보관하십시오. 이 토큰은 root 권한으로 Docker를 제어하는 API의 자격 증명입니다.

curl http://127.0.0.1:9090/healthz

제어 평면이 가동되면 ok이 출력됩니다. 아무것도 출력되지 않는다면 스택이 시작되지 않은 것입니다. ~/.sandboxd/src 경로에서 docker compose ps을 실행하여 중단된 서비스를 확인하고, docker compose logs sandboxd을 실행하여 원인을 파악하십시오.

원격 서버의 콘솔 접속

콘솔은 HTTP_PORT에서 Traefik을 통해 제공되며, 기본 포트는 80이고 호스트 이름은 http://console.localhost입니다. Traefik은 호스트 이름을 기준으로 라우팅하므로, 브라우저에 서버 IP 주소를 직접 입력하면 일치하는 규칙이 없어 404 오류가 발생합니다. 실제 도메인을 설정하기 전까지는 포트를 포워딩하고 호스트 이름을 유지하십시오.

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

그런 다음 노트북에서 http://console.localhost:8080을 엽니다. Linux와 macOS에서는 .localhost로 끝나는 모든 이름이 127.0.0.1로 해석되므로, 요청이 올바른 Host 헤더와 함께 터널을 통해 전달됩니다. 처음 접속할 때 콘솔 비밀번호를 설정하십시오.

에이전트에 모델 할당하기

기본 이미지에는 OpenCode와 Claude Code라는 두 가지 코딩 에이전트가 포함되어 있습니다. SANDBOXD_DEFAULT_AGENT는 에이전트가 지정되지 않은 작업을 수행할 때 어떤 에이전트를 실행할지 결정하며, 기본값은 opencode입니다. 연결된 키가 전혀 없는 경우 작업은 OpenCode Zen의 키리스 무료 모델에서 실행되므로, 첫 번째 빌드에는 비용이 발생하지 않으며 비용을 지불하기 전에 전체 루프를 테스트할 수 있습니다.

더 강력한 모델을 사용하려면 본인의 키를 연결하십시오. 키는 제어 평면으로 전송되며 샌드박스 내부로는 전달되지 않습니다. 키는 데이터 디렉터리에 암호화되어 저장되며 자격 증명 프록시에 의해 네트워크상에서 주입되므로, 에이전트나 에이전트가 작성한 코드는 키를 읽을 수 없습니다.

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

콘솔의 Settings, AI Agents 메뉴에서도 동일한 작업을 수행할 수 있습니다. API 키 대신 Claude 구독을 사용하려는 경우 안내에 따른 OAuth 흐름을 이용할 수 있습니다. 에이전트별 기본 모델은 동일한 패널에서 설정하며, 단일 작업에서 이를 재정의할 수도 있습니다.

소규모 애플리케이션의 엔드 투 엔드 빌드

애플리케이션을 생성하고 샌드박스를 부팅한 뒤 프롬프트를 전송합니다. ID는 JSON 형태로 반환되며, 퀵스타트는 sed을 사용하여 이를 추출하므로 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"

두 변수 모두 ID를 포함해야 합니다. $SB이 비어 있다면 샌드박스가 부팅되지 않은 것이며, 일반적인 원인은 베이스 이미지가 여전히 빌드 중이거나 호스트의 메모리가 부족한 경우입니다. ID 대신 401가 표시된다면 베어러 토큰이 잘못된 것입니다.

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

응답에는 작업 ID가 포함됩니다. GET /v1/sandboxes/$SB/tasks/<task id>는 해당 결과를 반환하며, 동일한 작업의 /events 경로는 에이전트의 동작을 실시간 SSE(Server Sent Events) 스트림으로 제공합니다. 콘솔에는 채팅과 동일한 스트림이 표시됩니다.

애플리케이션은 http://s-<sandbox id>-3000.preview.localhost에서 실행되며, 여기서 3000은 요청한 포트 번호입니다. 샌드박스가 대기 상태였다면 첫 번째 요청은 Traefik의 캐치올(catch-all)로 전달됩니다. 이후 sandboxd가 컨테이너를 시작하고 포트 응답을 기다린 뒤, 애플리케이션으로 자동 새로고침되는 짧은 준비 페이지를 제공합니다. 해당 페이지에서 넘어가지 않는다면, 내부 프로세스가 애플리케이션의 sandbox.yaml에 선언된 포트에서 대기 중이지 않은 것입니다.

실제 도메인과 HTTPS로 미리보기 서비스하기

모든 샌드박스는 고유한 호스트네임을 가지므로 와일드카드 DNS 레코드 하나로 모두 처리할 수 있습니다. *.preview.yourdomain.com을 서버의 IP 주소로 가리키는 A 레코드를 설정하십시오. 그런 다음 ~/.sandboxd/src의 .env에서 미리보기 변수를 설정합니다.

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

Traefik에도 대응하는 설정이 필요합니다. traefik/traefik.yml에서 websecure 엔트리포인트를 활성화하고 인증서 리졸버를 추가하십시오. 와일드카드 인증서 하나로 모든 미리보기 호스트네임을 커버할 수 있도록 DNS-01 챌린지를 사용해야 합니다. HTTP-01을 사용하면 샌드박스가 생성될 때마다 개별적으로 인증서를 발급받아야 하며, 빌드 작업이 많은 오후에는 Let's Encrypt의 속도 제한(rate limit)에 바로 걸리게 됩니다. DNS-01 챌린지를 통한 와일드카드 인증서에서 DNS 측면의 설정을 다룹니다.

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

미리보기 URL은 https://s-<id>-3000.preview.yourdomain.com 형식이 됩니다. 방화벽에서 80번과 443번 포트를 열고 9090번 포트는 외부에서 접근하지 못하도록 닫아두십시오. 기본 ufw 방화벽 규칙을 참조하십시오. 미리보기 호스트네임을 추측할 수 있는 사람은 누구나 앱을 로드할 수 있다는 점을 기억하고, 미리보기 환경을 공개 서비스로 간주하여 관리하십시오.

생성된 코드는 어디에 저장되며, 내보낼 수 있습니까?

호스트의 데이터 디렉터리 아래에 저장됩니다. 각 작업 공간은 /var/lib/sandboxed/workspaces/<id>/에 위치한 일반 디렉터리이며 컨테이너에 바인드 마운트됩니다. 애플리케이션 파일은 샌드박스 내부의 /home/sandbox/workspace/app에 위치합니다. 컨트롤 플레인 상태는 state/sandboxd.db에 있는 단일 SQLite 파일이며, 암호화된 에이전트 자격 증명은 agent-auth/에 저장됩니다. 컨테이너 레이어 내부에 숨겨진 것은 없으므로, 백업은 디렉터리 복사와 해당 데이터베이스 파일을 포함하는 방식입니다. VPS에서의 restic 백업을 통해 두 가지 모두 처리할 수 있습니다.

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

Git 내보내기 기능은 별도로 추가하는 것이 아니라 내장되어 있습니다. API는 상태와 diff를 읽기 위해 노출하며, 이후 commit과 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"}'

비공개 원격 저장소를 사용하려면 개인 액세스 토큰이 필요하며, 이는 콘솔의 Settings 내 Git credentials에서 한 번 설정합니다. 이 토큰은 암호화되어 저장되며 샌드박스 외부에서 유지되므로, 에이전트가 이를 읽거나 사용자의 동의 없이 push할 수 없습니다. 자주, 그리고 일찍 push하십시오. push를 수행하기 전까지는 작업 공간 디렉터리가 코드의 유일한 복사본이며, DELETE /v1/apps/<id>을 실행하면 복구할 기회 없이 삭제됩니다.

빌드 시 모델 토큰 비용은 어떻게 산정됩니까?

sandboxd는 사용량을 측정하지 않으므로, 실제 비용은 사용 중인 제공업체의 콘솔에서 확인해야 합니다. 무료 OpenCode Zen 모델은 비용이 발생하지 않지만, 유료 모델보다 속도가 느리고 성능이 낮습니다. 따라서 간단한 앱을 제외한 작업에서는 수정 횟수가 더 많이 발생할 수 있습니다.

청구 금액은 에이전트 루프의 작동 방식에 따라 결정됩니다. 각 턴마다 필요한 컨텍스트를 다시 전송하므로, 비용은 앱의 개수가 아니라 턴의 횟수에 비례합니다. 한 번에 성공하는 프롬프트는 비용이 저렴합니다. 하지만 50개의 파일이 포함된 프로젝트에서 "간격을 수정해 줘"와 같은 요청을 15번 반복하면, 매번 파일 내용이 함께 전송되므로 비용이 증가합니다. 입력 및 출력 토큰은 가격이 다르게 책정되며, 코딩 에이전트의 세션당 비용에서 현실적인 범위를 확인할 수 있습니다. 무인 루프를 실행하기 전에 제공업체 설정에서 엄격한 지출 한도를 지정하십시오.

오래된 샌드박스 정리

idle reaper는 SANDBOXD_IDLE_THRESHOLD_SECONDS을 초과하여 유휴 상태인 모든 샌드박스를 중지합니다. 이 값의 기본값은 2100초, 즉 35분입니다. 샌드박스가 중지되면 RAM은 반환되지만 파일은 유지되며, 이후 미리보기 URL로 요청이 들어오면 컨테이너가 다시 깨어납니다. 소형 서버에서는 이 값을 낮추십시오. 유휴 컨테이너가 35분 동안 유지되면 35분 동안 메모리를 사용할 수 없게 되기 때문입니다.

중지는 삭제가 아니며, 이 과정에서 디스크가 조용히 가득 차게 됩니다. 중지된 샌드박스는 여전히 자신의 작업 공간과 컨테이너를 소유합니다. 샌드박스를 제거하되 앱을 유지하는 것은 샌드박스에 대한 DELETE 작업이며, 이 작업은 컨테이너와 작업 공간을 함께 제거합니다. 앱을 제거하면 모든 데이터가 영구적으로 삭제됩니다.

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

몇 주간 실험을 진행한 후 docker system df을 확인하면 예상보다 많은 회수 가능한 이미지 공간이 나타날 것입니다. 자체 툴체인을 가져온 모든 앱이 레이어를 남기기 때문입니다. docker image prune는 연결되지 않은(dangling) 레이어를 정리합니다. 슬립 상태인 샌드박스가 참조 중인 이미지는 가비지가 아니므로, 먼저 GET /v1/apps를 확인하십시오.

컨테이너 경계가 제공하는 것과 제공하지 않는 것

각 샌드박스는 읽기 전용 루트 파일 시스템을 가진 권한 없는 사용자로 실행되며, 모든 Linux capabilities가 제거되고 no-new-privileges이 설정되며, 메모리 상한과 프로세스 제한이 적용됩니다. 이 프로젝트는 이러한 한계를 명확히 밝히고 있습니다. 커널을 공유하는 Linux 컨테이너는 강력한 격리 경계이지만 보안 경계로서는 취약합니다. 커널 버그는 곧 호스트 침해로 이어집니다.

두 가지 사실에 대응이 필요합니다. 자체 호스팅 빌드에서 샌드박스의 네트워크 송신(egress)은 열려 있으므로, 생성된 코드가 인터넷, 로컬 네트워크, 클라우드 메타데이터 엔드포인트에 접근할 수 있습니다. 소스 코드에는 nftables 송신 하위 시스템이 존재하지만, 이식 가능한 Docker Compose 빌드에서는 컴파일 시 제외되어 있습니다. 따라서 제한 사항은 호스트 방화벽에서 직접 설정해야 합니다. 또한 제어 평면 API는 Docker 소켓을 구동하므로 사실상 호스트의 root 권한과 같습니다. 기본적으로 127.0.0.1:9090에 바인딩되며, SANDBOXD_API_AUTH_DISABLED은 반드시 false로 유지해야 하고, 절대로 인터넷에 공개해서는 안 됩니다.

다른 사용자가 귀하의 박스로 프롬프트를 보내도록 허용할 계획이라면, 이 모델만으로는 보안이 너무 취약합니다. 이 프로젝트는 샌드박스와 호스트 사이에 사용자 공간 커널을 배치하는 gVisor와 SANDBOXD_RUNTIME=runsc 사용을 권장합니다. 이는 시스템 호출이 많은 작업에서 약 1.7배에서 4배 정도의 성능 저하를 유발합니다. 더 강력한 해결책은 테넌트당 하나의 머신을 할당하는 것이며, 이는 일회용 VM에서 코딩 에이전트 실행하기와 같은 논리입니다.

2개월 된 프로젝트를 기반으로 개발해도 되는가?

개인용 빌드 서버라면 당연히 가능합니다. 단, SANDBOXD_REF 고정, /var/lib/sandboxed 백업, 그리고 중요한 모든 애플리케이션을 git 원격 저장소에 푸시하는 등의 명확한 예방 조치를 취해야 합니다. 고객이 사용하는 서비스라면 1.0 버전이 나올 때까지 기다리거나 장애 발생에 대비한 예산을 책정하십시오. 메인테이너들은 0.x 버전에서 언제든 변경 사항이 발생할 수 있다고 명시하고 있기 때문입니다. 또한 2026년 8월 기준으로 메인테이너들이 월 79달러에 관리형 설치 서비스를 제공하고 있다는 점도 프로젝트의 지속 가능성을 판단할 때 참고할 가치가 있습니다.

이러한 위험을 감수할 수 있는 이유는 결과물 때문입니다. sandboxd는 일반적인 git 저장소에 일반적인 애플리케이션을 생성합니다. 따라서 프로젝트가 중단되더라도 코드는 유지되며 래퍼(wrapper)만 잃게 됩니다. 이는 사용자의 프로젝트를 소유하는 호스팅 빌더 서비스보다 훨씬 유리한 위치입니다. 올해 서버에 올릴 만한 가치가 있는 서비스에 대한 더 넓은 관점은 2026년에 직접 호스팅할 가치가 있는 것들을 참조하십시오.

FAQ

sandboxd를 실행하기 위한 최소 서버 사양은 어떻게 됩니까?

프로젝트에 따르면 2 vCPU와 4 GB RAM이면 제어 평면(control plane), Traefik, 그리고 하나의 작은 샌드박스를 실행하기에 충분합니다. 여러 애플리케이션을 동시에 실행하려면 8 GB RAM과 40 GB 디스크 공간을 권장합니다. 실행 중인 각 샌드박스는 전체 Node 또는 Python 툴체인을 포함하며, 각 작업 공간은 자체 의존성 트리를 디스크에 유지하기 때문입니다. 호스트 자원이 부족해지면 sandboxd의 압력 리퍼(pressure reaper)가 메모리 확보를 위해 샌드박스를 중단시킵니다. 컨테이너의 메모리 제한을 초과하는 빌드는 커널에 의해 강제 종료되며, 이때 docker ps -a은 종료 코드 137을 표시합니다.

sandboxd는 Dify나 OpenHands와 어떻게 다릅니까?

이들은 서로 다른 결과물을 생성합니다. Dify는 챗 인터페이스나 검색 파이프라인처럼 런타임에 모델을 호출하는 애플리케이션을 구축합니다. OpenHands는 이미 보유한 저장소를 편집하며, 명령을 실행하고 기존 코드에 대한 변경 사항을 제안합니다. sandboxd는 프롬프트로부터 완전히 새로운 프로젝트를 스캐폴딩하고, 자체 컨테이너 내부에서 빌드한 뒤 미리보기 URL로 제공합니다. 그 결과물은 실행을 위해 모델이 필요 없는 일반적인 웹 애플리케이션입니다.

에이전트가 작성한 코드는 실제로 어디에 저장됩니까?

컨테이너 이미지가 아닌 호스트 파일 시스템에 저장됩니다. 각 앱은 /var/lib/sandboxed/workspaces/<id>/에 디렉터리를 할당받아 샌드박스에 바인드 마운트되며, 파일은 내부의 /home/sandbox/workspace/app에 나타납니다. 제어 평면 상태는 동일한 데이터 디렉터리 내의 state/에 있는 단일 SQLite 파일로 관리됩니다. 콘솔의 Git 탭이나 /v1/apps/<id>/git/commit 및 /git/push 엔드포인트를 통해 원격 git 저장소로 커밋 및 푸시할 수 있습니다. 비공개 원격 저장소를 위한 토큰은 샌드박스에 전달되지 않고 제어 평면에 의해 암호화되어 저장됩니다.

sandboxd를 인터넷에 노출해도 안전합니까?

미리보기 URL과 콘솔은 노출해도 되지만, 제어 평면 API는 절대 노출해서는 안 됩니다. 해당 API는 호스트에서 Docker를 제어하므로 root 권한과 동일하며, 이러한 이유로 기본적으로 127.0.0.1:9090에 바인딩됩니다. 또한 자체 호스팅 빌드에서 샌드박스는 외부 네트워크 접근이 허용되어 있으므로, 에이전트가 작성한 코드가 로컬 네트워크나 클라우드 메타데이터 엔드포인트에 도달할 수 있습니다. 보호해야 할 대상이 같은 네트워크에 있다면 호스트 방화벽 규칙을 추가하십시오. 신뢰할 수 없는 사용자의 프롬프트를 처리해야 한다면 컨테이너 경계에만 의존하지 말고 테넌트당 하나의 호스트를 운영하십시오.

#sandboxd#ai-agents #self-hosted#app-builder#docker