راه‌اندازی Supabase خودمیزبان روی سرور مجازی و اختصاصی با Docker: جایگزین متن‌باز Firebase

اگر پروژه‌ای با Firebase شروع کرده‌اید و حالا به کنترل بیشتر روی داده‌ها، هزینه قابل پیش‌بینی یا الزامات نگهداری داده در داخل کشور نیاز دارید، Supabase خودمیزبان یکی از مسیرهای جدی است. Supabase همان مجموعه سرویس‌هایی را ارائه می‌دهد که از Firebase می‌شناسید — دیتابیس، احراز هویت، storage و API بلادرنگ — با این تفاوت که کاملاً متن‌باز است و می‌توانید کل استک را روی سرور خودتان اجرا کنید.

این راهنما مسیر کامل راه‌اندازی Supabase روی سرور مجازی یا اختصاصی با Docker را پوشش می‌دهد: از انتخاب پلن مناسب از نظر RAM و CPU تا تنظیم secrets واقعی، امن‌سازی، HTTPS و پشتیبان‌گیری.

چرا Supabase خودمیزبان به‌جای Firebase؟

Firebase یک سرویس مدیریت‌شده و بسته است؛ یعنی داده‌ها روی زیرساخت گوگل ذخیره می‌شوند و قیمت‌گذاری بر اساس مصرف، در پروژه‌های با ترافیک بالا به‌سرعت رشد می‌کند. Supabase از PostgreSQL به‌عنوان دیتابیس اصلی استفاده می‌کند، یعنی می‌توانید از SQL استاندارد، view، trigger و extension‌های PostgreSQL بهره ببرید — چیزی که در Firestore وجود ندارد.

نسخه خودمیزبان Supabase دقیقاً همان کدی است که نسخه ابری آن‌ها اجرا می‌کند، فقط روی سرور شما. این یعنی داده روی زیرساختی می‌ماند که خودتان انتخاب کرده‌اید و هزینه به پلن سرور محدود می‌شود، نه به تعداد درخواست یا حجم دانلود.

معیار	Firebase	Supabase خودمیزبان
دیتابیس	Firestore (NoSQL)	PostgreSQL
مدل هزینه	بر اساس مصرف (خواندن/نوشتن/پهنای باند)	هزینه ثابت سرور مجازی/اختصاصی
محل نگهداری داده	زیرساخت گوگل	سروری که خودتان انتخاب می‌کنید
دسترسی به SQL	ندارد	کامل، از جمله extension‌ها
قفل‌شدگی به فروشنده (Vendor Lock-in)	بالا	پایین (متن‌باز، قابل مهاجرت)
نیاز به نگهداری سرور	صفر	باید خودتان آپدیت و بکاپ کنید

نکته مهم: خودمیزبانی مسئولیت نگهداری، امنیت و بکاپ را به شما منتقل می‌کند. اگر تیم DevOps ندارید یا نمی‌خواهید این کارها را انجام دهید، نسخه ابری Supabase یا Firebase گزینه ساده‌تری هستند. برای سرویس‌های دیگری که همین الگو را دنبال می‌کنند، راه‌اندازی Vaultwarden روی سرور مجازی و اختصاصی نمونه دیگری از جایگزین متن‌باز و خودمیزبان یک سرویس ابری است.

پیش‌نیازها

قبل از شروع به این موارد نیاز دارید:

یک سرور مجازی یا اختصاصی با لینوکس (Ubuntu 22.04 یا جدیدتر توصیه می‌شود)
Docker و Docker Compose نصب‌شده
یک دامنه یا ساب‌دامنه که DNS آن به IP سرور اشاره کند
دسترسی SSH با کاربر دارای دسترسی sudo

نصب Docker روی Ubuntu:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

انتخاب پلن مناسب از نظر RAM و CPU

استک Supabase از چند سرویس تشکیل شده: PostgreSQL، GoTrue (احراز هویت)، PostgREST (API)، Realtime، Storage، Kong (API Gateway) و Studio. این یعنی حتی در بار کم، چند container به‌صورت هم‌زمان اجرا می‌شوند و به منابع بیشتری نسبت به یک اپلیکیشن تک‌سرویسی نیاز دارید.

نمودار معماری استک Supabase خودمیزبان شامل PostgreSQL، GoTrue، PostgREST، Realtime، Storage، Kong و Studio روی Docker Compose

