استضافة Penpot على VPS: بديل Figma مفتوح المصدر

يتشارك Figma وPenpot النموذج نفسه: تصميم متجهي داخل المتصفح، وتعاون في الزمن الفعلي، ومكوّنات قابلة لإعادة الاستخدام، وتسليم مدمج للمطورين. يكمن الفرق الجوهري في نموذج البيانات وفي التحكم. يخزّن Figma كل شيء على خوادمه بصيغة مملوكة. أما Penpot فيعتمد على SVG وCSS لغةً أساسية ويعمل على بنيتكم التحتية: أنتم تقررون أين تعيش الملفات، ومن يتصل، ومتى تُحدّثون. بالنسبة إلى فريق يستضيف شيفرته على Gitea ووثائقه على Docmost ومراسلاته على Mattermost، فإن استضافة أداة التصميم على ServOrbit أيضاً هي الخطوة المنطقية التالية. الثمن هو التشغيل: النسخ الاحتياطي والتحديثات وتحديد الحجم تصبح من مسؤوليتكم، وهذا ما تعالجه الأقسام التالية.

Penpot حزمة من عدة حاويات. يعلن ملف Compose الذي ينشره المشروع، في الإصدار 2.18، ثماني خدمات: penpot-frontend وpenpot-backend وpenpot-admin-console وpenpot-mcp وpenpot-exporter وpenpot-postgres وpenpot-valkey وpenpot-mailpit. يشغّل قالب ServOrbit مجموعة جزئية بحسب إصداره: يُقرأ العدد الدقيق بالأمر docker compose ps على الـ VPS. يعطي الجدول أدناه دور كل خدمة كما يصفه ملف Compose الأصلي. منفذ واحد فقط يهم من جهة التعريض: تستمع الواجهة الأمامية داخلياً على 8080 وينشرها Compose على 9001. ضعوا الوكيل العكسي أمام هذا المنفذ ولا شيء غيره.

لا تنشر الوثائق الأصلية حداً أدنى لفريق صغير. فهي تذكر أن 4 معالجات و16 غيغابايت من الذاكرة تكفي لخدمة آلاف المستخدمين، وتتيح لكم التحفظ عند تخصيص الموارد. وبالنسبة إلى القرص توصي بالبدء بمساحة قاعدة بيانات بين 50 و100 غيغابايت قابلة للتوسع، وهي تغطي حتى 10 محررين، ثم نحو 5 غيغابايت إضافية لكل محرر زائد. الحجم الفعلي يتبع الاستخدام وتعقيد الملفات لا عدد الحسابات. توصيتنا التحريرية لفريق من بضعة أشخاص: VPS بذاكرة 4 غيغابايت مع حد لكل خدمة (قسم الذاكرة أدناه)، وهو يترك هامشاً لتصدير الملفات الثقيلة؛ ويكفي 2 غيغابايت للتجربة. على مستوى الشبكة افتحوا 80 و443 نحو الوكيل العكسي، ولا تفتحوا 9001 أو 8025 مباشرةً. الحد الأقصى لجسم الطلب في Compose هو 367001600 بايت (350 ميبيبايت): يجب أن يوافقه client_max_body_size في وكيلكم. أما على جهاز المستخدم فتوصي الوثائق بآخر إصدار مستقر من Chrome.

بالنسبة إلى البريد فعّلوا enable-smtp في PENPOT_FLAGS واضبطوا في الخلفية PENPOT_SMTP_DEFAULT_FROM وPENPOT_SMTP_DEFAULT_REPLY_TO وPENPOT_SMTP_HOST وPENPOT_SMTP_PORT (القيمة 587 في المثال الأصلي) وPENPOT_SMTP_USERNAME وPENPOT_SMTP_PASSWORD وPENPOT_SMTP_TLS. يشير Compose الأصلي افتراضياً إلى penpot-mailpit الذي يحتفظ بالرسائل في الذاكرة ويفقدها عند إعادة إنشاء الحاوية. في الإنتاج أزيلوا أيضاً disable-email-verification الذي لا تنصح به الوثائق خارج التجارب. أما بالنسبة إلى الملفات فتُخزَّن الصور ومقاطع SVG التي يرفعها المستخدمون افتراضياً على نظام الملفات، في وحدة التخزين penpot_assets المركّبة على /opt/data/assets (PENPOT_OBJECTS_STORAGE_BACKEND: fs). والتخزين المتوافق مع S3 ممكن عبر PENPOT_OBJECTS_STORAGE_BACKEND: s3 مع bucket ونقطة نهاية اختيارية والمتغيرين AWS_ACCESS_KEY_ID وAWS_SECRET_ACCESS_KEY. منذ الإصدار 2.11.0 استُبدلت الأسماء القديمة PENPOT_STORAGE_ASSETS_* بالأسماء PENPOT_OBJECTS_STORAGE_*: إن أعدتم استخدام ملف Compose قديم فغيّروا أسماءها.

