خادم Linux

يعمل AWS (EC2 / Lightsail / الفئة المجانية) جيدًا أيضًا. يتوفر شرح فيديو تفصيلي من المجتمع على x.com/techfrenAJ/status/2014934471095812547 (مورد مجتمعي — قد يصبح غير متاح).

كيفية عمل الإعدادات السحابية

• يعمل Gateway على خادم VPS ويمتلك الحالة + مساحة العمل.
• تتصل من حاسوبك المحمول أو هاتفك عبر واجهة التحكم أو Tailscale/SSH.
• تعامل مع خادم VPS بوصفه مصدر الحقيقة، وأنشئ نسخًا احتياطية من الحالة + مساحة العمل بانتظام.
• الإعداد الافتراضي الآمن: أبقِ Gateway على local loopback وصِل إليه عبر نفق SSH أو Tailscale Serve. إذا ربطته بـ lan أو tailnet، فسيتطلب Gateway سرًا مشتركًا (gateway.auth.token أو gateway.auth.password) ما لم تُفوَّض المصادقة إلى وكيل موثوق.

صفحات ذات صلة: الوصول البعيد إلى Gateway، مركز المنصات.

حصّن وصول الإدارة أولًا

قبل تثبيت OpenClaw على خادم VPS عام، حدّد الطريقة التي تريد بها إدارة الخادم نفسه.

• لقصر وصول الإدارة على Tailnet فقط: ثبّت Tailscale أولًا، وأضف خادم VPS إلى شبكة tailnet الخاصة بك، وتحقق من جلسة SSH ثانية عبر عنوان IP الخاص بـ Tailscale أو اسم MagicDNS، ثم قيّد الوصول العام عبر SSH.
• من دون Tailscale: طبّق إجراءات التحصين المكافئة على مسار SSH قبل كشف المزيد من الخدمات.
• هذا منفصل عن الوصول إلى Gateway. لا يزال بإمكانك إبقاء OpenClaw مرتبطًا بـ local loopback واستخدام نفق SSH أو Tailscale Serve للوصول إلى لوحة المعلومات.

توجد خيارات Gateway الخاصة بـ Tailscale في Tailscale.

وكيل مشترك للشركة على خادم VPS

يُعد تشغيل وكيل واحد لفريق إعدادًا صالحًا عندما يكون جميع المستخدمين ضمن حدود الثقة نفسها ويكون الوكيل مخصصًا للأعمال فقط.

• أبقِه في بيئة تشغيل مخصصة (خادم VPS/جهاز افتراضي/حاوية + مستخدم/حسابات مخصصة لنظام التشغيل).
• لا تسجّل دخول بيئة التشغيل هذه إلى حسابات Apple/Google الشخصية أو ملفات المتصفح/مدير كلمات المرور الشخصية.
• إذا كان المستخدمون خصومًا لبعضهم، فافصل بينهم حسب Gateway/المضيف/مستخدم نظام التشغيل.

تفاصيل نموذج الأمان: الأمان.

استخدام العُقد مع خادم VPS

يمكنك إبقاء Gateway في السحابة وإقران العُقد على أجهزتك المحلية (Mac/iOS/Android/من دون واجهة رسومية). توفر العُقد إمكانات الشاشة/الكاميرا/مساحة الرسم المحلية وsystem.run بينما يظل Gateway في السحابة.

الوثائق: العُقد، CLI للعُقد.

تحسين بدء التشغيل للأجهزة الافتراضية الصغيرة ومضيفي ARM

إذا بدت أوامر CLI بطيئة على الأجهزة الافتراضية منخفضة القدرة (أو مضيفي ARM)، ففعّل ذاكرة التخزين المؤقت لتجميع وحدات Node:

grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cachemkdir -p /var/tmp/openclaw-compile-cacheexport OPENCLAW_NO_RESPAWN=1EOFsource ~/.bashrc

• يحسّن NODE_COMPILE_CACHE أزمنة بدء تشغيل الأوامر المتكررة؛ ويهيئ التشغيل الأول ذاكرة التخزين المؤقت.
• يُبقي OPENCLAW_NO_RESPAWN=1 عمليات إعادة التشغيل الاعتيادية لـ Gateway ضمن العملية نفسها، ما يتجنب عمليات التسليم الإضافية بين العمليات ويُبقي تتبّع PID بسيطًا على المضيفين الصغار.
• للحصول على التفاصيل الخاصة بـ Raspberry Pi، راجع Raspberry Pi.

قائمة تحقق لتحسين systemd (اختيارية)

بالنسبة إلى مضيفي الأجهزة الافتراضية الذين يستخدمون systemd، ضع في اعتبارك ما يلي:

• متغيرات بيئة الخدمة لمسار بدء تشغيل مستقر: OPENCLAW_NO_RESPAWN=1 و NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
• سلوك صريح لإعادة التشغيل: Restart=always وRestartSec=2 وTimeoutStartSec=90
• أقراص مدعومة بوحدات SSD لمسارات الحالة/ذاكرة التخزين المؤقت لتقليل أعباء البدء البارد الناتجة عن عمليات الإدخال/الإخراج العشوائية.

يثبّت المسار القياسي openclaw onboard --install-daemon وحدة مستخدم لـ systemd؛ عدّلها باستخدام:

systemctl --user edit openclaw-gateway.service

[Service]Environment=OPENCLAW_NO_RESPAWN=1Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cacheRestart=alwaysRestartSec=2TimeoutStartSec=90

إذا كنت قد ثبّتَّ وحدة نظام عمدًا بدلًا من ذلك، فعدّلها عبر sudo systemctl edit openclaw-gateway.service.

كيف تساعد سياسات Restart= في الاسترداد الآلي: يمكن لـ systemd أتمتة استرداد الخدمة.

للتعرف على سلوك نفاد الذاكرة في Linux، واختيار العملية الفرعية الضحية، وتشخيصات exit 137، راجع ضغط الذاكرة وعمليات الإنهاء بسبب نفاد الذاكرة في Linux.

ذو صلة

• نظرة عامة على التثبيت
• DigitalOcean
• Fly.io
• Hetzner