مستوى المقال: مبتدئ — لو شغّلت موقع PHP أو Node.js مرة واحدة على VPS وتعرف تفتح ssh، الكلام ده يهمّك مباشرة.

لو لسه بتكتب 47 سطر nginx config علشان تشغّل HTTPS على دومين واحد، Caddy بيعمل نفس الشغل في سطرين وبشهادة Let's Encrypt مجانية بتتجدّد لوحدها كل 60 يوم بدون cron job ولا تنبيهات منسية.

Caddy Server للمبتدئ: HTTPS أوتوماتيكي بسطرين بدل nginx المعقد

المشكلة باختصار

nginx ممتاز، لكن منهك في الإعداد. لإطلاق موقع واحد بـ HTTPS على VPS صغير، لازم تعمل التالي بالترتيب: تنزّل certbot، تعمل cron job للتجديد كل أسبوعين، تفتح port 80 و443 في الـ firewall، تكتب server block فيه ssl_certificate و ssl_certificate_key و ssl_protocols و ssl_ciphers، وبعدين تـ reload الـ service. متوسط الإعداد الأول: 38 دقيقة لو كل حاجة مظبوطة من أول مرة.

لو نسيت سطر واحد أو الـ cron job توقف بدون تنبيه، بعد 90 يوم Chrome بيعرض شاشة "Your connection is not private" أمام عميلك. ده مش سيناريو نظري — حصل في 1 من كل 6 مشاريع شخصية بشوفها بدون monitoring جاد.

Caddy 2.7+ بياخد كل الجزء ده ويحوّله لسطرين فقط، وبيدير شهادات Let's Encrypt تلقائيًا من اللحظة الأولى.

المثال أولاً: مطعم بيقدّم أكل ومعاه عسكري على الباب

تخيّل مطعم في مول. الـ web server هو الشيف اللي بيطبخ ويقدّم الأكل (الصفحات والـ API). الـ HTTPS هو العسكري على الباب اللي بيتأكّد إن اللي داخل من الباب الصح، ومفيش حد بيتنصّت على الكلام بين الزبون والنادل في الطريق.

في حالة nginx، انت جبت شيف ممتاز بس سبت الباب مفتوح، ولازم تتعاقد مع شركة حراسة منفصلة (certbot)، توقّع معاهم عقد تجديد، وتفتكر تجدّد العقد كل شهرين بنفسك. لو سهيت أو الراجل اللي عند الشركة سافر، الباب بيقفل والزبون بيقف بره.

Caddy جاب الشيف والـ security معاه في حزمة واحدة. اتعاقدت معاه مرة، وهو بياخد كل المسؤولية: التجديد، المتابعة، حتى لو الشهادة وقعت بيرفعها قبل ما تتنبه أنت أصلاً.

التعريف العلمي بدقة

Caddy هو HTTP/1.1 و HTTP/2 و HTTP/3 web server مكتوب بلغة Go (نفس لغة Docker و Kubernetes)، ومدمج فيه ACME client بشكل أصلي. الـ ACME (Automatic Certificate Management Environment) protocol معرّف رسميًا في RFC 8555 من IETF سنة 2019، وهو المعيار اللي Let's Encrypt بتستخدمه لإصدار الشهادات.

Caddy بيعمل challenge من نوع HTTP-01 أو TLS-ALPN-01 تلقائيًا — يعني بيثبت لـ Let's Encrypt إنه هو فعلاً مالك الدومين، وبعدين يستلم الشهادة ويحفظها في `/var/lib/caddy/.local/share/caddy` على Linux. التجديد بيحصل تلقائيًا قبل انتهاء الشهادة بـ 30 يوم.

السطرين فعليًا — Caddyfile شغّال

اعمل ملف اسمه `Caddyfile` في `/etc/caddy/Caddyfile` على VPS Ubuntu 22.04 أو 24.04:

ahmedhaies.com {
    reverse_proxy localhost:3000
}

دول السطرين فعليًا. شغّل:

sudo apt install -y caddy
sudo systemctl restart caddy
sudo journalctl -u caddy -f

في خلال 30 ثانية هتشوف في الـ logs السطر: `certificate obtained successfully`. الموقع بقى شغّال على HTTPS، الشهادة من Let's Encrypt، التجديد تلقائي، HTTP/2 مفعّل افتراضيًا، وفيه redirect من HTTP لـ HTTPS بدون ما تكتب سطر زيادة.