نوع پروژه	RAM پیشنهادی	CPU پیشنهادی	نوع سرور
توسعه/تست، ترافیک کم	۴ گیگابایت	۲ هسته	سرور مجازی
پروژه تولیدی کوچک تا متوسط	۸ گیگابایت	۴ هسته	سرور مجازی
ترافیک بالا یا چند دیتابیس	۱۶ گیگابایت به بالا	۶ هسته به بالا	سرور اختصاصی

اگر پروژه در مرحله MVP یا تست است، یک سرور مجازی با ۴ تا ۸ گیگابایت رم برای شروع کافی است. برای پروژه‌هایی که کوئری‌های سنگین PostgreSQL، تعداد بالای اتصال هم‌زمان یا چند محیط (staging/production) روی یک ماشین دارند، سرور اختصاصی گزینه پایدارتری است چون منابع به‌طور کامل در اختیار شماست و رقابت با سایر مستأجران وجود ندارد. هنگام انتخاب سرور مجازی هم به کیفیت منابع توجه کنید، نه فقط رقم RAM و CPU؛ چرا سرور مجازی ارزان کند است؟ توضیح می‌دهد Steal Time و Noisy Neighbor چطور می‌توانند عملکرد PostgreSQL را حتی روی یک پلن با رم کافی پایین بیاورند.

نصب Supabase با Docker Compose

Supabase یک ریپازیتوری رسمی برای نصب خودمیزبان دارد که فایل‌های Docker Compose آماده در آن قرار دارد:

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env

فایل .env شامل تمام کلیدها و رمزهای سرویس‌هاست. قبل از اجرا، این فایل باید کامل بازنویسی شود — مقادیر پیش‌فرض آن در ریپازیتوری عمومی قابل مشاهده هستند و هرگز نباید در محیط تولیدی استفاده شوند.

مقادیری که باید با کلیدهای واقعی و تصادفی جایگزین شوند:

POSTGRES_PASSWORD — رمز عبور دیتابیس اصلی
JWT_SECRET — کلید امضای توکن‌ها، حداقل ۳۲ کاراکتر تصادفی
ANON_KEY و SERVICE_ROLE_KEY — این دو باید با JWT_SECRET جدید تولید شوند، نه صرفاً کپی از مقدار پیش‌فرض
DASHBOARD_USERNAME و DASHBOARD_PASSWORD — برای دسترسی به Supabase Studio

برای تولید JWT_SECRET تصادفی:

openssl rand -base64 32

ANON_KEY و SERVICE_ROLE_KEY باید توکن‌های JWT معتبر امضاشده با JWT_SECRET جدید باشند؛ مستندات رسمی Supabase یک اسکریپت برای تولید این دو کلید بر اساس secret جدید ارائه می‌دهد که باید پیش از اجرای اولین بار استفاده شود.

بعد از تکمیل .env، سرویس‌ها را بالا بیاورید:

docker compose up -d

اجرای اول ممکن است چند دقیقه طول بکشد چون PostgreSQL باید migration‌های اولیه را اجرا کند. وضعیت container‌ها را با docker compose ps بررسی کنید؛ همه سرویس‌ها باید در وضعیت running یا healthy باشند. اگر با نصب سرویس‌های چندکانتینری روی Docker Compose آشنایی کمتری دارید، نصب و راه‌اندازی n8n با Docker یک مثال دیگر از همین الگو (پایگاه‌داده، HTTPS و مقیاس‌پذیری) را قدم‌به‌قدم نشان می‌دهد.

امن‌سازی و HTTPS با ریورس‌پروکسی

به‌صورت پیش‌فرض، Kong (API Gateway) روی پورت‌های ۸۰۰۰ و ۸۴۴۳ گوش می‌دهد، بدون گواهی TLS معتبر. برای محیط تولیدی، پورت‌های Docker نباید مستقیم به اینترنت باز باشند؛ به‌جای آن یک ریورس‌پروکسی مثل Nginx یا Caddy جلوی آن قرار می‌گیرد.

نمونه پیکربندی ساده با Nginx برای فوروارد کردن ترافیک به Kong:

