المصادر المفتوحة للفريق التقني في الشركة الناشئة: ماذا تستضيف بنفسك ومتى؟

في الأشهر الأولى من عمر الشركة الناشئة يكون الفريق التقني ثلاثة أو أربعة مهندسين، وكل أداة يحتاجونها تبدأ بخطة مجانية أو باشتراك صغير لا يلفت النظر، مستودعات الكود Code في GitHub، والمحادثات في Slack، وكلمات المرور في مدير كلمات مرور سحابي، وتتبع الأخطاء في Sentry، ثم يكبر الفريق إلى خمسة عشر شخصاً فتجد أن أغلب هذه الاشتراكات تحسب لكل مستخدم Per Seat، وأن الفاتورة الشهرية تكبر مع كل موظف جديد في الوقت نفسه الذي تحاول فيه الشركة أن تطيل المدة التي يكفيها فيها التمويل Runway. وفي المقابل، إذا قررت أن تستضيف كل شيء بنفسك من اليوم الأول، فسوف تكتشف أن أغلى ما تملكه الشركة ليس المال وإنما وقت مهندسيها، وأن كل ساعة يقضيها المهندس في إصلاح سيرفر هي ساعة لم يقضها في بناء المنتج.

لذلك فالسؤال الصحيح في الشركة الناشئة ليس «هل نستخدم المصادر المفتوحة Open Source؟» وإنما «ماذا نستضيف بأنفسنا، ومتى، وما الذي نتركه لخدمة مدارة Managed Service؟». وفي هذا الدليل نجيب عن هذا السؤال للمدير التقني CTO وأول المهندسين في الفريق، أما الخلفية العامة عن الاستضافة الذاتية Self-Hosting ومتى لا تناسبك فقد شرحناها في لماذا الاستضافة الذاتية؟ ومتى لا تناسبك، والفرق بين التراخيص المفتوحة Licenses شرحناه في ما هي البرمجيات مفتوحة المصدر وتراخيصها؟، فلن نعيد ذلك هنا.

وسوف نناقش في هذا المقال ما يلي:

• ما الذي تكسبه الشركة الناشئة فعلاً من المصادر المفتوحة: تكلفة لا تكبر مع عدد الموظفين، وبيانات عملائك عندك، واستقلال عن قرارات المزود، وإجابات أسرع لأسئلة الأمان من العملاء.
• الثمن الحقيقي، وهو وقت الفريق، وما تقوله تجربة 37signals الموثقة عن متى يناسبك ترك السحابة ومتى لا يناسبك.
• قواعد واضحة لما تستضيفه من اليوم الأول، وما تتركه للخدمات المدارة، وما تعيد النظر فيه عند 20 و50 و100 شخص.
• الأدوات المقترحة بالترتيب على أربع مراحل، مع رابط دليل التثبيت لكل أداة منشورة على الموقع.
• بنية مرجعية Reference Architecture لفريق صغير على سيرفرين، ومثال توضيحي للتكلفة الشهرية بافتراضات معلنة.
• الحد الأدنى من الأمان، ثم قائمة تحقق تراجعها قبل أن تعتمد على أي أداة.

والشكل التالي يلخص المراحل الأربع والأدوات المقترحة في كل مرحلة، وسوف نفصل كل واحدة منها في قسم الأدوات:

ماذا تكسب الشركة الناشئة من المصادر المفتوحة؟

الفائدة في الشركة الناشئة تختلف عن الفائدة في الجامعة أو الجهة الحكومية، فالشركة الناشئة لا تبحث عن السيادة على البيانات Data Sovereignty بوصفها مبدأ، وإنما تبحث عن أربعة أشياء عملية، وكل واحد منها له شروط حتى يتحقق.

تكلفة لا تكبر مع كل موظف جديد

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

لاحظ أن Sentry في الجدول لا يحسب السعر لكل مستخدم وإنما بحسب عدد الأحداث Events، وهذا مثال على أن قاعدة «كل اشتراك يكبر مع الفريق» ليست صحيحة في كل الأدوات، لذلك افتح صفحة الأسعار لكل أداة قبل أن تحسب، وابدأ باستبدال الأدوات التي تحسب لكل مستخدم، والسبب أن هذه هي التي سوف تكبر فاتورتها مع كل توظيف. وتذكر أن هذه الأسعار تتغير، فراجعها في يوم حسابك أنت وليس من هذا الجدول.

بيانات عملائك عندك، وإجابات جاهزة لأسئلة الأمان

عندما تبيع لشركة كبيرة أو لجهة حكومية Business to Business، فسوف يصلك قبل العقد استبيان أمني Security Questionnaire يسألك أين تحفظ بيانات العميل، ومن يصل إليها، وكيف تنسخها احتياطياً، وما هي الخدمات الخارجية التي تمر بها البيانات (المعالجون الفرعيون Sub-processors). وكلما قل عدد الخدمات الخارجية التي تمر بها البيانات، قصرت قائمة المعالجين الفرعيين وأصبحت الإجابة أسهل، والسبب أن كل خدمة خارجية تحتاج منك أن تشرح أين تعمل وماذا ترى من البيانات وما هي شروط عقدها. لذلك فاستضافة الأدوات التي تلمس بيانات العملاء، مثل تتبع الأخطاء الذي يستقبل رسائل الخطأ وفيها أحياناً بيانات المستخدمين، وخدمة العملاء التي تحفظ محادثاتهم، والتحليلات Analytics، تختصر عليك جزءاً من هذا العمل.

