إيّاك أن تترك تطبيق Bun على خادم إنتاج دون مدير عمليات حقيقي. systemd وPM2 هما الخياران المعتمدان لدى معظم فِرق التطوير في الرياض ودبي وداكار وأبيدجان والقاهرة لإبقاء خدمات Bun (Hono, Elysia, Express) عاملةً 24/7. في هذا الدليل المُحدَّث لعام 2026 نقارن بدقة بين الحلَّين، نعرض ملفات التهيئة الجاهزة للنسخ، ونكشف الأخطاء التي وقع فيها زملاؤنا في الإنتاج.

1. لماذا تحتاج إلى مدير عمليات أصلاً؟

عملية Bun وحيدة الخيط من حيث التشغيل، فإذا تعطّلت فلن يُعيد النواة Linux تشغيلها وحدها. مدير العمليات يضمن: إعادة التشغيل التلقائية بعد التعطل، تشغيل عند الإقلاع، إدارة السجلات، حدّ موارد، Zero-downtime على إعادة النشر، وفصل المستخدم عن العملية لأمان أكبر. على خادم Hetzner CX22 (4.51 € شهرياً) تخدم Bun + systemd خمسة آلاف طلب في الدقيقة دون انقطاع.

2. systemd: الخيار الأصلي على لينكس

أنشئ ملف /etc/systemd/system/api-bun.service بهذا المحتوى:

[Unit]
Description=Bun API service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=app
WorkingDirectory=/srv/api
ExecStart=/usr/local/bin/bun run src/server.ts
Restart=always
RestartSec=5
LimitNOFILE=65536
Environment=NODE_ENV=production
Environment=PORT=3000
StandardOutput=append:/var/log/api-bun/out.log
StandardError=append:/var/log/api-bun/err.log

[Install]
WantedBy=multi-user.target

ثم: systemctl daemon-reload && systemctl enable --now api-bun. للمتابعة: journalctl -u api-bun -f. systemd يعيد التشغيل تلقائياً، ويتعامل مع مستخدمين منفصلين، ويُدمج مع logrotate. هذا هو الخيار المفضّل في 80% من خوادمنا الإنتاجية.

3. PM2: الخيار المتعدد للمنصات

PM2 أداة Node.js شهيرة تعمل أيضاً مع Bun عبر pm2 start --interpreter bun. نقاط قوتها: لوحة تحكم رسومية (PM2 Plus)، ذاكرة-قتل تلقائي، load balancer داخلي بالتفرع (cluster mode غير مدعوم في Bun فعلياً، استعمل reverse proxy عوضاً)، نشر pm2 deploy من جهازك مباشرة. ملف ecosystem.config.cjs:

module.exports = {
  apps: [{
    name: 'api',
    script: 'src/server.ts',
    interpreter: 'bun',
    instances: 1,
    exec_mode: 'fork',
    max_memory_restart: '512M',
    env_production: { NODE_ENV: 'production', PORT: 3000 }
  }]
};

تشغيل: pm2 start ecosystem.config.cjs --env production. حفظ الحالة لإعادة الإقلاع: pm2 save && pm2 startup systemd.

4. مقارنة دقيقة: systemd vs PM2 في 2026

المعيار	systemd	PM2
الاستهلاك RAM	0 MB إضافي	40-80 MB لكل عملية مراقبة
التوافر	مدمج Linux	تثبيت npm منفصل
إعادة تشغيل سريعة	5 ms	180-250 ms
Cluster mode	لا (استعمل HAProxy/Caddy)	غير مفيد مع Bun
Logs	journald	ملفات + داشبورد
تكامل CI/CD	ssh + systemctl reload	pm2 deploy
المنصات	Linux فقط	متعدد

5. النشر دون توقف (Zero downtime)

الحل الواقعي مع Bun: ضع Caddy أو HAProxy أمام نسختين من الخدمة على منفذين مختلفين، أعد تشغيل الأولى، انتظر صحة، ثم الثانية. مع systemd استعمل systemctl reload-or-restart عبر سكربت يبدّل المنفذ في EnvironmentFile. مع PM2 استعمل pm2 reload api لكنه ليس صفر-توقف حقيقي مع Bun.

6. مراقبة الإنتاج: السجلات والمؤشرات

اشحن السجلات إلى Loki (مفتوح المصدر) أو Better Stack (مدفوع). مع journald: vector أو promtail يُرسلان كل سطر إلى Loki ثم Grafana. أضف نقطة /health و/metrics في تطبيقك. ادمج uptime-kuma الذاتي الاستضافة لإطلاق تنبيهات WhatsApp أو Discord إلى فريق الدعم في تونس أو أبيدجان.

7. الأمان: المستخدم، الجدار الناري، الحدود

لا تشغّل Bun بـ root أبداً. أنشئ مستخدم app بصلاحيات قراءة فقط على المجلد. حُدّ موارد systemd عبر MemoryMax=512M وCPUQuota=200%. قيّد المنافذ المفتوحة بـ UFW (ufw allow 443) ووجّه طلبات Caddy داخلياً عبر شبكة Tailscale.

8. الأخطاء الشائعة

الخطأ	السبب	الحل
service crashes loop	RestartSec=0	حدد RestartSec=5 وراقب السبب الجذري
EADDRINUSE	عملية قديمة لم تُغلَق	fuser -k 3000/tcp قبل الإقلاع
logs غير دوارة	نسي logrotate	أضف /etc/logrotate.d/api-bun
زمن استجابة عشوائي	GC غير مضبوط	BUN_JSC_useShadowChicken=0 في البيئة

9. أسئلة متكررة

هل أحتاج Docker؟ ليس ضرورياً. systemd كافٍ على VPS صغير. Docker مفيد للنشر المتعدد العقد عبر Coolify.

كم عدد الطلبات التي تتحملها عملية Bun واحدة؟ 8000 req/s على CCX13 لاستجابة JSON بسيطة، 1200 req/s مع PostgreSQL.

كيف أبدّل بين البيئتين؟ ملفان api-bun.service وapi-bun-staging.service مع EnvironmentFile مختلف.

نشر Bun في الإنتاج: systemd أو PM2 (دليل 2026)