لنسخة Penpot حالتان يجب نسخهما معاً: قاعدة PostgreSQL ووحدة تخزين الملفات. تحذّر الوثائق الأصلية من أنه لا يمكن نسخ مجلد بيانات وحدة تخزين Docker مباشرةً، وتحيل إلى إجراء النسخ الاحتياطي لوحدات التخزين في Docker. نهجنا: تصدير منطقي للقاعدة بالأمر docker exec penpot-penpot-postgres-1 pg_dump -U penpot penpot > penpot.sql، ثم أرشفة وحدة تخزين الملفات عبر حاوية مؤقتة تركّبها للقراءة فقط. اعثروا على أسماء الوحدات بالأمر docker volume ls. خذوا النسختين في اللحظة نفسها، وإلا قد تشير القاعدة إلى ملفات غائبة عن الأرشيف، وجرّبوا الاستعادة على VPS آخر قبل أن تحتاجوا إليها. وللتحديث ثبّتوا الإصدار عبر PENPOT_VERSION بدل اتباع آخر صورة، ونفّذوا docker compose -p penpot -f docker-compose.yaml pull ثم up -d، وتقدموا بخطوات صغيرة: تنصح الوثائق بعدم القفز بين إصدارات متباعدة. في 1 نوفمبر 2026 كان آخر إصدار منشور هو 2.18.5. وإن كنتم تصونون ملف Compose خاصاً بكم، فقد أضاف الإصدار 2.18 خدمة penpot-admin-console والمتغير PENPOT_ADMIN_CONSOLE_URI في الواجهة الأمامية والخلفية. انسخوا احتياطياً دائماً قبل التحديث.

البلاغ #3299 في مشروع penpot، المفتوح في يونيو 2023، ما زال مفتوحاً وتلقى رسالة في أكتوبر 2026. يجمع شهادات عن استهلاك مرتفع للذاكرة في تثبيتات Docker: مستخدم يذكر نحو 20 غيغابايت مشغولة بعد ثلاثة إلى أربعة أيام على خادم بذاكرة 64 غيغابايت، وآخر أكثر من 50 غيغابايت تطلبها آلة افتراضية بلا مستخدمين، وثالث 15 غيغابايت لمستخدم واحد مع إعادة تشغيل الخلفية كل 12 ساعة. هذه تقارير فردية لم يُعد إنتاجها: يرد عضو في فريق Penpot داخل النقاش بأن لديهم تثبيتات Docker بحركة كبيرة دون هذا العرض، ويطلب ملفاً وسجلات للتشخيص. لذلك لا يمكننا الوعد برقم استهلاك. ما يمكننا قوله هو كيف لا نترك خدمة واحدة تقرر وحدها: الخلفية عملية Java، ومن دون حد على الحاوية تحدد آلة Java الافتراضية حجم الـ heap بحسب الذاكرة التي تراها، أي ذاكرة المضيف كله. حد لكل خدمة يحوّل انحرافاً صامتاً إلى إعادة تشغيل مضبوطة.

خلافاً لما يُقرأ أحياناً، لا يستورد Penpot ملف .fig. يصون المشروع إضافة لـ Figma اسمها « Penpot Exporter » تحوّل ملف Figma إلى أرشيف .zip قابل للاستيراد. في Figma افتحوا الملف، ثم Resources ثم Plugins، وابحثوا عن « Penpot Exporter » وشغّلوا التصدير. في Penpot افتحوا قائمة النقاط الثلاث لمشروع أو للمسودات، واختاروا « Import Penpot files » وحددوا ملف .zip. بحسب README الخاص بالإضافة يُنقل ما يلي: الأشكال الأساسية والمتجهات والإطارات والأقسام (لوحات boards في Penpot) والمجموعات والأقنعة والنصوص والتعبئة والحدود والظلال والمكوّنات ونسخها وauto layouts والنسخ المتغيرة ومكتبات الألوان والخطوط. ولا تُنقل إعدادات النماذج الأولية. تبقى الملفات الضخمة نقطة صعبة لأن التصدير يمر على كل عقدة تحت حدود واجهة Figma البرمجية، وقد تختلف بعض عمليات العرض قليلاً. استوردوا ملف اختبار أولاً، وقارنوا المكوّنات والخطوط، ثم انقلوا الباقي. تُرفع الخطوط المخصصة إلى Penpot.

لا يخزّن Penpot تصاميمكم كملفات نصية في مستودع: مصدر الحقيقة هو قاعدة PostgreSQL. غير أن تصديرين يناسبان Git. أرشيف .penpot نسخة احتياطية محمولة لملف. وتصدير SVG للوحة ينتج نصاً مقروءاً يمكنكم رفعه إلى Gitea، مثلاً لأيقونات ورسوم نظام التصميم. يعرض طلب الدمج حينئذ الفرق في SVG، ويمكن لخط CI أن يكشف تغييراً غير متوقع. يبقى هذا النهج اتفاقاً داخل الفريق: يفترض إعادة التصدير بعد كل تغيير، وهو ما يمكن لسكربت أو لمراجعة تصميم أن يذكّركم به.