ولكن انتبه إلى أن الاستضافة الذاتية لا تجعلك ملتزماً بالمعايير تلقائياً، فإذا كانت بيانات العملاء على سيرفرك بدون نسخ احتياطية مختبرة ولا تحكم في الصلاحيات Permissions فالإجابة على الاستبيان سوف تكون أسوأ من الاعتماد على خدمة مدارة لديها شهادات امتثال Compliance، وبالتالي فالاستضافة الذاتية تفيدك في هذا الجانب فقط إذا طبقت الحد الأدنى من الأمان الذي نذكره في آخر المقال.

استقلال عن قرارات المزود

الشركة الناشئة تبني على أدوات لا تملك قرارها، فإذا غير المزود السعر أو أوقف الخطة التي تعتمد عليها، فعليك أن تنتقل في الوقت الذي يحدده هو وليس في الوقت المناسب لك، والأمثلة الموثقة على ذلك كثيرة.

وحتى المصادر المفتوحة نفسها قد يتغير ترخيصها، ففي 10 أغسطس 2023 نقلت HashiCorp الإصدارات القادمة من Terraform ومنتجاتها الأخرى من ترخيص MPL 2.0 إلى Business Source License 1.1، فقامت مجموعة من الشركات بنسخ المشروع وإطلاق OpenTofu تحت إشراف Linux Foundation وبالترخيص المفتوح نفسه، وهذا ما يعطيك إياه الكود المفتوح، وهو أن يبقى أمامك طريق إذا تغير قرار الشركة. لذلك قبل أن تعتمد على أداة، اقرأ ترخيصها واعرف من يملك قرارها، وتجد ما تحتاجه لفهم الفروق بين التراخيص في دليل التراخيص.

فريق يفهم البنية التي يعمل عليها

المهندس الذي ثبت Gitea وكتب ملف CI/CD بنفسه يفهم ما يحدث عندما يفشل النشر Deployment، ويعرف أين يبحث في السجلات Logs، وهذه المعرفة سوف تحتاجها الشركة في كل الأحوال عندما يكبر المنتج، ولكن لا تجعلها السبب الرئيسي للاستضافة الذاتية، والسبب أن الشركة الناشئة تدفع رواتب المهندسين لبناء المنتج وليس للتعلم على حسابه.

الثمن الحقيقي: وقت الفريق

وقد يتساءل البعض: إذا كانت الأدوات مجانية، فلماذا لا نستضيف كل شيء من اليوم الأول؟ والإجابة على ذلك أن الأداة المجانية لها تكلفة لا تظهر في الفاتورة، وهي التثبيت ثم التحديثات Upgrades ثم النسخ الاحتياطية Backups ثم اختبار الاستعادة Restore ثم الاستيقاظ في الليل عندما يتوقف السيرفر، وكل ذلك يأخذه مهندس من وقت المنتج. وفي فريق من أربعة مهندسين، أسبوع واحد يضيع في إصلاح سيرفر بريد هو ربع إنتاجية الفريق في ذلك الأسبوع.

ولنأخذ أشهر حالة موثقة لترك السحابة، وهي شركة 37signals التي تطور Basecamp وHEY، ففي أكتوبر 2022 كتب مديرها التقني David Heinemeier Hansson لماذا يتركون السحابة، وقال إن السحابة تتفوق في طرفين من الطيف، الأول عندما يكون تطبيقك بسيطاً وقليل الزيارات فتوفر فعلاً من التعقيد عندما تبدأ بخدمات مدارة بالكامل، والثاني عندما يكون الحمل متقلباً جداً بقمم كبيرة، وأن شركته لم تعد في أي منهما. ثم في سبتمبر 2023 ذكر أن إنفاقهم على السحابة بدون S3 نزل من قرابة 180 ألف دولار شهرياً إلى أقل من 80 ألفاً، بعد شراء أجهزة بقرابة نصف مليون دولار، وأن فريق التشغيل بقي بالعدد نفسه، وفي أكتوبر 2024 ذكر أن فاتورة السحابة لسنة 2024 نزلت من 3.2 مليون دولار سنوياً إلى 1.3 مليون، وأن الأجهزة كلفت قرابة 700 ألف دولار واستردوها خلال 2023، وأن التوفير المتوقع يتجاوز عشرة ملايين دولار على خمس سنوات بعد نقل S3 أيضاً.

وهذه أرقام حقيقية ولكنها لا تنطبق على الشركة الناشئة كما هي، والسبب أن 37signals شركة قائمة منذ سنوات طويلة، ولديها فريق تشغيل Operations ثابت، وكانت تستأجر أماكن في مراكز بيانات Data Centers من قبل، وفاتورتها بالملايين، والمقال نفسه ينبه إلى أنك إذا كنت بالكامل في السحابة وليس لديك أماكن في مركز بيانات فسوف تدفع إيجارها أيضاً. لذلك خذ من هذه الحالة القاعدة وليس الرقم: عندما يصبح الحمل ثابتاً ومعروفاً والفاتورة كبيرة، يصبح امتلاك البنية أرخص، أما في البداية فالخدمة المدارة تعطيك وقتاً أنت في أشد الحاجة إليه.

والقاعدة التي نقترحها للشركة الناشئة هي: استضف بنفسك ما يكون تشغيله رخيصاً وشراؤه غالياً، واترك للخدمات المدارة ما يكون تشغيله مكلفاً في الوقت أو المخاطرة. فأداة مثل Vaultwarden تعمل في Container واحد بقاعدة SQLite، وتحديثها أمر واحد، بينما سعرها السحابي يتكرر لكل موظف، فهذه تستضيفها. أما البريد الإلكتروني للموظفين فتشغيله يحتاج إلى سمعة عنوان IP ومراقبة القوائم السوداء Blacklists ومتابعة يومية، فهذا تتركه لمزود، وقد فصلنا أسباب ذلك في دليل استضافة البريد للمؤسسات.

