لماذا تستضيف Trigger.dev ذاتيًا على خادم VPS
يستبدل Trigger.dev الطوابير المصنوعة يدويًا (BullMQ، وcron هشّة، وLambda التي تنتهي مهلتها) بمنصة موحّدة: مهام دائمة، وإعادات محاولة تلقائية، وإدارة للتزامن، ولوحة تحكم في الزمن الحقيقي. تفرض نسخة SaaS رسومًا حسب عدد عمليات التنفيذ وتحدّ من مدة المهام، وهو ما يصبح مُقيِّدًا سريعًا لمعالجة ETL أو إرسال رسائل بريد إلكتروني بالجملة أو استدعاءات API بطيئة. وبالاستضافة الذاتية على خادم VPS، تُبقي workers لديك عندك: لا تمرّ مفاتيح API الطرف الثالث (OpenAI، Stripe، Resend) عبر أي طرف ثالث، ويمكن أن تعمل مهامك 10 دقائق أو عدة ساعات دون أن تُقطع. تعتمد الحزمة على PostgreSQL وRedis ومنسّق Docker، ما يجعلها قابلة لإعادة الإنتاج وسهلة النسخ الاحتياطي.
ما الذي تكسبه بالاستضافة الذاتية
- لا حدّ على مدة أو عدد عمليات تنفيذ مهامك في الخلفية.
- تبقى أسرارك (مفاتيح API، رموز) في بنيتك التحتية، وليس على خدمة SaaS طرف ثالث أبدًا.
- تكلفة ثابتة قابلة للتوقّع: خادم VPS واحد بدلًا من فاتورة ترتفع مع الحجم.
- زمن استجابة أقل إن كانت workers لديك تعمل بجوار قاعدة بياناتك وتطبيقك.
- تحكّم كامل في الإصدارات ومتغيرات البيئة ومدة الاحتفاظ بالسجلات.
- إمكانية إطلاق المهام من webhooks الداخلية لديك دون كشف أي خدمة خارجية.
المتطلبات العتادية والبرمجية
Trigger.dev حزمة كثيفة الاستهلاك نسبيًا لأنها تجمع بين تطبيق الويب وworkers وPostgreSQL وRedis. خصّص خادم VPS بذاكرة 4 غيغابايت RAM و2 vCPU كحد أدنى لاستخدام إنتاجي خفيف؛ واستهدف 8 غيغابايت RAM و4 vCPU إن كنت تشغّل عددًا كبيرًا من المهام المتزامنة أو عمليات معالجة ثقيلة. احسب 40 غيغابايت من قرص SSD لقاعدة البيانات والسجلات وصور Docker. على الصعيد البرمجي: Docker Engine 24+ وإضافة Docker Compose v2، واسم نطاق (مثل trigger.mydomain.com) يشير إلى عنوان IP الخاص بالخادم، والمنفذ 443 مفتوحًا لـ HTTPS. لا غنى عن مفتاح MAGIC_LINK_SECRET وENCRYPTION_KEY (32 محرفًا سِتّ عشريًا) لتشفير متغيرات البيئة الخاصة بالمشاريع.
نشر Trigger.dev باستخدام Docker في 5 خطوات
تحضير الخادم VPS وDocker
اتصل عبر SSH، وحدّث النظام ثم ثبّت Docker وCompose: curl -fsSL https://get.docker.com | sh. أنشئ مستخدمًا مخصّصًا ومجلد /opt/trigger لاستضافة الإعدادات. تحقّق باستخدام docker compose version.
الحصول على حزمة الاستضافة الذاتية الرسمية
استنسخ مستودع النشر: git clone https://github.com/triggerdotdev/trigger.dev. يحتوي المجلد docker/ على ملف docker-compose.yml الذي يجمع تطبيق الويب وworkers وPostgreSQL وRedis. انسخ .env.example إلى .env.
توليد الأسرار وضبط النطاق
ولّد مفاتيحك باستخدام openssl rand -hex 16 لـ ENCRYPTION_KEY وMAGIC_LINK_SECRET. اضبط LOGIN_ORIGIN وAPP_ORIGIN على https://trigger.mydomain.com. حدّد بيانات اعتماد PostgreSQL وعنوان URL الداخلي لـ Redis.
تشغيل الحزمة
شغّل المجموعة كلها باستخدام docker compose up -d. تابع تهيئة عمليات الترحيل عبر docker compose logs -f webapp. وبمجرد أن يصبح التطبيق متاحًا على المنفذ الداخلي (3030 افتراضيًا)، أنشئ أول حساب مسؤول عبر الـ magic link المعروض في السجلات.
الكشف عبر وكيل عكسي بـ HTTPS
ضع Caddy أو Traefik أمام التطبيق لإدارة TLS تلقائيًا. مع Caddy: يكفي سطر واحد trigger.mydomain.com { reverse_proxy localhost:3030 } للحصول على شهادة Let's Encrypt وتفعيل HTTPS. ثم اربط مشروعك المحلي باستخدام npx trigger.dev@latest login --api-url https://trigger.mydomain.com.
اعزل workers عن تطبيق الويب في حاويات منفصلة، وحُدّ من تزامنها عبر المتغير WORKER_CONCURRENCY. وبالنسبة للمهام الشديدة الاستهلاك للمعالج، أضف خادم VPS ثانيًا مخصّصًا للـ workers يشير إلى نفس PostgreSQL وRedis: بذلك تتوسّع أفقيًا دون المساس بلوحة التحكم. فكّر أيضًا في عملية cron يومية pg_dump نحو تخزين خارجي، لأن كل منطق مهامك وسجلها يعيش في PostgreSQL.
