المشكلة: أدوات مراقبة كثيرة وقنوات إشعارات متفرقة
Uptime Kuma يراقب خدماتك، Beszel يراقب مقاييس VPS، Changedetection.io يراقب صفحاتك، ومهام cron تصمت ليلًا — إلا حين تفشل. لكل أداة قناة إشعارات خاصة: Slack، بريد إلكتروني، webhook، Telegram. النتيجة: خمس تكاملات مختلفة للصيانة وعدم وجود رؤية موحدة حين يتعطل شيء الساعة 3 صباحًا. يحل ntfy هذه المشكلة بطريقة معكوسة: أنت تستضيف مركز الإشعارات، وكل أداة أو سكريبت يرسل تنبيهاته إليه عبر HTTP بسيط.
ما يمنحك إياه ntfy مباشرةً
- أرسل إشعارًا بأمر curl بسيط —
curl -d "فشل البناء" http://vps/تنبيهات-ci— بدون SDK أو مكتبة. - استقبل الإشعارات على Android وiOS والمتصفح وواجهة ntfy الويب — جميعها تشترك في نفس الموضوع.
- إجراءات الإشعارات — أزرار تُطلق استدعاءات HTTP أو تفتح URLs أو تُشغّل أوامر على الجهاز.
- إشعارات مجدولة — تسليم مؤجل (
X-Delay: 30min) لجدولة التذكيرات من السكريبتات. - مستويات الأولوية (دنيا / منخفضة / افتراضية / عالية / عاجلة) مع تجاوز وضع عدم الإزعاج.
- مرفقات — صور أو ملفات حتى 15 ميغابايت عبر رأس
X-Attach. - التحكم في الوصول — أضف مستخدمين وكلمات مرور وقوائم تحكم بالوصول عبر ntfy CLI.
- أقل من 30 ميغابايت RAM وSQLite وحاوية واحدة — أخف خادم إشعارات push مستضاف ذاتيًا.
البنية: pub/sub HTTP في حاوية واحدة
ntfy هو ثنائي Go يعمل في حاوية Docker واحدة. يكشف واجهة HTTP بسيطة: PUT أو POST على /موضوعك ينشر رسالة؛ أي عميل يستمع لهذا الموضوع (عبر WebSocket أو SSE أو التطبيق المحمول) يتلقاها فورًا. تُخزَّن الرسائل في SQLite مع استبقاء قابل للتكوين (12 ساعة افتراضيًا). NTFY_BEHIND_PROXY=true يخبر ntfy أنه خلف nginx.
نشر واستخدام ntfy في 5 خطوات
أول تسجيل دخول
يبدأ ntfy دون أي حساب أو كلمة مرور: يفتح الرابط الواجهة مباشرة، وكل من يعرف العنوان يمكنه القراءة والنشر في أي موضوع. وإذا كان خادمك متاحاً من الإنترنت، فعّل المصادقة قبل استخدامه بشكل جدّي.
نصيحة: أسماء المواضيع كفضاءات أسماء
نظّم تنبيهاتك حسب المصدر: ci-builds لـ GitHub Actions/GitLab CI، server-alerts لـ Uptime Kuma/Beszel، cron-jobs للسكريبتات. يتيح تطبيق ntfy كتم بعض المواضيع ليلًا مع إبقاء server-alerts على أعلى أولوية.