قواعد القرار: ماذا تستضيف وماذا تترك؟

قبل أن تثبت أي أداة، اسأل عنها أربعة أسئلة، وإذا كانت الإجابة على أغلبها «نعم» فاستضفها:

• هل سعرها السحابي يحسب لكل مستخدم، وسوف يكبر مع الفريق؟
• هل تعمل في Container أو اثنين بدون عنقود Cluster، ويمكن تحديثها بتغيير وسم ال Image وإعادة التشغيل؟
• هل يمكن أن تتوقف ساعة دون أن يتوقف المنتج أو يتأثر العملاء؟ وأدوات الفريق الداخلية غالباً كذلك.
• هل تستطيع أن تنسخ بياناتها احتياطياً وتستعيدها بأوامر تعرفها، واختبرت ذلك مرة على الأقل؟

وعلى هذا الأساس يكون التقسيم في البداية كما يلي:

متى تعيد النظر؟ عند 20 و50 و100 شخص

القرار الذي اتخذته عندما كان الفريق خمسة أشخاص يحتاج إلى مراجعة كلما كبر الفريق، والسبب أن ميزان التكلفة يتغير في الاتجاهين، فالاشتراكات السحابية تكبر، وفي المقابل يكبر ما تخسره الشركة إذا توقفت أداة يعتمد عليها عشرات الموظفين. والجدول التالي يبين ما نقترح أن تراجعه عند كل حجم، وهي نقاط مراجعة تقريبية وليست أرقاماً ثابتة:

الأدوات المقترحة بالترتيب

الترتيب هنا مهم بقدر الأدوات نفسها، فكل مرحلة تبني على ما قبلها، فلا معنى للدخول الموحد قبل أن يكون لديك سيرفر آمن وReverse Proxy يعطي كل أداة نطاقاً وشهادة TLS، ولا معنى لمنصة نشر قبل أن يكون الكود في Git. وفي كل مرحلة سوف تجد أدلة التثبيت المنشورة على الموقع، أما الأدوات التي لم ننشر دليلها بعد فنذكرها بالاسم، وهي موجودة ضمن الأدلة المخططة في خارطة طريق الاستضافة الذاتية.

المرحلة الأولى: اليوم الأول

هدف هذه المرحلة أن يكون للفريق مكان آمن للكود والأسرار، وأن يكون كل شيء قابلاً للاستعادة، والترتيب كما يلي:

1. سيرفر واحد آمن: سيرفر افتراضي VPS بنظام Ubuntu، بدخول عبر مفاتيح SSH فقط وجدار حماية Firewall وتحديثات تلقائية، والسبب أن كل ما بعده يعمل فوقه، فإذا كان السيرفر مكشوفاً فكل الأدوات مكشوفة.
2. Docker وDocker Compose: كل أداة في ملف Compose خاص بها مع وسوم Tags ثابتة للإصدارات، فيصبح التحديث والنقل إلى سيرفر آخر تغيير سطر وإعادة تشغيل.
3. Reverse Proxy: Nginx Proxy Manager إذا أردت واجهة رسومية، أو Traefik إذا أردت أن تأتي الإعدادات من ملفات Compose نفسها، وهو الذي يعطي كل أداة نطاقاً فرعياً Subdomain وشهادة TLS.
4. Gitea مع Gitea Actions: مستودعات الكود والمراجعات Code Review وCI/CD في مكان واحد على سيرفرك، والسبب أن الكود أهم ما تملكه الشركة، وأن دقائق CI في الخدمات السحابية لها حدود في كل خطة.
5. Vaultwarden لكلمات المرور: خادم متوافق مع تطبيقات Bitwarden، يكتبه مجتمع مستقل عن شركة Bitwarden، ويعمل في Container واحد، فتشارك فيه كلمات مرور الخدمات بين الفريق بدلاً من ملف أو رسالة في المحادثة، ودليله مخطط، وتجد مستودعه في GitHub.
6. authentik للدخول الموحد عندما يتجاوز الفريق خمسة أشخاص تقريباً: حساب واحد لكل موظف يدخل به إلى Gitea وباقي الأدوات، والفائدة الأكبر تظهر يوم يغادر موظف، فتغلق حسابه في مكان واحد بدلاً من عشرة أماكن.
7. النسخ الاحتياطي من اليوم الأول: نسخ يومية لكل Volume وقاعدة بيانات إلى مكان خارج السيرفر ومزود مختلف إن أمكن، باستخدام أداة مثل restic أو Borg، ودليل استراتيجية 3-2-1 مع هذه الأدوات مخطط.

