كيفية استضافة sandboxd على VPS وتشغيله ذاتيًا

ما هو sandboxd، وما الذي تحصل عليه عند تشغيله بنفسك

لاستضافة sandboxd ذاتياً، تحتاج إلى خادم Linux واحد يحتوي على Docker واسم نطاق. ترسل مطالبة، فيبني وكيل برمجي تطبيقاً فعلياً داخل حاوية معزولة، ثم يصبح التطبيق متاحاً على عنوان URL للمعاينة خاص به. تُعد أدوات تحويل المطالبات إلى تطبيقات الفئة الأبرز في الاستضافة لعام 2026، وsandboxd هو النظام الذي يعمل على VPS الخاص بك، بموجب ترخيص MIT، بينما يبقى الرمز البرمجي المُولَّد على القرص الخاص بك.

التصميم صغير عمداً. تدير طبقة التحكم المكتوبة بلغة Go ‏Docker، ويوجّه Traefik v3 كل اسم مضيف للمعاينة، وتحتفظ SQLite بالحالة، ويعمل كل تطبيق داخل حاوية واحدة. لا يوجد Kubernetes ولا خادم قاعدة بيانات منفصل، ولذلك يستطيع خادم بسعة 2 vCPU تشغيله أصلاً.

تحمل أربعة كائنات النموذج بأكمله. التطبيق هو المشروع الدائم، ويحتوي على اسمه وبيانات git الوصفية والأسرار الخاصة به. صندوق الاختبار هو حاوية Docker التي يعمل فيها التطبيق، ويشير كل تطبيق إلى صندوق اختبار واحد في كل مرة. مساحة العمل هي ملفات التطبيق، وتوجد على المضيف وتبقى بعد إزالة الحاوية. المهمة هي مطالبة واحدة تُسلَّم إلى الوكيل داخل صندوق الاختبار. يؤدي إيقاف صندوق الاختبار إلى تحرير الذاكرة مع الاحتفاظ بالملفات. أما تدميره فيزيل الحاوية، ويمكن للتطبيق تشغيل صندوق اختبار جديد.

ما الفرق بين sandboxd وDify وOpenHands؟

يحدث الخلط بين هذه الأدوات الثلاث لأنّها جميعاً تشغّل نموذج لغة كبيراً (LLM) على خادمك، لكنّها تنتج أشياء مختلفة. تبني Dify تطبيقات تعتمد على نماذج LLM: واجهات محادثة، وخطوط معالجة للاسترجاع، وسير عمل يستدعي نموذجاً في كل مرة يستخدمه أحد. يكون النموذج جزءاً من المنتج النهائي. يعمل OpenHands على مستودع لديك مسبقاً: تشير إليه إلى شيفرتك، فيقرأ الملفات، وينفّذ الأوامر، ويقترح التغييرات. يبدأ sandboxd من لا شيء. فهو ينشئ هيكل مشروع انطلاقاً من إعداد مسبق، ويبنيه داخل حاوية جديدة، ويمنحك URL لعرضه. والناتج تطبيق React أو FastAPI عادي لا يحتاج إلى نموذج لتشغيله.

لذلك اختر الأداة وفقاً لما تريد الحصول عليه في النهاية. يناسب sandboxd البدء من جملة والاحتفاظ بالشيفرة بعد ذلك. أما الأداتان الأخريان فتناسبان الحالات التي يكون فيها المستودع أو المنتج المعتمد على نموذج موجوداً مسبقاً.

والفرق الآخر هو عمر المشروع، وهو العامل الذي ينبغي موازنته قبل بناء أي شيء فعلي اعتماداً عليه.