server {
    listen 443 ssl;
    server_name supabase.example.com;

    ssl_certificate     /etc/letsencrypt/live/supabase.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/supabase.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

گواهی TLS را می‌توان با Certbot و Let's Encrypt به‌صورت رایگان صادر کرد:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d supabase.example.com

علاوه بر HTTPS، این موارد را هم بررسی کنید:

فایروال سرور فقط پورت‌های ۲۲، ۸۰ و ۴۴۳ را باز نگه دارد؛ پورت‌های داخلی Docker (۵۴۳۲، ۸۰۰۰) نباید از بیرون قابل دسترس باشند
DASHBOARD_PASSWORD رمزی قوی و غیرتکراری باشد، چون Studio دسترسی کامل به دیتابیس دارد
به‌روزرسانی منظم image‌های Docker با docker compose pull و docker compose up -d

پشتیبان‌گیری

خودمیزبانی یعنی مسئولیت بکاپ کاملاً به عهده شماست؛ برخلاف نسخه ابری، بکاپ خودکار روزانه به‌صورت پیش‌فرض وجود ندارد. حداقل دو چیز باید پشتیبان‌گیری شوند: دیتابیس PostgreSQL و volume مربوط به Storage.

بکاپ دیتابیس با pg_dump:

docker compose exec db pg_dump -U postgres -d postgres > backup-$(date +%F).sql

بهتر است این دستور را در یک cron job روزانه قرار دهید و خروجی را به یک مقصد خارج از همان سرور (فضای ذخیره‌سازی جدا یا سرور دیگر) منتقل کنید؛ نگه‌داشتن بکاپ فقط روی همان سرور در صورت خرابی دیسک یا حمله، عملاً بی‌فایده است.

نگهداری و ارتقا در بلندمدت

بعد از راه‌اندازی اولیه، چند کار تکراری روی دوش شماست که در نسخه ابری خودکار انجام می‌شوند:

آپدیت نسخه: تیم Supabase به‌صورت مرتب image‌های جدید منتشر می‌کند. قبل از هر آپدیت روی محیط تولیدی، حتماً یک بکاپ کامل بگیرید و ابتدا روی یک محیط تست همان تغییرات را اعمال کنید؛ برخی نسخه‌ها migration دیتابیس دارند که برگشت‌ناپذیر است.
پایش مصرف منابع: با docker stats یا ابزارهایی مثل Netdata مصرف RAM و CPU هر container را زیر نظر بگیرید. اگر PostgreSQL مدام به سقف حافظه نزدیک می‌شود، معمولاً نشانه‌ای است که باید به پلن بالاتر مهاجرت کنید، نه اینکه تنظیمات را فشرده‌تر کنید.
بررسی لاگ‌ها: docker compose logs -f db و docker compose logs -f auth برای عیب‌یابی مشکلات اتصال یا احراز هویت مفید هستند، مخصوصاً وقتی کلاینت فرانت‌اند خطای غیرمنتظره از API می‌گیرد.

اگر تعداد کاربران یا حجم درخواست به‌طور پیوسته رشد کند، مهاجرت دیتابیس به یک سرور با دیسک NVMe و رم بیشتر معمولاً ساده‌تر از تلاش برای بهینه‌سازی روی سخت‌افزار فعلی است. برای پروژه‌هایی که دیگر نمی‌توانند قطعی PostgreSQL را تحمل کنند، راه‌اندازی Replication و Failover خودکار در PostgreSQL روی دو سرور جداگانه مسیر بعدی طبیعی است. به همین ترتیب، وقتی یک سرور اختصاصی برای کل استک کافی نیست، راه‌اندازی کلاستر Docker Swarm روی چند سرور نحوه توزیع container‌ها بین چند ماشین را توضیح می‌دهد.

جمع‌بندی

Supabase خودمیزبان کنترل کامل روی داده و هزینه‌ای قابل پیش‌بینی می‌دهد، اما در مقابل نگهداری، امن‌سازی و بکاپ را به عهده شما می‌گذارد. برای شروع، یک سرور مجازی با ۴ تا ۸ گیگابایت رم کافی است؛ اگر پروژه رشد کرد یا نیاز به منابع اختصاصی و پایدار داشتید، مهاجرت به سرور اختصاصی گزینه بعدی است.

اگر می‌خواهید بدون درگیر شدن با جزئیات زیرساخت شروع کنید، سرورهای مجازی آریانت با پیکربندی SSD و پهنای باند مناسب برای اجرای این نوع استک‌ها آماده هستند:

مشاهده پلن‌های سرور مجازی آریانت

برای پروژه‌هایی با نیاز به منابع بیشتر یا ایزوله بودن کامل زیرساخت، سرورهای اختصاصی هم گزینه مناسبی برای اجرای Supabase در مقیاس بزرگ‌تر هستند.