دليلتأمين خادم VPS من أول دخول على Ubuntu 24.04استلمت خادمك للتو؟ قبل أن تثبت عليه أي تطبيق، اتبع هذه الخطوات لإغلاق أبرز الثغرات: الدخول بمفتاح SSH بدلاً من كلمة المرور، وجدار حماية، وتحديثات أمنية تلقائية.دليلتثبيت Docker Engine وDocker Compose على Ubuntu 24.04Docker هو الأساس الذي تعمل عليه معظم التطبيقات التي تستضيفها بنفسك. يشرح هذا الدليل تثبيته على Ubuntu 24.04 من المستودع الرسمي، وضبطه من البداية حتى لا يمتلئ القرص أو تنكشف منافذك للإنترنت.دليلNginx Proxy Manager: نطاقات وشهادات TLS لكل خدماتكبدلاً من فتح منفذ مستقل لكل تطبيق، يتيح لك Nginx Proxy Manager أن تربط كل خدمة بنطاقها وتمنحها شهادة HTTPS مجانية من واجهة بسيطة، دون أن تكتب إعدادات Nginx بنفسك.دليلتثبيت Traefik على خادمك: Reverse Proxy لحاويات Docker بشهادات TLS تلقائيةمع Traefik، يحصل كل تطبيق على نطاقه وشهادة HTTPS بمجرد إضافة بضعة أسطر إلى ملف Compose الخاص به. نثبته على Ubuntu 24.04، ونحمي لوحة التحكم، ونجهز النسخ الاحتياطي والتحديث.دليلتثبيت Gitea على خادمك: خادم Git خاص لفريقك باستخدام Docker Compose وPostgreSQLإذا أردت أن يبقى كود فريقك على سيرفرك دون أن تخسر تجربة تشبه GitHub، فهذا الدليل يثبت لك Gitea مع PostgreSQL ويشغل SSH على منفذ لا يتعارض مع السيرفر، ثم يجهز معك النسخ الاحتياطي والاستعادة والتحديث.دليلGitea Actions لتشغيل CI/CD على السيرفر وبناء Docker Images ونشرهااجعل خادمك يختبر الكود ويبني Docker Images تلقائياً مع كل push، دون الاعتماد على خدمة CI خارجية. نفعل Gitea Actions، ونشغل Runner معزولاً، ونكتب أول workflow خطوة بخطوة.دليلدخول موحد لجميع تطبيقاتك: تثبيت authentik باستخدام Docker Composeحساب واحد لكل موظف يدخل به إلى جميع تطبيقات الفريق، بدلاً من حساب مستقل في كل خدمة. يشرح هذا الدليل تثبيت authentik وإعداده، وفرض المصادقة الثنائية على المستخدمين.دليلربط Gitea مع authentik عبر OIDC: دخول موحد وإنشاء تلقائي للحسابات وصلاحيات إدارة تتبع المجموعاتاجعل موظفيك يدخلون إلى Gitea بحساباتهم في authentik، فتنشأ حساباتهم تلقائياً في أول دخول، وتمنح صلاحية الإدارة أو تسحب بحسب المجموعة التي ينتمون إليها.

المرحلة الثانية: عندما يبدأ المنتج في استقبال العملاء

هنا يصبح لديك تطبيق في بيئة الإنتاج، وتحتاج إلى أن تنشره بسرعة، وأن تعرف أنه توقف قبل أن يخبرك العميل، وأن تعرف لماذا توقف:

1. منصة نشر Coolify أو Dokploy: على سيرفر مستقل عن سيرفر الأدوات، فيدفع المطور إلى Git وتبني المنصة التطبيق وتنشره وتعطيه نطاقاً وشهادة، وقد قارنا بينهما وبين Portainer في مقارنة Portainer وCoolify وDokploy.
2. مراقبة التوفر بـ Uptime Kuma: أداة خفيفة بترخيص MIT تفحص روابط التطبيق والأدوات كل دقيقة وترسل تنبيهاً إلى البريد أو المحادثة، ودليلها مخطط، وتجدها في مستودعها الرسمي. وعندما يكبر عدد السيرفرات انتقل إلى Grafana مع Prometheus وLoki لقياس الموارد وجمع السجلات، وأدلتها مخططة في خارطة الطريق.
3. تتبع الأخطاء Error Tracking بـ GlitchTip: يستقبل الأخطاء من حزم Sentry SDK نفسها التي يستخدمها تطبيقك، فلا تغير الكود، ويحتاج بحسب وثائق التثبيت إلى 256 MB من الذاكرة في وضع التثبيت الواحد مع PostgreSQL. أما Sentry نفسه فيمكن استضافته، ولكن الحد الأدنى في وثائقه 4 معالجات و16 GB من الذاكرة مع 16 GB من ال Swap، والموصى به 32 GB، وترخيصه Functional Source License وليس ترخيصاً مفتوحاً بالمعنى المعروف، لذلك فلفريق صغير إما GlitchTip على سيرفرك أو خطة Sentry السحابية، ودليل GlitchTip مخطط.
4. تحليلات الموقع بـ Umami: بديل خفيف لـ Google Analytics بترخيص MIT، لا يحتاج إلى ملفات Cookies لتتبع الزوار، فتبقى بيانات زوار منتجك عندك، وتجد وثائقه في موقعه الرسمي، ودليله مخطط.
5. البريد التفاعلي Transactional Email: رسائل التسجيل واستعادة كلمة المرور والفواتير، وفي البداية نقترح Amazon SES لأن سعره 0.10 دولار لكل 1000 رسالة وسمعة عناوينه جاهزة، ثم Postal على سيرفرك إذا أردت أن تملك الإرسال بالكامل، وقد شرحنا الفرق بينهما في دليل البريد التفاعلي.
6. النشرات البريدية بـ listmonk: لرسائل المنتج والتحديثات إلى قائمة المستخدمين، ويرسل عبر SES أو Postal، فلا تدفع لكل مشترك كما في أغلب خدمات النشرات.
7. مفاتيح الميزات Feature Flags بـ Unleash أو Flagsmith: لتفعيل ميزة لعدد محدود من العملاء قبل الجميع، أو إيقافها فوراً دون نشر جديد، وUnleash بترخيص AGPL-3.0 وFlagsmith بترخيص BSD-3-Clause، ولا تضفها قبل أن تحتاجها فعلاً، والسبب أن متغير بيئة Environment Variable يكفي في الأشهر الأولى.

وقبل أن تنشر أول تطبيق للعملاء راجع قائمة تحقق المطور قبل النشر، ففيها الأخطاء التي تظهر عادة بعد النشر خلف Reverse Proxy وداخل Container.