[
  {
    "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 نجمة، مقابل 83,091 لـOpenHands و151,320 لـDify. أُنشئ المستودع في 3 June 2026، ولذلك كان عمره شهرين في August 2026، بينما يعود OpenHands إلى March 2024 وDify إلى April 2023. صدر الإصدار v0.1.0 في 6 June 2026، والإصدار v0.3.6 في 1 August 2026. يصف المشروع نفسه بأنّه تجريبي، ويذكر أنّ إصدارات 0.x قد تكسر التوافق. اقرأ هذه الأرقام باعتبارها مؤشراً إلى مخاطر الاعتماديات، لا حكماً على الجودة: فالمشروع الذي يبلغ عمره شهرين لم تتح له سوى شهرين كي يكتشف الآخرون أخطاءه.

ما يحتاج إليه الخادم، وما يتعطل عند نقصه

يذكر المشروع أن 2 vCPU و4 GB من RAM تكفيان للبدء. وهذا صحيح بالنسبة إلى control plane مع sandbox صغيرة واحدة، لكنه لا يكفي لشخصين ينفذان عمليات build في الوقت نفسه. خصّص الذاكرة على أجزاء. إنَّ Traefik وGo control plane صغيران من حيث استهلاك الذاكرة. تحتوي كل sandbox قيد التشغيل على toolchain كاملة لـ Node أو Python، وتبلغ الذروة عند تنفيذ npm install ثم production build. خطط لاستخدام 8 GB على جهاز سيبقي عدة تطبيقات قيد التشغيل، وتعامل مع swap كشبكة أمان لا كسعة إضافية، لأن عملية build التي تستخدم swap تستغرق دقائق بدلاً من ثوانٍ.

عند نفاد الذاكرة، يحدث فشلان مختلفان، ولا يتشابهان في الظاهر. داخل sandbox، تصل الحاوية إلى حد --memory الصارم الذي يحدده sandboxd، ثم يقتل kernel العملية الأكبر، فتفشل عملية build من دون رسالة مفيدة من agent. يعرض docker ps -a رمز الخروج 137 لتلك الحاوية، ويعرض docker inspect عليها القيمة "OOMKilled": true. وغالباً ما تطبع عملية Node build التي تفشل بهذه الطريقة JavaScript heap out of memory أولاً.

يحدث الفشل الثاني على المضيف. يشغّل sandboxd عملية pressure reaper توقف sandboxes عندما تنخفض ذاكرة المضيف، لذلك قد تختفي sandbox على جهاز صغير أثناء مراقبتك للـpreview. تبقى الملفات سليمة، ويوقظها الطلب التالي إلى عنوان preview URL، لكن المهمة التي كانت قيد التشغيل عند توقف الحاوية لا تُستأنف.

القرص هو المشكلة الأقل وضوحاً. تحتفظ كل app بمساحة عمل خاصة بها على المضيف، ويحتوي مشروع JavaScript على شجرة node_modules بحجم مئات الميغابايت. وتشغل 10 تطبيقات عدة غيغابايت من dependencies قبل احتساب images. ابدأ بسعة 40 GB وراقبها:

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

مجلد البيانات الافتراضي هو /var/lib/sandboxed، ويُكتب مع e الإضافية. يؤدي إدخال /var/lib/sandboxd إلى الوصول إلى مجلد فارغ وإضاعة خمس دقائق في التحقق من السبب.

تثبيت إصدار sandboxd محدد

يجب أن يكون Docker Engine مع إضافة Compose، إضافة إلى git، مثبتاً على الخادم أولاً. يشرح تثبيت Docker على VPS هذا الجانب.

docker compose version
git --version

يجب أن يطبع كلاهما رقم إصدار. يعني docker: 'compose' is not a docker command أن لديك ملف docker-compose الثنائي المستقل القديم، بينما يتوقع المثبّت إضافة v2.

المثبّت عبارة عن shell script يُجلب عبر الشبكة، لذلك اقرأه قبل تشغيله، وثبّت الإصدار.

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 مرجع git الذي ينسخه المثبّت إلى $HOME/.sandboxd/src، وقيمته الافتراضية هي main. يعني تركه دون ضبط أن الإصدار المثبت هو أي تغييرات دُمجت في ذلك الصباح، وهذا مهم في مشروع أصدر ستة إصدارات في يوليو 2026 وحده. ثبّت الإصدار، ثم رقّه عمداً بعد قراءة سجل التغييرات.

ينسخ البرنامج النصي المصدر، ويبني الصور، ويشغّل الحزمة باستخدام docker compose up -d، ثم يطبع في النهاية عنوان URL لوحدة التحكم ورمز API. احفظ هذا الرمز في مكان آمن. فهو بيانات اعتماد لواجهة API تتحكم في Docker بصلاحيات root.

curl http://127.0.0.1:9090/healthz

يطبع ذلك ok عندما تصبح طبقة التحكم قيد التشغيل. إذا لم يطبع شيئاً، فهذا يعني أن الحزمة لم تبدأ. شغّل docker compose ps من ~/.sandboxd/src لمعرفة الخدمة المتوقفة، ثم شغّل docker compose logs sandboxd لمعرفة السبب.

الوصول إلى وحدة التحكم على خادم بعيد

تُقدَّم وحدة التحكم عبر Traefik على HTTP_PORT، وهو المنفذ 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، وتتضمن تدفق OAuth إرشادياً إذا أردت استخدام اشتراك Claude بدلاً من مفتاح API. يوجد النموذج الافتراضي لكل وكيل في اللوحة نفسها، ويمكن لمهمة واحدة تجاوز هذا الإعداد.

إنشاء تطبيق صغير من البداية إلى النهاية

أنشئ التطبيق، وشغّل بيئة الاختبار المعزولة، ثم أرسل مطالبة. تعود المعرّفات بصيغة 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"

يجب أن يحتوي المتغيران على معرّف. تعني قيمة $SB الفارغة أن بيئة الاختبار المعزولة لم تبدأ قط. والسبب المعتاد هو أن الصورة الأساسية ما زالت قيد الإنشاء أو أن ذاكرة المضيف غير كافية. وتعني قيمة 401 بدلاً من المعرّف أن 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"}'

يحمل الرد معرّف مهمة. يعرض GET /v1/sandboxes/$SB/tasks/<task id> النتيجة، بينما يكون المسار /events ضمن المهمة نفسها تدفق SSE (أحداث يرسلها الخادم) مباشراً لما ينفذه العامل. وتعرض وحدة التحكم التدفق نفسه على هيئة محادثة.

يصبح التطبيق متاحاً على http://s-<sandbox id>-3000.preview.localhost، حيث يمثّل 3000 المنفذ الذي طلبته. إذا كانت بيئة الاختبار المعزولة متوقفة مؤقتاً، يصل الطلب الأول إلى المعالج العام في Traefik، ثم يبدأ sandboxd الحاوية وينتظر استجابة المنفذ، ويعرض صفحة قصيرة تفيد ببدء التشغيل وتُحدّث نفسها لعرض تطبيقك. إذا بقيت المعاينة على هذه الصفحة، فهذا يعني أن العملية داخل الحاوية لا تستمع على المنفذ المعرّف في sandbox.yaml الخاص بالتطبيق.

ضع المعاينات على نطاق حقيقي مع HTTPS

تحصل كل بيئة اختبار معزولة على اسم مضيف خاص بها، لذلك يغطي سجل DNS عام واحد جميع البيئات. وجّه *.preview.yourdomain.com إلى عنوان IP الخاص بالخادم باستخدام سجل A. ثم اضبط متغيرات المعاينة في .env داخل ~/.sandboxd/src:

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

يحتاج Traefik إلى الجزء المقابل: فعّل نقطة الدخول websecure في traefik/traefik.yml وأضف محلّل شهادات. استخدم تحدي DNS-01، لأن شهادة عامة واحدة تغطي بعد ذلك كل أسماء مضيفي المعاينات. أما مع HTTP-01، فستحتاج كل بيئة اختبار جديدة إلى إصدار شهادة خاص بها، وقد تؤدي عمليات البناء الكثيفة خلال فترة قصيرة إلى تجاوز حدود معدل Let's Encrypt. يشرح الشهادات العامة باستخدام تحدي DNS-01 جانب DNS من ذلك.

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

تصبح عناوين المعاينات https://s-<id>-3000.preview.yourdomain.com. افتح المنفذين 80 و443 في الجدار الناري، وأبقِ المنفذ 9090 مغلقاً أمام الإنترنت: راجع قواعد ufw الأساسية للجدار الناري. تذكّر أن أي شخص يستطيع تخمين اسم مضيف المعاينة يمكنه تحميل التطبيق، لذلك تعامل مع المعاينات على أنها عامة.

أين يستقر الرمز المُنشأ، وهل يمكن تصديره؟

على المضيف، داخل دليل البيانات. كل مساحة عمل عبارة عن دليل عادي في /var/lib/sandboxed/workspaces/<id>/، ويُربط داخل الحاوية باستخدام bind mount، بينما توجد ملفات التطبيق في /home/sandbox/workspace/app داخل بيئة العزل. تكون حالة طبقة التحكم في ملف SQLite واحد في state/sandboxd.db، وتوجد بيانات اعتماد الوكيل المشفّرة في agent-auth/. لا شيء مخفي داخل طبقة الحاوية، لذلك تتكوّن النسخة الاحتياطية من نسخ الدليل وملف قاعدة البيانات. يتولى إجراء نسخ احتياطية باستخدام restic على VPS الأمرين.

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

تصدير Git مدمج في التطبيق، وليس إضافة منفصلة. تتيح API قراءة الحالة والفروقات، ثم تنفيذ 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"}'

يحتاج المستودع الخاص إلى personal access token، ويُضبط مرة واحدة في وحدة التحكم ضمن Settings ثم Git credentials. يُخزَّن الرمز مشفّراً ويبقى خارج بيئة العزل، لذلك لا يستطيع الوكيل قراءته أو استخدامه لتنفيذ push من دون علمك. نفّذ push مبكراً وبانتظام. إلى أن تفعل ذلك، يبقى دليل مساحة العمل النسخة الوحيدة من الرمز، ويؤدي DELETE /v1/apps/<id> إلى حذفه نهائياً.

ما تكلفة عملية البناء بوحدات النموذج؟

لا يقيس sandboxd إنفاقك، لذلك يجب الرجوع إلى الرقم الظاهر في لوحة تحكم مزوّد الخدمة. نماذج OpenCode Zen المجانية لا تكلّف شيئاً، لكنها أبطأ وأضعف من النموذج المدفوع. يظهر ذلك في زيادة جولات التصحيح عند العمل على أي شيء يتجاوز تطبيقاً تجريبياً بسيطاً.

تتبع الفاتورة طريقة عمل حلقة الوكيل. يعيد كل دور إرسال السياق الذي يحتاج إليه. لذلك ترتبط التكلفة بعدد الأدوار، لا بعدد التطبيقات. يكون الطلب الواحد الذي ينجح من المحاولة الأولى منخفض التكلفة. أما تنفيذ 15 جولة من طلبات مثل «أصلح تباعد العناصر الآن» على مشروع يضم 50 ملفاً، فليس منخفض التكلفة، لأن محتويات الملفات تُرسل في كل مرة. تُسعَّر وحدات الإدخال والإخراج بشكل مختلف، ويوضح ما تكلفة وكيل البرمجة لكل جلسة النطاق الواقعي للتكلفة. ضع حداً صارماً للإنفاق لدى مزوّد الخدمة قبل أن تترك حلقة تعمل دون إشراف وبصلاحية الوصول إلى النظام.

تنظيف بيئات الاختبار القديمة

يوقف نظام التخلص من البيئات الخاملة أي بيئة اختبار ظلت خاملة لأكثر من SANDBOXD_IDLE_THRESHOLD_SECONDS، وتكون القيمة الافتراضية 2100 ثانية، أي 35 دقيقة. يحرر ذلك ذاكرة RAM مع الاحتفاظ بالملفات، ويوقظ الطلب التالي إلى عنوان URL للمعاينة الحاوية. خفّض هذه المدة على الخوادم الصغيرة، لأن بقاء الحاويات خاملة لمدة 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 مساحة أكبر مما تتوقع من صور النظام القابلة للاستصلاح، لأن كل تطبيق جلب toolchain الخاص به خلّف طبقات. يحذف docker image prune الطبقات غير المرتبطة. تحقّق من GET /v1/apps أولاً، لأن الصورة التي لا تزال بيئة اختبار خاملة تشير إليها لا تُعد مهملات.

ما يوفّره حدّ الحاوية وما لا يوفّره

تعمل كل بيئة معزولة كمستخدم غير مميّز، مع نظام ملفات root للقراءة فقط، وإسقاط جميع إمكانات Linux، وضبط no-new-privileges، وحد أقصى للذاكرة، وحد أقصى لعدد العمليات. يوضح المشروع هذا الحد بوضوح: حاوية Linux ذات نواة مشتركة توفر حداً قوياً للعزل، لكنها توفر حداً ضعيفاً للأمان. ويؤدي أي خلل في النواة إلى اختراق المضيف.

تتطلب حقيقتان اتخاذ إجراء. فالاتصالات الصادرة من الشبكة داخل البيئة المعزولة مفتوحة في الإصدار المستضاف ذاتياً، ولذلك يمكن للتعليمات البرمجية المُنشأة الوصول إلى الإنترنت، وشبكتك المحلية، ونقاط نهاية بيانات التعريف السحابية. يوجد نظام فرعي للاتصالات الصادرة باستخدام nftables في المصدر، لكنه معطّل عند التجميع في إصدار Docker Compose المحمول، ما يعني أن القيود يجب أن يفرضها جدار الحماية على المضيف. كما أن واجهة API الخاصة بطبقة التحكم تملك عملياً صلاحيات root على المضيف لأنها تتحكم في Docker socket. وهي تستمع على 127.0.0.1:9090 افتراضياً، ويجب أن تبقى SANDBOXD_API_AUTH_DISABLED على false، ولا ينبغي أبداً نشرها على الإنترنت.

إذا كنت تخطط للسماح لأشخاص آخرين بإرسال prompts إلى جهازك، فهذا النموذج ضعيف أكثر من اللازم بمفرده. يشير المشروع إلى gVisor مع SANDBOXD_RUNTIME=runsc، إذ يضع نواة تعمل في مساحة المستخدم بين البيئة المعزولة والمضيف، مع كلفة تتمثل في أن العمليات كثيفة استدعاءات النظام تصبح أبطأ بنحو 1.7 إلى 4 مرات. والحل الأقوى هو تخصيص جهاز واحد لكل مستأجر، وهو المبرر نفسه وراء تشغيل وكلاء البرمجة في آلة افتراضية مؤقتة.

هل ينبغي أن تبني على مشروع مضى على إصداره شهران؟

بالنسبة إلى خادم بناء شخصي، نعم، مع اتخاذ الاحتياطات الواضحة: ثبّت إصدار SANDBOXD_REF، وأنشئ نسخاً احتياطية من /var/lib/sandboxed، وادفع كل تطبيق مهم لديك إلى مستودع git بعيد. أما إذا كان أي عميل سيتعامل معه، فانتظر حتى الإصدار 1.0 أو خصّص ميزانية لمعالجة الأعطال، لأن القائمين على المشروع يذكرون بوضوح أن إصدارات 0.x قد تتغير دون توافق مع إعدادك الحالي. كما يبيع القائمون على المشروع تثبيتاً مُداراً بسعر 79 دولاراً شهرياً اعتباراً من أغسطس 2026. من المفيد معرفة ذلك عند تقييم ما إذا كان للمشروع سبب للاستمرار.

يمكن تحمّل هذا الخطر بسبب الناتج. ينشئ sandboxd تطبيقاً عادياً داخل مستودع git عادي. لذلك، إذا توقف المشروع، يبقى لديك الكود وتفقد الغلاف فقط. وهذا أفضل بكثير من استخدام أداة بناء مستضافة تملك مشروعك. ولمعرفة الصورة الأوسع لما يستحق الاستضافة الذاتية على خادمك هذا العام، راجع ما الذي يستحق الاستضافة الذاتية في 2026.

FAQ

ما مواصفات الخادم الدنيا اللازمة لـ sandboxd؟

يذكر المشروع أن 2 vCPU و4 GB من RAM تكفي للبدء، وهذا يشمل مستوى التحكم وTraefik وsandbox صغيرة واحدة. استخدم 8 GB و40 GB من مساحة القرص إذا أردت تشغيل عدة تطبيقات في الوقت نفسه، لأن كل sandbox قيد التشغيل تحتوي على سلسلة أدوات Node أو Python كاملة، ويحتفظ كل workspace بشجرة تبعياته الخاصة على القرص. عندما تنخفض الموارد المتاحة على المضيف، يوقف pressure reaper في sandboxd بعض sandboxes لتحرير الذاكرة، وتُنهي النواة عملية build التي تتجاوز الحد الأقصى للذاكرة المحدد لحاويتها: يعرض docker ps -a رمز الخروج 137 لهذه العملية.

كيف يختلف sandboxd عن Dify أو OpenHands؟

تنتج هذه الأدوات مخرجات مختلفة. ينشئ Dify تطبيقات تستدعي نموذجاً أثناء التشغيل، مثل واجهات الدردشة ومسارات الاسترجاع. ويعدّل OpenHands مستودعاً موجوداً لديك، إذ يشغّل الأوامر ويقترح تغييرات على الشفرة الحالية. أما sandboxd فينشئ هيكل مشروع جديد تماماً من prompt، ويبنيه داخل حاويته الخاصة، ويعرضه عبر preview URL. والنتيجة تطبيق ويب عادي لا يحتاج إلى نموذج لكي يعمل.

أين توجد الشفرة التي يكتبها الوكيل فعلياً؟

توجد على نظام ملفات المضيف، وليس داخل صورة حاوية. يحصل كل تطبيق على دليل في /var/lib/sandboxed/workspaces/<id>/، ويُربط هذا الدليل داخل sandbox باستخدام bind mount، وتظهر الملفات في /home/sandbox/workspace/app داخلها. تكون حالة مستوى التحكم في ملف SQLite واحد ضمن state/ في دليل البيانات نفسه. يمكنك تنفيذ commit وpush إلى git remote من علامة Git في console، أو عبر نقطتي النهاية /v1/apps/<id>/git/commit و/git/push. ويخزّن مستوى التحكم token الخاص بالمستودعات الخاصة مشفراً، بدلاً من تمريره إلى sandbox.

هل تعريض sandboxd للإنترنت آمن؟

عرّض preview URLs وconsole، ولا تعرّض control plane API. تتحكم واجهة API هذه في Docker على المضيف، ولذلك تعادل صلاحيات root، كما أنها تستمع على 127.0.0.1:9090 افتراضياً لهذا السبب. تملك sandboxes أيضاً صلاحية إخراج مفتوحة إلى الشبكة في النسخة المستضافة ذاتياً، ما يعني أن الشفرة التي يكتبها الوكيل يمكنها الوصول إلى شبكتك المحلية ونقاط نهاية cloud metadata. لذلك أضف قواعد إلى جدار الحماية على المضيف إذا كان الخادم متصلاً بأنظمة أخرى يجب حمايتها. وبالنسبة إلى prompts الواردة من أشخاص لا تثق بهم، شغّل مضيفاً واحداً لكل tenant بدلاً من الاعتماد على عزل الحاوية.