لماذا تستضيف Supabase ذاتيًا على VPS
Supabase ليس صندوقًا أسود: إنه مجموعة من الخدمات مفتوحة المصدر (PostgreSQL، وGoTrue للمصادقة، وPostgREST للواجهة البرمجية، وRealtime، وStorage، وKong كبوابة) مُنسَّقة معًا. تُفوتر النسخة السحابية لكل مشروع ولكل مستخدم نشط شهريًا، وتوقف المشاريع المجانية الخاملة. باستضافة Supabase ذاتيًا على خادم VPS، تحصل على backend-as-a-service متكامل دون هذه القيود، مع وصول مباشر إلى PostgreSQL للهجرات والإضافات (pgvector، PostGIS) والضبط. مثالي لوكالة تستضيف تطبيقات عدة لعملاء، أو SaaS ناشئ يريد التحكم في التكاليف، أو أي مشروع يستلزم سيادة البيانات. تدير التحديثات والنسخ الاحتياطية بنفسك، مقابل حرية كاملة.
المزايا الملموسة لـ Supabase المستضاف ذاتيًا
- backend متكامل: Postgres والمصادقة والتخزين وRealtime وواجهة REST/GraphQL في مكدس واحد.
- وصول مباشر إلى PostgreSQL الأساسي: هجرات SQL وإضافات وسياسات RLS بلا حدود.
- بلا إيقاف مؤقت أو فوترة لكل مستخدم نشط شهريًا.
- Studio مضمَّن: واجهة ويب للإدارة لإدارة الجداول والمصادقة والـبuckets.
- إضافات الذكاء الاصطناعي عبر
pgvectorللـRAG والبحث الدلالي، مفعَّلة بحرية. - مشاريع متعددة على نفس الـ VPS: عملي لوكالة أو استوديو تطوير.
متطلبات الأجهزة والبرامج
يشغّل Supabase المستضاف ذاتيًا نحو عشر حاويات (Postgres، وKong، وGoTrue، وPostgREST، وRealtime، وStorage، وStudio، وMeta، وImgproxy...)، مما يجعله أكثر استهلاكًا من قاعدة بيانات بسيطة. احسب حدًا أدنى من 2 vCPU و4 غيغابايت RAM لبيئة تجريبية، ويُفضَّل 4 vCPU مع 8 غيغابايت RAM و80 غيغابايت SSD للإنتاج. على صعيد البرامج: Ubuntu 22.04/24.04 LTS، وDocker وDocker Compose v2، واسم نطاق يشير إلى الخادم (مثلاً api.myapp.com) لعرض البوابة بصيغة HTTPS، وبروكسي عكسي مثل Caddy أو Traefik أو Nginx لإدارة SSL. خطِّط أيضًا لتوليد أسرار قوية (JWT_SECRET، مفاتيح anon وservice_role).
نشر Supabase المستضاف ذاتيًا بـ Docker
استنساخ المستودع الرسمي وإعداد البيئة
احصل على مجلد
dockerمن مستودع Supabase، وانسخ.env.exampleإلى.env، ثم أنشئ أسرارًا فريدة:POSTGRES_PASSWORD، وJWT_SECRET، ومفاتيحANON_KEY/SERVICE_ROLE_KEYالمشتقة من JWT. لا تنشر أبدًا بالقيم الافتراضية.تهيئة عناوين URL وكلمة مرور Studio
في
.env، عيِّنSITE_URLوAPI_EXTERNAL_URLوSUPABASE_PUBLIC_URLبنطاقك، وحمِّ Supabase Studio بـDASHBOARD_USERNAMEوDASHBOARD_PASSWORD: يمنح Studio وصولًا إداريًا كاملًا لمشروعك.تشغيل المكدس
ابدأ بـ
docker compose up -d، ثم تابع بدء تشغيل الخدمات عبرdocker compose ps. تستغرق التهيئة الأولى لـPostgres وتطبيق هجرات داخلية دقيقة إلى دقيقتين؛ تحقق من غياب الأخطاء فيdocker compose logs.وضع بروكسي عكسي مع SSL
ضع Caddy أو Traefik أمام Kong (المنفذ 8000 للبوابة) لعرض واجهتك البرمجية بصيغة HTTPS. يحصل Caddy على شهادات Let's Encrypt ويجدِّدها تلقائيًا: كتلة بسيطة
myapp.com { reverse_proxy localhost:8000 }تكفي. لا تكشف Postgres (5432) للعموم أبدًا.تفعيل سياسات RLS
اتصل بـStudio، وأنشئ جداولك، ثم فعِّل Row Level Security على كل منها وعرِّف سياساتك. بدون RLS، يكشف مفتاحك
anonجميع بياناتك: هذا الإعداد الواجب قبل عرض أي شيء.نسخ Postgres والتخزين احتياطيًا
جدوِل
pg_dumpيوميًا لقاعدة البيانات، وأرشف حجم التخزين (مجلدات الملفات) إلى تخزين خارجي. اختبر الاستعادة الكاملة على VPS تجريبي قبل الاعتماد عليها في الإنتاج.
Supabase أم Appwrite: أيّ BaaS مستضاف ذاتيًا تختار؟
مرّر الجدول أفقيًا
| المعيار | Supabase | Appwrite |
|---|---|---|
| قاعدة البيانات | PostgreSQL أصيل، SQL كامل | MariaDB داخليًا، واجهة وثيقة/مجموعة |
| نموذج البيانات | علائقي، RLS Postgres | وثائق ومجموعات، صلاحيات بقاعدة |
| واجهة برمجية تلقائية | REST (PostgREST) + GraphQL | REST وGraphQL ومجموعات SDK متعددة |
| المصادقة | GoTrue وOAuth وروابط سحرية | مصادقة مدمجة وOAuth وفرق وJWT |
| بصمة الموارد | أثقل (~10 حاويات) | معتدلة، مكدس أكثر إحكامًا |
| البحث الشعاعي/الذكاء الاصطناعي | أصيل عبر pgvector | غير أصيل، يجب الاستعانة بخارجي |
| الأنسب لـ | تطبيقات علائقية، RAG، SQL متقدم | تطبيقات جوال/ويب موجَّهة للوثائق |
| منحنى التعلم | مريح إن أتقنت SQL | سريع لمطوري الواجهة الأمامية/الجوال |
حدِّث Supabase بحذر: إذ إن الصور مُرقَّمة في docker-compose.yml، نفِّذ دائمًا pg_dump كاملًا ولقطة للخادم قبل docker compose pull && docker compose up -d. بعض التحديثات تمس مخطط الخدمات الداخلية. للإنتاج، عزل Postgres على حجم مخصص عالي IOPS، وفعِّل pgvector منذ البداية إن خططت للبحث الدلالي: إضافته لاحقًا يستلزم هجرة مخطط.
انشر من المكدس الرسمي لـ Supabase، لا من compose محلي الصنع
قد يبدو إغراؤك في كتابة docker-compose مُختزَل بالخدمات التي تحتاجها وحسب. في الواقع، هذا يتعطّل: تنفِّذ صورة supabase/postgres نصها الخاص للهجرة (migrate.sh) الذي يُنشئ الأدوار الأساسية (supabase_admin، authenticator، supabase_auth_admin...) ومخطط المصادقة بالكامل، وتتوقع وجود ملفات SQL لتهيئة Supabase مرفوعة كملفات مع توسيع المتغيرات وقت التشغيل. لا يمكن لـcompose داخلي مستقل استنساخ ذلك (يُفسِّر Docker Compose المتغيرات داخل الإعدادات الداخلية، تاركًا مخطط المصادقة نصف مهاجَر وGoTrue يفشل بـ'must be owner of function auth.uid()'). المقاربة الصلبة — تلك التي يستخدمها ServOrbit — هي نشر ملفات Docker الرسمية لـSupabase، مثبَّتة على إصدار محدد، وترك migrate.sh يُشغِّل الإقلاع تمامًا كما يتوقعه upstream.
النسخ الاحتياطي التلقائي لنسختك
لا ينشئ نشر Supabase عبر Docker أي نسخة احتياطية من تلقاء نفسه، وهذه أكثر ثغرة يبلّغ عنها من يستضيفونه ذاتيًا. تتكامل آليتان. الأولى، pg_dump، تنتج نسخة منطقية كاملة: شغّلها من المضيف عبر cron، واكتبها إلى وحدة تخزين منفصلة عن وحدة قاعدة البيانات، واحتفظ بعدة أجيال منها. والثانية، أرشفة WAL، تسجّل كل معاملة وتتيح الرجوع إلى لحظة محددة بدل الرجوع إلى آخر نسخة. الأولى تكفي معظم المشاريع، والثانية تصبح ضرورية حين يكون فقدان يوم من الكتابات غير مقبول. وفي الحالتين، لا تساوي النسخة الاحتياطية شيئًا قبل أن تثبت الاستعادة صحتها: أنشئ نسخة فارغة وأعد تشغيل ملف النسخ داخلها قبل أن تحتاج إليها فعلًا.
تخفيف الحزمة: خدمة التحليلات
يتضمّن ملف Docker الرسمي خدمة Logflare للتحليلات الداخلية في Supabase باسم analytics. وهي ليست ضرورية لواجهة البرمجة ولا للمصادقة ولا للتخزين، بل هي أداة مراقبة. على خادم افتراضي محدود الموارد، كثيرًا ما تظهر بحالة unhealthy دون أن يتأثر بقية المكوّنات، وينتهي كثير من المستضيفين ذاتيًا إلى تعطيلها في ملف docker-compose.yml. قِس استهلاكها الفعلي لديك عبر docker stats قبل أن تقرر: إن كانت مراقبتك تمرّ أصلًا عبر أداة خارجية فلن تخسر شيئًا، وإن كنت تعتمد على سجلّاتها فلا تعطّلها إلا بعد توصيل بديل.
الانتقال من Kong إلى Envoy: ما الذي يتغيّر، ولمن يُعدّ كاسرًا
في أسبوع 9 أغسطس 2026 جعلت Supabase من Envoy بوّابة الـ API الافتراضية للتنصيبات المستضافة ذاتيًا، وانتقل Kong إلى طبقة اختيارية. كان Envoy متاحًا منذ عدّة إصدارات عبر docker-compose.envoy.yml — الذي تغيّر هو الافتراضي.
في docker-compose.yml صارت الخدمة تُسمّى api-gw والحاوية supabase-envoy، لكن الاسم الشبكي البديل kong باقٍ: الخدمات التي تنادي البوّابة بهذا الاسم تستمر في العمل. ويبقى منفذ HTTP هو 8000، ويُضبط عبر API_GW_HTTP_PORT، فلا يحتاج وسيطك العكسي Caddy أو Nginx إلى أي تعديل.
⚠️ تصف Supabase هذا التغيير بأنه كاسر لجزء من المستضيفين ذاتيًا، وعليك أن تعرف إن كنت منهم. ثلاث حالات: كنت تعتمد على منفذ HTTPS 8443 المدمج في Kong — لم يعد يُشحن افتراضيًا، وإنهاء TLS صار عبر docker-compose.caddy.yml أو docker-compose.nginx.yml؛ كان لديك ملف volumes/api/kong.yml مخصّص — يجب نقل المسارات والإضافات إلى إعدادات Envoy في volumes/api/envoy/؛ أو كانت سكربتاتك تشير إلى البوّابة باسم الخدمة. وفي الحالات الثلاث يمكنك البقاء على Kong: sh run.sh config add kong.
الانتقال إلى Envoy دون كسر بوّابتك
اعرف على أيّ شيء تعمل
نفّذ
docker compose ps. وجود حاويةsupabase-kongيعني أنك ما زلت على Kong، وsupabase-envoyيعني أن التحويل تمّ. تحقّق أيضًا مما إذا كانvolumes/api/kong.ymlمختلفًا عن نسخة المستودع — هذا الملف هو ما يقرّر إن كانت الهجرة ستكلّفك عملًا.خُذ نسخة احتياطية قبل لمس ملف compose
نفّذ
pg_dumpكاملًا، ولقطة للخادم إن أتاحها مزوّدك. تبديل البوّابة لا يمسّ مخطّط PostgreSQL، لكنه يغيّر مسار دخول كل الطلبات: التراجع السريع أفضل من التشخيص تحت الضغط.قرّر: النقل أم البقاء
إن كان
kong.ymlلديك هو ملف المستودع فلا شيء لتنقله. وإن كان يحوي مساراتك أو إضافاتك، فأمامك طريقان: ترجمتها إلى إعدادات Envoy ضمنvolumes/api/envoy/، أو البقاء على Kong عبرsh run.sh config add kongريثما تفعل. البقاء قرار مشروع لا فشل.اسحب ملف compose الجديد وأعد التشغيل
اسحب أحدث نسخة من مجلّد
dockerفي مستودع Supabase الرسمي، ثمdocker compose down && docker compose up -d. تحقّق من وصولapi-gwإلى حالةhealthyومن استجابة الـ API على المنفذ 8000.أعد TLS إن كنت تعتمد على منفذ 8443 في Kong
لم يعد منفذ HTTPS المدمج يُشحن. أضف إنهاء TLS عبر
docker-compose.caddy.ymlأوdocker-compose.nginx.yml، أو دع وسيطك العكسي الحالي يتولّاه أمام المنفذ 8000. هذه هي النقطة الأكثر كسرًا، ولا تظهر إلا عند أول نداء HTTPS مباشر.تحقّق من التخزين والروابط الموقَّعة
جرّب تنزيلًا من حاوية خاصة عبر رابط موقَّع مسبقًا. إن حصلت على 403 بعد التحويل، فانظر أولًا في إعادة كتابة ترويسة
Hostوفي قيمة الرابط العام لخدمة التخزين لديك: هناك يقع الفرق بين البوّابتين.
Kong وEnvoy نقطة بنقطة
مرّر الجدول أفقيًا
| الجانب | Kong (قبل أغسطس 2026) | Envoy (الافتراضي منذ ذلك الحين) |
|---|---|---|
| الخدمة في `docker-compose.yml` | `kong` | `api-gw` — مع الإبقاء على `kong` كاسم شبكي بديل |
| الحاوية | `supabase-kong` | `supabase-envoy` |
| منفذ HTTP | 8000 | 8000 — عبر `API_GW_HTTP_PORT` |
| منفذ HTTPS المدمج | 8443 | **أُزيل** — TLS عبر `docker-compose.caddy.yml` أو `.nginx.yml` |
| الإعدادات | `volumes/api/kong.yml` | `volumes/api/envoy/` (YAML مُصدَّر بإصدارات) |
| العودة إلى Kong | — | `sh run.sh config add kong` |
CVE-2026-31813: ثغرة OIDC في GoTrue — حدِّث الآن
أُفصح في 2026 عن ثغرة في GoTrue (خدمة المصادقة في Supabase) تحت المرجع CVE-2026-31813. تكمن الثغرة في التحقق من الـclaim iss أثناء مصادقة OIDC: كان JWT موقَّع من مزوِّد هوية خارجي (Apple أو Azure) بـiss مختلف عن المُهيَّأ في GoTrue يُقبَل في ظروف إعداد معينة.
عمليًا، يستطيع مهاجم يتحكم في مزوِّد OIDC مسجَّل في التطبيق العميل إصدار رموز صالحة لمستخدمين عشوائيين على نسخة Supabase الخاصة بك. النطاق الفعلي يعتمد على الإعداد: تتأثر فقط النسخ التي تحتوي على مزوِّد OAuth خارجي مفعَّل واحد على الأقل (Social Auth). النسخ التي تستخدم المصادقة بالبريد الإلكتروني/كلمة المرور أو الروابط السحرية حصرًا غير مكشوفة.
التصحيح مضمَّن في Supabase Auth (GoTrue) 2.185.0. للتحقق من إصدارك: docker compose exec auth gotrue version. إن كان إصدار gotrue أدنى من 2.185.0، حدِّث فورًا.
تحديث GoTrue لإصلاح CVE-2026-31813
تحديد الإصدار الحالي
من مجلد مكدس Supabase الخاص بك:
docker compose exec auth gotrue version. إن أظهرت النتيجة إصدارًا < 2.185.0، فنسختك مكشوفة لـCVE-2026-31813. سجِّل أيضًا إصدار المكدس العام:grep 'SUPABASE_VERSION' .env(إن ثبَّته) أوdocker compose images | grep supabase.النسخ الاحتياطي قبل التحديث
قبل أي تحديث، انسخ قاعدة البيانات:
docker compose exec db pg_dumpall -U postgres > /tmp/supabase-backup-$(date +%F).sql. تحديث GoTrue لا يستلزم هجرة مخطط PostgreSQL، لكن النسخة الاحتياطية المسبقة تبقى قاعدة قبل أي تغيير في إصدار بيئة الإنتاج.التحديث إلى Supabase Auth 2.185.0 أو أحدث
في
docker-compose.yml، حدِّث علامة صورةsupabase/gotrueإلىv2.185.0أو أحدث، أو إن كنت تتبع المكدس الكامل، اسحب آخر إصدار متوافق:docker compose pull && docker compose up -d auth. تحديث GoTrue وحده لا يستلزم إعادة تشغيل الخدمات الأخرى. تحقق بـdocker compose exec auth gotrue versionمن تفعيل الإصدار الجديد.التحقق من مصادقة OIDC
بعد التحديث، اختبر تدفق مصادقة كاملًا مع كل مزوِّد OIDC مُهيَّأ (Google وGitHub...): تسجيل دخول، خروج، إعادة دخول. تحقق في سجلات GoTrue (
docker compose logs auth) من غياب رسائل خطأ متعلقة بالتحقق منissفي ظروف الاستخدام الطبيعي.
إن تعذَّر التحديث الفوري (نافذة صيانة مطلوبة)، يمكنك تقليص سطح الهجوم بتعطيل مزوِّدي OAuth الخارجيين مؤقتًا في Studio Supabase: Authentication ← Providers، ثم تعطيل كل مزوِّد اجتماعي. تبقى مصادقة البريد الإلكتروني/كلمة المرور تعمل. هذا حل مؤقت: لا يُصلِح الثغرة، يُقلِّص فقط سطح الهجوم ريثما تُعدّ التحديث.