مقارنةPortainer أم Coolify أم Dokploy؟ مقارنة لاختيار أداة إدارة التطبيقات على خادمكهل تحتاج إلى واجهة تدير بها الـ Containers، أم إلى منصة تنشر تطبيقاتك من Git مباشرة؟ نقارن Portainer وCoolify وDokploy لتعرف أيها يناسب فريقك، ومتى تحتاج إلى خادم مستقل.دليلتثبيت Coolify لنشر التطبيقات من Git على خادمكانشر تطبيقاتك من Git على خادمك بضغطة زر، كما تفعل في Heroku أو Vercel. نثبت Coolify بأمان، وننشر أول تطبيق بنطاق وشهادة HTTPS، ونجهز النسخ الاحتياطي لقواعد البيانات.دليلتثبيت Dokploy لنشر تطبيقاتك من Git على خادمكمنصة مفتوحة المصدر تنشر تطبيقاتك من Git على خادمك، على طريقة Vercel. نثبت Dokploy بأمان، وننشر تطبيقاً وملف Compose بنطاق وشهادة HTTPS لكل منهما، ونجهز النسخ الاحتياطي.دليلقبل أن تنشر تطبيقك على خادمك: قائمة تحقق للمطورإذا كان تطبيقك سيعمل في Docker خلف Reverse Proxy، فهذه قائمة بالأخطاء التي لا تظهر عادة إلا بعد النشر، ومع كل بند ما يحدث إذا أهملته وكيف تعالجه قبل أن يصل إلى المستخدمين.دليلتطبيقك خلف Reverse Proxy: عنوان الزائر الحقيقي وHTTPS والروابط الصحيحةإذا كان تطبيقك يرى عنوان الـ Proxy بدلاً من عنوان الزائر، أو يولد روابط http مع أن موقعك يعمل بـ HTTPS، فستعرف هنا السبب والإعداد الصحيح لإطار عملك دون أن تفتح باباً لانتحال العناوين.دليلالبريد التفاعلي Transactional Email: كيف تصل رسائل تطبيقك في وقتهارابط استعادة كلمة المرور الذي لا يصل يعني مستخدماً لا يستطيع الدخول، لذلك نشرح ما هو البريد التفاعلي ولماذا تفصله عن النشرات بنطاق وسمعة مستقلين، وكيف ترسله من تطبيقك بطابور وإعادة محاولة، ومتى تختار Amazon SES أو منصة تستضيفها بنفسك مثل Postal.دليلإرسال بريد خادمك عبر Amazon SES مع mailcow وPostfix وStalwartإذا كان مزودك يحجب المنفذ 25 أو كانت رسائل سيرفرك الجديد تصل إلى Spam، فسوف نرسل البريد الصادر عبر Amazon SES ويبقى الاستقبال والصناديق على سيرفرك، مع DKIM وMAIL FROM وDMARC والارتدادات، والإعداد الدقيق لكل خادم بريد وأي تطبيق.دليلتثبيت Postal لإرسال البريد التفاعلي من تطبيقاتكمنصة إرسال مفتوحة المصدر على سيرفرك تشبه Amazon SES، ترسل منها تطبيقاتك رسائل التسجيل واستعادة كلمة المرور عبر SMTP أو HTTP API. يشرح هذا الدليل تثبيت Postal بالأداة الرسمية، وسجلات DNS التي يطلبها، وWebhooks والنسخ الاحتياطي والتحديث.دليلتثبيت listmonk لإدارة النشرات البريدية على خادمكإذا كانت نشرتك البريدية تخرج اليوم من Gmail بخانة BCC أو من خدمة يرتفع سعرها مع كل مشترك، فسوف نثبت في هذا الدليل listmonk مع PostgreSQL على سيرفرك، ونربطه بمزود SMTP تختاره أنت، ثم نرسل أول حملة ونعالج الرسائل المرتدة، وتبقى قائمة المشتركين لديك.

المرحلة الثالثة: عندما يكبر الفريق

بعد العشرة الأوائل تقريباً يصبح التواصل والتوثيق هو المشكلة، ويصبح للفريق أشخاص من خارج الهندسة يحتاجون إلى أدوات، وفي هذه المرحلة تظهر الأدوات التي يكبر سعرها السحابي مع كل موظف:

1. المحادثات بـ Mattermost: قنوات ورسائل مباشرة وتكامل مع Gitea وتنبيهات المراقبة، وتبقى المحادثات وسجلها عندك.
2. قاعدة المعرفة Wiki بـ Outline: توثيق القرارات والإجراءات وطريقة الاستعادة لكل أداة، ويدخل إليه الفريق عبر authentik، ولاحظ أن Outline مرخص بـ Business Source License 1.1 الذي يسمح لك باستخدامه داخل شركتك ويمنعك من أن تقدمه خدمة تجارية لجهات أخرى، وقد ذكرنا التفاصيل في دليله.
3. إدارة المشاريع بـ Taiga: لوحات Scrum وKanban للفريق، ويوجد أيضاً Plane بترخيص AGPL-3.0 لمن يريد واجهة قريبة من Jira وLinear، ودليله مخطط.
4. الملفات بـ Seafile: مزامنة الملفات ومشاركتها بين الفريق بدلاً من حسابات تخزين سحابي شخصية متفرقة.
5. خدمة العملاء بـ Chatwoot: صندوق واحد للمحادثات من الموقع والبريد وقنوات التواصل، وتبقى محادثات عملائك عندك، وهذا مهم عندما يسألك عميل كبير أين تحفظ بياناته.
6. إدارة علاقات العملاء CRM بـ Twenty: بديل مفتوح لأدوات CRM السحابية، وأغلبه بترخيص AGPL-3.0 مع ملفات بترخيص تجاري كما يذكر ملف الترخيص، ويثبت بـ Docker Compose بحسب وثائقه، ودليله مخطط.