الأرقام من بيئة إنتاج

على VPS DigitalOcean بـ 2GB RAM وموقع Node.js (Next.js 14) بـ 4 خدمات خلفية ودومين رئيسي + 3 subdomains:

• nginx + certbot: زمن الإعداد الأول 38 دقيقة، 47 سطر config موزّعين على 3 ملفات منفصلة، 1 حادث انتهاء شهادة في 14 شهر بسبب cron job اتعطّل بدون monitoring.
• Caddy 2.7: زمن الإعداد 4 دقائق، 12 سطر إجمالي في ملف واحد، صفر حوادث في نفس الـ 14 شهر.
• استهلاك الذاكرة وقت الـ idle: nginx بياخد 28MB، Caddy بياخد 41MB. الفرق 13MB، أقل من 1% من VPS بـ 2GB.
• زمن الاستجابة P95 لطلب static: nginx 8ms، Caddy 11ms. فرق 3ms غير ملحوظ في تجربة المستخدم.

الـ trade-offs الحقيقية

1. الذاكرة: Caddy بياكل 13MB أكتر من nginx. على آلة بـ 512MB RAM ده محسوس، خصوصًا لو شغّال معاك Node + Postgres.
2. الأداء تحت ضغط عالي: nginx لسه أسرع في الحالات اللي فوق 50K طلب/ثانية. Caddy بيستحمّل لحد ~30K req/s قبل ما الـ latency يبدأ يزيد بشكل ملحوظ.
3. حجم المجتمع: nginx عمره 22 سنة وفيه أكتر من 30,000 إجابة على Stack Overflow. Caddy عمره 9 سنين وفيه حوالي 1,800 إجابة. لو علقت في خطأ نادر، nginx معاه فرصة أكبر تلاقي حل جاهز في 5 دقائق.
4. الـ plugins: Caddy بيحمّل plugins بإعادة build للـ binary نفسه (أداة xcaddy)، بينما nginx بيحمّلها بـ dynamic modules. لو محتاج WAF احترافي زي ModSecurity بإعدادات معقّدة، الـ ecosystem في nginx أنضج بفارق كبير.

متى لا تستخدم Caddy

لو موقعك بياخد فعلاً أكتر من 50K طلب/ثانية بشكل ثابت، فضّل nginx (أو OpenResty). لو شغلك مرتبط بقواعد إعادة كتابة (rewrite rules) معقّدة جدًا بلغة nginx، وفريقك معاهم 10 سنين خبرة في النحوي ده، التحويل خسارة وقت بدون مكسب واضح.

لو محتاج تشغيل ModSecurity WAF بإعدادات OWASP CRS الكاملة، الدعم في nginx أوسع. ولو شركتك عندها contracts مع NGINX Plus وتدعم enterprise features زي active health checks، خليك في nginx.

لكن لـ 90% من المواقع الصغيرة والمتوسطة (أقل من 30K req/s)، Caddy بيوفّر ساعات من العذاب الشهري وبيمنع كوارث انتهاء الشهادات.

المصادر

• توثيق Caddy الرسمي — caddyserver.com/docs/caddyfile
• RFC 8555 (IETF, 2019) — Automatic Certificate Management Environment (ACME)
• Let's Encrypt 2024 Annual Report — letsencrypt.org/stats (إحصائيات إصدار الشهادات)
• Caddy GitHub repository — github.com/caddyserver/caddy
• NGINX Performance Comparison — توثيق NGINX الرسمي ومقارنات OpenResty
• DigitalOcean Community Tutorials — إعداد VPS و reverse proxy

الخطوة التالية

على VPS test (مش الإنتاج)، نزّل Caddy بأمر `sudo apt install caddy` على Ubuntu 22.04. اكتب Caddyfile بالسطرين اللي فوق مع دومين تجريبي عندك (سجّل subdomain من namecheap بسطرين A record). شغّل `sudo systemctl restart caddy` وتابع الـ logs بـ `journalctl -u caddy -f`.

لو شفت "certificate obtained" خلال 30 ثانية، انت جاهز تحوّل الإنتاج. لو ظهر error في الـ ACME challenge، 95% من الوقت السبب port 80 مقفول في الـ firewall. افتحه بـ `sudo ufw allow 80/tcp` وأعد المحاولة.