دليلتثبيت Mattermost Team Edition مع PostgreSQL وترقيته بأمانمساحة محادثة لفريقك تبقى رسائلها وملفاتها كاملة على سيرفرك، فلا تحذفها خطة مجانية ولا يخفيها حد للرسائل. نثبت Mattermost Team Edition مع PostgreSQL، ونجهز الفريق الأول والبريد، ثم نشرح النسخ الاحتياطي والتحديث دون أن تفقد بياناتك.دليلتثبيت Outline لقاعدة معرفة فريقك مع PostgreSQL وRedis والدخول عبر authentikمكان واحد يكتب فيه فريقك إجراءاته وقراراته ويجد فيه ما يبحث عنه بسرعة، يعمل على سيرفرك أنت ويدخل إليه الموظفون بحساباتهم في authentik، مع نسخ احتياطي وتحديث لا تخسر فيهما شيئاً.دليلتثبيت Taiga لإدارة المشاريع بأسلوب Scrum وKanbanإذا كانت مهام فريقك موزعة بين جداول Excel وأدوات سحابية مثل Jira وTrello، فهذا الدليل يشرح كيف تشغل Taiga على سيرفرك لتدير العمل بأسلوب Scrum وKanban، وتدعو الأعضاء، وتجهز البريد والنسخ الاحتياطي والتحديث.دليلتثبيت Seafile 13 لمزامنة الملفات ومشاركتها على خادمكإذا كانت ملفات فريقك على Dropbox أو OneDrive فالمساحة والأسعار والشروط بيد غيرك. في هذا الدليل نثبت Seafile 13 على سيرفرك بالملفات الرسمية، ونجهز المكتبات والمشاركة وعميل المزامنة، ثم نأخذ نسخة احتياطية ونستعيدها على سيرفر جديد.دليلتثبيت Chatwoot لخدمة العملاء على خادمكاجمع رسائل عملائك من دردشة الموقع والبريد وWhatsApp في صندوق وارد واحد على خادمك. نثبت Chatwoot، ونجهز نافذة الدردشة والبريد، ثم النسخ الاحتياطي والترقية.

المرحلة الرابعة: التوسع

عندما يصبح لديك أكثر من بضعة سيرفرات، يصبح بناء كل سيرفر يدوياً هو مصدر الأخطاء، والسبب أن أحداً لا يتذكر ماذا تغير على السيرفر الثالث قبل ستة أشهر:

1. البنية بالكود بـ OpenTofu: تنشئ السيرفرات وسجلات DNS والشبكات من ملفات في Git، فتراجعها في طلب دمج Pull Request مثل أي كود، وهو بديل مفتوح لـ Terraform ويقبل ملفاته نفسها بحسب موقعه الرسمي.
2. إعداد السيرفرات بـ Ansible: تكتب في Playbook ما يجب أن يكون على كل سيرفر، من التحديثات إلى إعدادات SSH وجدار الحماية، فيصبح السيرفر الجديد نسخة مطابقة للقديم، وتجد وثائقه في موقعه الرسمي.
3. Kubernetes فقط عندما تحتاجه: إذا كان لديك عشرات الخدمات وتحتاج إلى توزيع الحمل Load Balancing بين سيرفرات كثيرة والتعافي التلقائي، أما لعدد قليل من التطبيقات فإن Docker Compose أو Docker Swarm أو عقد Dokploy تكفيك بتكلفة تشغيل أقل بكثير، وأدلة Kubernetes مخططة في خارطة الطريق ومنها «هل تحتاج Kubernetes فعلاً؟».

بنية مرجعية لفريق صغير على سيرفرين

لفريق من خمسة إلى عشرين شخصاً نقترح سيرفرين، الأول لأدوات الفريق والثاني للمنتج، والسبب أن خطأ في نشر تطبيق أو بناء يستهلك الذاكرة يجب ألا يوقف Git ومدير كلمات المرور، وأن منصات النشر مثل Coolify وDokploy تحتاج إلى المنفذين 80 و443 لنفسها كما شرحنا في مقارنة منصات النشر. والشكل التالي يبين التقسيم:

Internet
   |
   |-- DNS + CDN (managed)          Cloudflare or your DNS provider
   |-- Mailboxes (managed)          Google Workspace / Microsoft 365 / hosted mail
   |-- Transactional email          Amazon SES (later: Postal)
   |
   +-- Server 1: team tools  (4 vCPU, 8 GB RAM)
   |     Reverse Proxy (Nginx Proxy Manager or Traefik): 80/443 only
   |     authentik      sso.example.com
   |     Gitea          git.example.com
   |     Vaultwarden    vault.example.com
   |     Mattermost     chat.example.com
   |     Outline        wiki.example.com
   |     Uptime Kuma    status.example.com
   |     Gitea Actions runner (or on Server 2)
   |
   +-- Server 2: product  (8 vCPU, 16 GB RAM)
   |     Coolify or Dokploy (its own Traefik on 80/443)
   |     app.example.com, api.example.com, staging.example.com
   |     PostgreSQL (or a managed database)
   |     GlitchTip, Umami
   |
   +-- Off-site backups: object storage at another provider
         restic/Borg, daily, encrypted, restore tested monthly

Admin panels (Proxmox, databases, Coolify/Dokploy UI): VPN only (WireGuard)

في البنية أعلاه لاحظ التالي:

• الخدمات التي يحتاج تشغيلها إلى سمعة أو التزامات، وهي ال DNS والبريد والإرسال بكميات كبيرة، تبقى عند مزود، وهذا قرار مقصود وليس نقصاً في البنية.
• كل أداة على السيرفر الأول تدخل عبر ال Reverse Proxy فقط، ولا ينشر أي Container منفذاً آخر على العنوان العام، وتجد السبب والطريقة في شبكات Docker وأفضل الممارسات.
• لوحات الإدارة لا تفتح للإنترنت، وإنما عبر شبكة خاصة VPN مثل WireGuard، والسبب أن من يصل إلى لوحة Coolify أو Dokploy يملك السيرفر عملياً.
• النسخ الاحتياطية عند مزود آخر، فإذا أغلق حسابك لدى مزود السيرفر لأي سبب بقيت بياناتك.
• أحجام السيرفرات في الشكل افتراض مبدئي، فقس الاستهلاك الفعلي بعد أسبوعين وغير الحجم بحسبه، وتجد طريقة اختيار السيرفر في كيف تختار خادماً افتراضياً VPS.

دليلكيف تختار خادماً افتراضياً VPSكم تحتاج من المعالج والذاكرة والقرص؟ وما الذي يميز مزوداً عن آخر غير السعر؟ يساعدك هذا الدليل على اختيار خادم VPS يناسب احتياجك، مع مقارنة بأبرز المزودين القريبين من المنطقة.دليلشبكات Docker وأفضل الممارسات مع Docker Composeكل منفذ تنشره في ملف Compose بدون عنوان يصبح مفتوحاً على الإنترنت حتى لو كان ufw مفعلاً. يشرح هذا الدليل أنواع شبكات Docker، والنمط الذي نستخدمه في كل أدلة الموقع: شبكة proxy مشتركة لل Reverse Proxy والتطبيقات، وشبكة داخلية لقاعدة بيانات كل مشروع.دليلشبكة خاصة مع WireGuard وواجهة wg-easyلا تحتاج لوحات الإدارة إلى أن تكون مكشوفة للإنترنت. ننشئ شبكة VPN خاصة باستخدام WireGuard وواجهة wg-easy، ونضيف إليها الأجهزة برمز QR، فلا يصل إلى أدواتك إلا أجهزة فريقك.دليلكيف تحمي أي تطبيق ويب بصفحة دخول authentik عبر Forward Authلديك أداة داخلية لا تحتوي على صفحة دخول؟ يمكنك أن تضع أمامها صفحة دخول authentik مع المصادقة الثنائية، دون أي تعديل على التطبيق نفسه.دليلنقل Containers إلى خادم جديد دون فقدان البياناتعندما تنتقل إلى سيرفر جديد أو مزود آخر، تريد أن تصل ال Containers مع بياناتها كما هي. نشرح طريقتين للنقل، نسخ كل شيء دفعة واحدة أو نقل كل تطبيق على حدة، مع خطة للتراجع إذا تعثر النقل.

كم تكلف هذه البنية شهرياً؟ مثال توضيحي

الأرقام التالية حساب توضيحي وليست عرض سعر، وهدفه أن ترى طريقة الحساب وليس أن تأخذ النتيجة كما هي. وافتراضاتنا كما يلي: السيرفران من فئة Basic في صفحة أسعار DigitalOcean كما ظهرت في أكتوبر 2026، واخترناها لأن أسعارها منشورة بوضوح وليس توصية بالمزود، والنسخ الاحتياطي الأسبوعي من المزود بنسبة 20% من سعر السيرفر بحسب الصفحة نفسها، ومساحة تخزين للنسخ خارج السيرفر بخطة Spaces الأساسية بـ 5 دولارات شهرياً لـ 250 GiB، ولاحظ أن الأفضل أن تكون النسخ عند مزود آخر، فضع سعر المزود الذي تختاره مكانها.

ولنقارن ذلك بأربع أدوات سحابية فقط من الجدول السابق، وهي GitHub Team وSlack Pro بالدفع السنوي وBitwarden Teams وSentry Team، واخترنا الأرخص في كل فئة حتى تكون المقارنة عادلة للخدمات السحابية:

لاحظ أن الفرق عند عشرة أشخاص يكاد يكون صفراً، وأن السيرفرين يحملان أكثر من هذه الأدوات الأربع، فعليهما أيضاً قاعدة المعرفة والمحادثات وخدمة العملاء والتحليلات، وكل واحدة منها لها اشتراك سحابي آخر لم ندخله في الحساب. وفي المقابل لم ندخل في الحساب وقت المهندس، فإذا افترضت أن الصيانة والتحديثات واختبار الاستعادة تأخذ عدداً من الساعات كل شهر، فاضرب هذا العدد في تكلفة ساعة المهندس عندك وأضفه إلى عمود الاستضافة الذاتية، فإذا كانت النتيجة قريبة من الاشتراكات فالخدمة السحابية أنسب لك الآن، وأعد الحساب عندما يكبر الفريق. ولاحظ أيضاً أن Sentry بقي ثابتاً في الجدول لأننا افترضنا أن الأخطاء لم تتجاوز ما تشمله الخطة، وهذا يتغير مع عدد مستخدمي المنتج وليس مع عدد الموظفين.

الحد الأدنى من الأمان قبل أن تعتمد على أي أداة

السيرفر الذي يحمل الكود وكلمات المرور هو أثمن ما تملكه الشركة بعد بيانات العملاء، لذلك لا تبدأ في استخدام أي أداة قبل أن تطبق ما يلي:

• الدخول إلى السيرفر: مفاتيح SSH فقط بدون كلمات مرور، ومستخدم غير root، وجدار حماية لا يفتح إلا 22 و80 و443، وتحديثات أمنية تلقائية، والخطوات كاملة في تأمين خادم VPS من أول دخول.
• المنافذ المنشورة: Docker يتجاوز قواعد ufw عند نشر المنافذ، فلا تنشر منفذ قاعدة بيانات أو لوحة إدارة على العنوان العام، واربط الأدوات بال Reverse Proxy عبر شبكة Docker داخلية.
• المصادقة الثنائية 2FA على كل حساب مدير، وعلى الدخول الموحد في authentik لكل الفريق، والسبب أن كلمة مرور واحدة مسروقة تفتح كل الأدوات عندما يكون الدخول موحداً.
• مغادرة الموظفين Offboarding: إجراء مكتوب يغلق حساب الموظف في authentik ويغير كلمات المرور المشتركة التي كان يعرفها في Vaultwarden في اليوم نفسه.
• الأسرار Secrets: لا تحفظها في الكود ولا في ملفات Compose داخل Git، واستخدم أسرار Gitea Actions وملفات .env خارج المستودع، وامنح منصة النشر صلاحية المستودعات التي تنشرها فقط.
• النسخ الاحتياطي: نسخ يومية مشفرة خارج السيرفر، واختبار استعادة مرة في الشهر على سيرفر آخر، ومراقبة تنبهك إذا لم تنجح النسخة الليلية.
• التحديثات: وسوم ثابتة للإصدارات، وموعد ثابت في الأسبوع لقراءة ملاحظات الإصدار Release Notes وتحديث الأدوات، ونسخة احتياطية قبل كل تحديث.

دليلتأمين خادم VPS من أول دخول على Ubuntu 24.04استلمت خادمك للتو؟ قبل أن تثبت عليه أي تطبيق، اتبع هذه الخطوات لإغلاق أبرز الثغرات: الدخول بمفتاح SSH بدلاً من كلمة المرور، وجدار حماية، وتحديثات أمنية تلقائية.دليلحماية تطبيقات الويب على مستوى HTTP: طبقات أمان أمام كل تطبيق في الـ Reverse Proxyكلمة المرور وحدها لا تحمي تطبيقاً مكشوفاً على الإنترنت، لذلك نبني في هذا الدليل أمام كل تطبيق طبقات حماية في الـ Reverse Proxy نفسه، بإعدادات مختبرة على Nginx Proxy Manager وTraefik وCaddy.دليلكيف تحمي أي تطبيق ويب بصفحة دخول authentik عبر Forward Authلديك أداة داخلية لا تحتوي على صفحة دخول؟ يمكنك أن تضع أمامها صفحة دخول authentik مع المصادقة الثنائية، دون أي تعديل على التطبيق نفسه.

قائمة تحقق قبل أن تعتمد على أداة

راجع هذه القائمة قبل أن تنقل الفريق إلى أي أداة جديدة، وإذا كانت الإجابة على أي بند «لا» فأجل الانتقال حتى تصبح «نعم»:

• هل قرأنا ترخيص الأداة، ونعرف هل هو ترخيص مفتوح أو ترخيص يقيد الاستخدام التجاري؟
• هل ثبتنا الأداة بوسم إصدار ثابت وليس latest؟
• هل تعمل خلف ال Reverse Proxy بشهادة TLS، ولا ينشر Container منفذاً على العنوان العام؟
• هل يدخل إليها الفريق عبر authentik، وهل المصادقة الثنائية مفعلة لحسابات المدير؟
• هل تنسخ بياناتها يومياً خارج السيرفر، وهل استعدناها مرة على سيرفر آخر ونجحت الاستعادة؟
• هل يراقبها Uptime Kuma ويصل تنبيهها إلى أكثر من شخص؟
• هل كتبنا في Outline طريقة تحديثها واستعادتها، ويعرفها شخصان على الأقل؟
• هل نعرف كيف نصدر بياناتها Export إذا قررنا الانتقال إلى أداة أخرى؟
• هل حسبنا وقت تشغيلها الشهري، وقارناه بسعر البديل السحابي لعدد الفريق الحالي وبعد سنة؟

الخلاصة

• المصادر المفتوحة تعطي الشركة الناشئة تكلفة لا تكبر مع كل موظف، وبيانات عملاء عندها، واستقلالاً عن قرارات المزود، ولكن ثمنها وقت المهندسين، وهو أندر ما تملكه الشركة في البداية.
• القاعدة: استضف ما يكون تشغيله رخيصاً وشراؤه غالياً، مثل Git وCI/CD وكلمات المرور والدخول الموحد، واترك البريد وال DNS والدفع للخدمات المدارة في البداية.
• الترتيب: سيرفر آمن وDocker وReverse Proxy وGitea ونسخ احتياطي أولاً، ثم منصة النشر والمراقبة وتتبع الأخطاء والبريد التفاعلي، ثم أدوات الفريق، ثم البنية بالكود وKubernetes عندما تحتاجه فعلاً.
• أرقام 37signals حقيقية، ولكنها لشركة بفاتورة بالملايين وحمل ثابت وفريق تشغيل قائم، فخذ منها القاعدة وليس الرقم، واحسب أنت بأسعار يومك وعدد فريقك ووقت مهندسيك.
• لا تعتمد على أداة قبل أن تختبر استعادتها، فالنسخة التي لم تستعدها مرة لا تعرف إن كانت تعمل.

وإذا كنت تعمل في جامعة أو جهة حكومية، فلكل منهما دليل خاص بأدواته وترتيبه في قسم «ابدأ من نوع مؤسستك» في خارطة طريق الاستضافة الذاتية.

سجل التحديثات (Changelog)

• أكتوبر 2026: كتابة الدليل، والأسعار المذكورة من صفحات الأسعار الرسمية كما ظهرت في أكتوبر 2026.