بهترین برنامه‌های self-hosted برای اجرا در سال 2026

آنچه در حال ساخت آن هستید

این یک برنامه واحد نیست، بلکه یک فهرست کوتاه است. این مرکز اصلی برای تمام موارد دیگر در این سایت است: بیست و پنج برنامه‌ای که در سال 2026 واقعاً ارزش اجرا روی VPS شخصی شما را دارند و بر اساس وظیفه‌ای که انجام می‌دهند دسته‌بندی شده‌اند. برای هر مورد، سرویسی که جایگزین می‌شود، میزان واقعی رم و دیسک مورد نیاز، و نکته کلیدی که در صورت نادیده گرفتن برایتان دردسرساز خواهد شد، ذکر شده است. لینک‌ها به راهنمای گام‌به‌گام کامل (در صورت وجود) اشاره دارند.

من پانزده سال است که یک میزبان VPS را مدیریت می‌کنم و اکثر این موارد را روی سرورهای خودم اجرا می‌کنم. بنابراین، اعداد مربوط به منابع در زیر، مقادیری هستند که برنامه در یک بار کاری واقعی و کوچک استفاده می‌کند، نه «حداقل‌های» ذکر شده در صفحات تبلیغاتی. آن‌ها را به عنوان یک بودجه در نظر بگیرید و سپس مقداری فضای اضافی برای اطمینان به آن اضافه کنید.

پیش‌نیازها و واقعیت‌های موجود

هر برنامه در این فهرست روی یک VPS تازه با سیستم‌عامل Ubuntu 24.04 KVM و دسترسی root یا sudo اجرا می‌شود. همین فهرست روی دستگاهی در خانه شما نیز به همان خوبی کار می‌کند؛ اگر در حال مقایسه هزینه اجاره ماهانه با خرید یک‌باره رم هستید، Proxmox در خانه در برابر VPS اجاره‌ای محاسبات سخت‌افزاری و مصرف برق را بررسی می‌کند. تقریباً تمام این برنامه‌ها به صورت Docker container عرضه می‌شوند، بنابراین کافی است Docker را یک‌بار نصب کنید تا برای کل فهرست آماده باشید:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-world

اگر دستورات docker با خطای permission denied while trying to connect to the Docker daemon socket مواجه شدند، یعنی مرحله افزودن به گروه را نادیده گرفته‌اید یا شل (shell) جدیدی باز نکرده‌اید؛ از سیستم خارج شده و دوباره وارد شوید. اگر docker compose خروجی docker: 'compose' is not a docker command را برمی‌گرداند، یعنی شما نسخه قدیمی و مستقل باینری را دارید؛ اسکریپت بالا افزونه مدرن Compose را نصب می‌کند که باید آن را به صورت docker compose (با فاصله، نه خط تیره) فراخوانی کنید.

سه واقعیت، ساختار تمام موارد زیر را تعیین می‌کند. نخست، رم محدودیت اصلی است، نه دیسک یا پردازنده. یک VPS با 1 گیگابایت رم فقط یک برنامه کوچک را اجرا می‌کند و نه بیشتر. 4 گیگابایت رم نقطه تعادل واقعی برای سروری است که قرار است «چند سرویس را میزبانی کند». 2 گیگابایت رم وضعیت دشواری است که در آن کاربر تازه‌کار سرویس سوم را اضافه می‌کند، با خطای Out-Of-Memory (OOM) مواجه می‌شود و هرگز نمی‌فهمد چرا کانتینر ناپدید شده است؛ sudo dmesg خط Out of memory: Killed process را که توسط دیمون بلعیده شده است، نشان می‌دهد. دوم، هر سرویس عمومی به نام دامنه و گواهی نیاز دارد؛ استفاده از IP خام فقط برای تست مناسب است و به محض اینکه بخواهید یک اپلیکیشن موبایل یا مرورگر به آن اعتماد کند، با مشکل مواجه می‌شوید. سوم، دو پورت نیمی از گزینه‌های شما را تعیین می‌کنند: پورت‌های 80 و 443 باید برای TLS خودکار در دسترس باشند و پورت خروجی 25 توسط اکثر ارائه‌دهندگان مسدود است؛ به همین دلیل است که ایمیل در فهرست «نبایدها» در انتهای متن قرار دارد.

فایل‌ها و عکس‌ها

• Nextcloud جایگزینی برای Google Drive، Dropbox و Google Calendar در یک مجموعه واحد است. برای آن 1 تا 2 گیگابایت رم به علاوه فضای مورد نیاز برای فایل‌هایتان در نظر بگیرید. نکته مهم: استفاده از SQLite برای محیط دمو مناسب است اما در محیط عملیاتی (production) یک تله محسوب می‌شود؛ از همان ابتدا آن را روی PostgreSQL نصب کنید، زیرا مهاجرت دیتابیس پس از بارگذاری داده‌ها، رایج‌ترین راه برای خراب کردن Nextcloud است. راهنمای کامل Nextcloud روی VPS با Docker، TLS و پشتیبان‌گیری آن را از همان ابتدا به درستی پیکربندی می‌کند.
• Immich جایگزینی برای Google Photos است، با همان قابلیت‌های اپلیکیشن موبایل برای آپلود خودکار تصاویر دوربین و جستجوی چهره و اشیاء. حداقل 6 گیگابایت رم برای آن در نظر بگیرید (طبق مستندات Immich)، اگرچه 8 گیگابایت عملکرد راحت‌تری را فراهم می‌کند؛ کانتینر یادگیری ماشین (machine-learning) بخش پرمصرف آن است. فضای دیسک مورد نیاز نیز برابر با حجم کتابخانه شما به علاوه حدود بیست درصد برای تصاویر بندانگشتی (thumbnails) است. نکته مهم: Immich همچنان در نسخه‌های مختلف تغییرات ساختاری (breaking changes) دارد، بنابراین هرگز بدون بررسی، دستور latest را اجرا نکنید؛ نسخه را ثابت نگه دارید و پیش از هر ارتقا، یادداشت‌های انتشار (release notes) را مطالعه کنید. راهنمای کتابخانه عکس Immich به صورت self-hosted مسیر ارتقای ایمن را پوشش می‌دهد. اگر حداقل 6 گیگابایت رم برای سرور شما زیاد است، مقاله مقایسه PhotoPrism و Immich این دو را از نظر مصرف واقعی حافظه، اپلیکیشن‌های موبایل و دستورات پشتیبان‌گیری مورد نیاز پیش از انتخاب نهایی بررسی می‌کند.
• Seafile جایگزینی برای Dropbox است و سریع‌ترین موتور همگام‌سازی را در میان این سه گزینه دارد. حدود 1 گیگابایت رم برای آن در نظر بگیرید. نکته مهم: Seafile فایل‌های شما را به صورت بلوک‌های آدرس‌دهی‌شده ذخیره می‌کند، نه به صورت فایل‌های معمولی روی دیسک؛ بنابراین نمی‌توانید داده‌ها را با ls مرور کنید و باید حتماً از طریق ابزارهای خودِ Seafile پشتیبان‌گیری کنید، نه با کپی کردن مستقیم پوشه‌ها.

گذرواژه‌ها

• Vaultwarden جایگزینی برای نسخه پولی Bitwarden، LastPass و 1Password است. این سرویس یک سرور کوچک به زبان Rust است که از پروتکل Bitwarden پشتیبانی می‌کند؛ بنابراین تمام اپلیکیشن‌های رسمی Bitwarden و افزونه‌های مرورگر با آن سازگار هستند. برای این سرویس، 100 تا 200 مگابایت رم و فضای دیسک بسیار ناچیزی در نظر بگیرید. نکته مهم: این سرور تمام گذرواژه‌های شما را نگهداری می‌کند، بنابراین استفاده از TLS و تهیه نسخه پشتیبان در اینجا اختیاری نیست، بلکه هدف اصلی است. همچنین ADMIN_TOKEN را به عنوان یک هش Argon2 تنظیم کنید، زیرا وجود یک توکن متنی ساده در فایل compose به معنای قرار دادن کلید اصلی به صورت متن آشکار است. راهنمای مدیریت گذرواژه Vaultwarden بهترین گزینه برای شروع اولین تجربه self-host شماست.

رسانه

• Jellyfin جایگزینی برای Plex و در صورت داشتن آرشیو شخصی، جایگزینی برای Netflix است؛ کاملاً متن‌باز، بدون نیاز به حساب کاربری و بدون محدودیت‌های پولی برای استریم از راه دور. برای این سرویس در حالت idle حدود 1 تا 2 گیگابایت رم در نظر بگیرید، اما هنگام transcode کردن، بار پردازنده به‌شدت افزایش می‌یابد. نکته مهم: transcode نرم‌افزاری یک استریم 4K می‌تواند یک VPS کوچک را از پا درآورد؛ یا از شتاب‌دهنده سخت‌افزاری استفاده کنید یا فایل‌ها را با فرمتی ذخیره کنید که کلاینت‌ها مستقیماً قادر به پخش آن باشند (Direct Play) تا سرور فقط نقش انتقال‌دهنده داده‌ها را ایفا کند. راهنمای Jellyfin media server on a VPS تفاوت این دو حالت را توضیح می‌دهد. پس از راه‌اندازی، Halcyon همان کتابخانه را به یک فروشگاه کرایه فیلم دهه 90 در مرورگر تبدیل می‌کند؛ این جالب‌ترین و مؤثرترین ترفندی است که می‌شناسم تا اعضای خانواده به‌جای اسکرول کردن بی‌هدف، واقعاً در قفسه‌ها به جستجو بپردازند.
• Navidrome جایگزینی برای Spotify جهت استفاده از موسیقی شخصی است که به هر اپلیکیشن سازگار با Subsonic استریم می‌کند. با مصرف 150 تا 300 مگابایت رم، این سرویس که با زبان Go نوشته شده، تقریباً هیچ بار اضافه‌ای روی سیستم ایجاد نمی‌کند. نکته مهم: اولین اسکن کتابخانه، تگ‌های تمام فایل‌ها را می‌خواند و در مجموعه‌های بزرگ ممکن است یک ساعت طول بکشد؛ تگ‌های ID3 نامعتبر، تجربه مرور ضعیفی را به همراه خواهد داشت.
• Audiobookshelf جایگزینی برای Audible و اپلیکیشن پادکست شماست که موقعیت پخش را در دستگاه‌های مختلف همگام‌سازی می‌کند. برای این سرویس 200 تا 500 مگابایت رم در نظر بگیرید. نکته مهم: این سرویس انتظار دارد هر کتاب در یک پوشه مجزا قرار داشته باشد؛ وارد کردن فایل‌ها از یک پوشه نامنظم، باعث ایجاد کتابخانه‌ای به‌هم‌ریخته و ناقص می‌شود که اصلاح آن پس از انجام کار، بسیار خسته‌کننده است.

اتوماسیون و هوش مصنوعی

• n8n جایگزینی برای Zapier و Make است که یک محیط بصری برای ساخت گردش‌کار (workflow) در اختیار شما می‌گذارد؛ شما مالک آن هستید و هزینه‌ای بر اساس تعداد تسک پرداخت نمی‌کنید. برای این سرویس 400 MB تا 1 GB رم در نظر بگیرید. نکته مهم: n8n اعتبارنامه‌های ذخیره‌شده را با کلیدی که در اولین اجرا تولید می‌کند، رمزنگاری می‌کند. اگر این کلید را گم کنید یا فراموش کنید N8N_ENCRYPTION_KEY را تنظیم کنید و اجازه دهید کلید دوباره تولید شود، تمام اعتبارنامه‌های ذخیره‌شده غیرقابل خواندن می‌شوند و باید دوباره آن‌ها را وارد کنید. راهنمای میزبانی n8n با HTTPS کلید را ثابت نگه می‌دارد و یک گواهی معتبر برای URLهای webhook قرار می‌دهد.
• Ollama جایگزینی برای اشتراک ChatGPT جهت استنتاج (inference) محلی و خصوصی مدل‌های زبانی بزرگ (LLM) است. بودجه‌بندی بر اساس مدل: یک مدل 7–8B به حدود 8 GB رم نیاز دارد و هر مدل 4–8 GB فضا روی دیسک اشغال می‌کند. نکته مهم: روی یک VPS که فقط CPU دارد، استنتاج دقیق اما کند است؛ سرعت را به صورت کلمه در ثانیه تصور کنید، نه پاسخ‌های آنی که از APIهای میزبانی‌شده می‌گیرید. بنابراین انتظارات خود را مدیریت کنید یا یک سرور مجهز به GPU اجاره کنید. راهنمای اجرای Ollama برای میزبانی LLM اعداد واقع‌بینانه‌ای ارائه می‌دهد.

ارتباطات

• Rocket.Chat جایگزینی برای Slack در تیم‌هاست که قابلیت‌هایی مانند گفتگوهای رشته‌ای (threads)، تماس و یکپارچه‌سازی با سایر سرویس‌ها را ارائه می‌دهد. حداقل 2 گیگابایت رم برای آن در نظر بگیرید، زیرا این سرویس بر پایه MongoDB اجرا می‌شود که منبع سنگینی است. نکته مهم: Rocket.Chat در هر نسخه، یک نسخه اصلی (major version) خاص از MongoDB را الزامی می‌کند؛ پریدن از یک نسخه به نسخه دیگر هنگام ارتقا باعث از دسترس خارج شدن پایگاه داده می‌شود، بنابراین ارتقا را مرحله‌به‌مرحله انجام دهید. راهنمای Rocket.Chat با Docker Compose مسیر گام‌به‌گام ارتقای نسخه‌ها را توضیح می‌دهد.
• Matrix (Synapse) جایگزینی برای Slack و Discord است که یک شبکه فدرال و رمزنگاری‌شده (end-to-end-encrypted) ارائه می‌دهد که در آن مالکیت سرور در اختیار خودتان است. 1 تا 2 گیگابایت رم برای آن در نظر بگیرید که با عضویت در اتاق‌های عمومی بزرگ، افزایش می‌یابد. نکته مهم: مصرف حافظه Synapse در اتاق‌های فدرال بزرگ به‌شدت افزایش می‌یابد و حتماً باید روی PostgreSQL اجرا شود؛ استفاده از SQLite پیش‌فرض فقط برای تست‌های تک‌کاربره مناسب است و به‌محض فدرال شدن شبکه، از کار می‌افتد. اگر Synapse برای منابع شما سنگین است، سرورهای سبک‌تر مانند Conduit یا Dendrite از همان پروتکل پشتیبانی می‌کنند.

شبکه و دسترسی

• WireGuard جایگزین VPNهای تجاری است و یک تونل خصوصی به IP اختصاصی و سایر سرویس‌های شما ایجاد می‌کند. هزینه آن تقریباً صفر است، کمتر از 50 MB رم اشغال می‌کند و عملیات رمزنگاری آن در سطح kernel اجرا می‌شود. نکته مهم: در مجازی‌سازی مبتنی بر container (مانند OpenVZ و برخی LXCها)، ماژول آن با خطای RTNETLINK answers: Operation not supported مواجه می‌شود؛ بنابراین باید از KVM استفاده کنید. راهنمای راه‌اندازی WireGuard VPN به صورت self-hosted مرجع اصلی شماست و اتصال سرویس‌ها به این تونل، روشی برای دور نگه داشتن کامل آن‌ها از اینترنت عمومی است. اگر نمی‌خواهید برای هر دستگاه جدید به‌صورت دستی فایل پیکربندی peer را ویرایش کنید، اجرای یک Tailscale subnet router روی VPS کل آن محدوده خصوصی را به سایر ماشین‌های شما معرفی می‌کند؛ البته به شرطی که مسیر (route) را تأیید کرده و IP forwarding را برای پس از reboot تنظیم کنید.
• Traefik جایگزین virtual hostهای دستی در nginx و تمدید دستی گواهی‌ها می‌شود؛ این ابزار containerهای شما را از طریق Docker labelها شناسایی کرده و گواهی‌های Let's Encrypt را به‌طور خودکار دریافت می‌کند. حدود 100 MB رم برای آن در نظر بگیرید. نکته مهم: مدل پیکربندی مبتنی بر label در ابتدا گیج‌کننده است و یک label اشتباه باعث می‌شود برنامه بدون هیچ خطای واضحی، مسیریابی نشود. راهنمای استفاده از Traefik به عنوان reverse proxy برای چندین برنامه Docker دقیقاً برای اجرای چندین برنامه معرفی‌شده در این صفحه پشت یک نقطه ورود واحد نوشته شده است.
• AdGuard Home جایگزین دستگاه Pi-hole و سرویس‌های فیلترینگ DNS پولی است و تبلیغات و ردیاب‌ها را برای تمام دستگاه‌های شبکه شما در لایه DNS مسدود می‌کند. حدود 100 تا 150 MB رم برای آن در نظر بگیرید. نکته مهم: این سرویس می‌خواهد پورت 53 را در اختیار بگیرد که با systemd-resolved در اوبونتو تداخل دارد؛ بنابراین تا زمانی که این پورت را آزاد نکنید، با خطای listen udp 0.0.0.0:53: bind: address already in use مواجه شده و اجرا نمی‌شود.

مانیتورینگ

• Uptime Kuma جایگزینی برای Pingdom، UptimeRobot و StatusPage است که داشبوردی تمیز و قابلیت ارسال هشدار به تقریباً هر کانالی را ارائه می‌دهد. برای آن 150 تا 300 مگابایت رم در نظر بگیرید. نکتهٔ مهمی که همیشه نادیده گرفته می‌شود: سرور اصلی خود را از یک سرور دیگر مانیتور کنید؛ اگر Uptime Kuma روی همان سروری اجرا شود که در حال مانیتور کردن آن است، نمی‌تواند زمان از دسترس خارج شدن آن سرور را تشخیص دهد. راهنمای مانیتورینگ وضعیت با Uptime Kuma به نحوهٔ استقرار خارجی می‌پردازد.
• Zabbix جایگزینی برای Datadog و مجموعه‌های مانیتورینگ سازمانی است که متریک‌های عمیق مبتنی بر agent، تریگرها و تاریخچه را ارائه می‌دهد. برای آن 2 گیگابایت رم یا بیشتر، به همراه دیتابیس اختصاصی‌اش در نظر بگیرید. نکتهٔ مهم: Zabbix بسیار قدرتمند و راه‌اندازی آن واقعاً سنگین است؛ برای مانیتور کردن سه کانتینر، استفاده از آن زیاده‌روی است، اما برای مدیریت یک ناوگان از سرورها ابزاری مناسب محسوب می‌شود. با Uptime Kuma شروع کنید و زمانی که واقعاً زیرساختی برای مانیتور کردن داشتید، به سراغ سرور مانیتورینگ Zabbix بروید.

Prometheus و Grafana عمداً در این لیست قرار نگرفته‌اند: آن‌ها ابزارهای فوق‌العاده‌ای برای مقیاس ناوگان هستند، اما اجرای آن‌ها سنگین‌تر از آن است که برای یک استک شخصی با دو یا سه سرور توجیه داشته باشد. در این مقیاس، Uptime Kuma و Zabbix همان نیازها را با هزینهٔ نگهداری کمتر برطرف می‌کنند.

داشبوردها و پنل‌های مدیریتی

این ابزارها مدل کاری شما را تغییر می‌دهند؛ به‌جای اجرای دستی فایل‌های compose، یک پنل مدیریت برنامه‌ها را برای شما بر عهده می‌گیرد.

• Cloudron آرزوی «کاش این با یک کلیک نصب می‌شد» را با یک فروشگاه برنامه حرفه‌ای، TLS خودکار و قابلیت پشتیبان‌گیری داخلی محقق می‌کند. حداقل 2 گیگابایت رم در نظر بگیرید، اما 4 گیگابایت برای عملکرد راحت‌تر توصیه می‌شود. نکته مهم: این ابزار بسیار سخت‌گیرانه عمل می‌کند و می‌خواهد کنترل کامل سرور را در دست بگیرد؛ همچنین فقط تا 2 برنامه رایگان است و پس از آن یک محصول پولی محسوب می‌شود.
• CasaOS یک داشبورد نامنظم هوم‌لب را با یک شبکه برنامه‌های کاربرپسند جایگزین می‌کند که رایگان و سبک است. برای خودِ CasaOS حدود 150 تا 300 مگابایت رم در نظر بگیرید. نکته مهم: این ابزار برای شبکه‌های خانگی قابل‌اعتماد طراحی شده و برای اینترنت عمومی ایمن‌سازی نشده است؛ آن را مستقیماً در معرض اینترنت قرار ندهید و فقط از طریق WireGuard به آن دسترسی داشته باشید.
• Coolify جایگزینی برای Heroku، Vercel و Netlify است که امکان استقرار با git-push، مدیریت دیتابیس‌ها و پیش‌نمایش پروژه‌ها را روی سرور شخصی شما فراهم می‌کند. حداقل 2 گیگابایت رم در نظر بگیرید. نکته مهم: این پروژه جوان است و با سرعت زیادی توسعه می‌یابد؛ بنابراین نسخه‌ها را ثابت (pin) کنید و پیش از ارتقا، release notes را مطالعه کنید. مطلب مقایسه Cloudron در برابر CasaOS و Coolify بررسی می‌کند که کدام‌یک از این سه گزینه برای نیاز شما مناسب‌تر است.

ابزارهای توسعه‌دهنده و بهره‌وری

• Gitea (یا Forgejo) جایگزینی برای GitHub جهت مدیریت مخازن خصوصی، ثبت مشکلات (issues) و CI است. حدود 200 تا 500 مگابایت رم در نظر بگیرید. نکته مهم: Forgejo انشعاب (fork) تحت مدیریت جامعه کاربری Gitea است و امروزه بسیاری آن را توصیه می‌کنند؛ هر دو عالی هستند، اما یکی را انتخاب کنید و حتماً از مخازن و دیتابیس با هم نسخه پشتیبان تهیه کنید؛ پشتیبان‌گیری از مخزن بدون دیتابیس باعث از دست رفتن تمام مشکلات و درخواست‌های ادغام (pull requests) می‌شود.
• Paperless-ngx جایگزینی برای فایل‌های بایگانی و اسکنرهای گران‌قیمت است که با انجام OCR روی همه اسناد، آن‌ها را قابل جستجو می‌کند. حدود 1 گیگابایت رم در نظر بگیرید؛ در حین عملیات OCR، مصرف CPU افزایش می‌یابد. نکته مهم: کیفیت نتایج OCR به کیفیت اسکن‌های شما بستگی دارد و پردازش مجدد آرشیوهای بزرگ زمان‌بر است؛ پیش از وارد کردن انبوه اسناد ده سال گذشته، تنظیمات آن را بهینه کنید.
• Actual Budget جایگزینی برای YNAB و Mint جهت بودجه‌بندی به روش پاکتی (envelope budgeting) به‌صورت سریع، محلی و خصوصی است. حدود 150 مگابایت رم در نظر بگیرید. نکته مهم: همگام‌سازی خودکار با بانک یک افزونه جداگانه با تنظیمات خاص خود است، بنابراین در حالت پیش‌فرض باید تراکنش‌ها را به‌صورت دستی وارد کنید.
• FreshRSS جایگزینی برای Feedly و Google Reader قدیمی است؛ یک خبرخوان سریع و خصوصی که اپلیکیشن‌های موبایل نیز دارد. حدود 150 مگابایت رم در نظر بگیرید. نکته مهم: به‌روزرسانی فیدها را بر اساس cron تنظیم کنید، در غیر این صورت فیدها فقط زمانی به‌روز می‌شوند که صفحه را باز کنید.
• BookStack جایگزینی برای Notion و Confluence جهت مستندسازی است که محتوا را در قالب قفسه‌ها، کتاب‌ها و صفحات سازمان‌دهی می‌کند. حدود 500 مگابایت رم برای PHP و MySQL در نظر بگیرید. نکته مهم: این ابزار محتوا را با ساختار خاص خود دسته‌بندی می‌کند نه به‌صورت یادداشت‌های آزاد؛ برخی این ویژگی را می‌پسندند و برخی آن را محدودکننده می‌دانند؛ پیش از انتقال کل ویکی خود، ابتدا آن را تست کنید.
• Home Assistant جایگزینی برای SmartThings و ده‌ها اپلیکیشن اختصاصی است که خانه هوشمند شما را به‌صورت محلی یکپارچه می‌کند. حدود 1 گیگابایت رم در نظر بگیرید. نکته مهم: بخش بزرگی از قابلیت‌های آن نیازمند دسترسی شبکه محلی به دستگاه‌های شماست، بنابراین اجرای آن روی سخت‌افزار خانگی بسیار منطقی‌تر از VPS راه دور است؛ اگر مجبور هستید، داشبورد را از راه دور اجرا کرده و از طریق bridge متصل شوید.

یک نصب نمونه

برای ملموس‌تر شدن موضوع، در اینجا ساختار کلی یک سرویس self-host آورده شده است: یک فایل compose، یک گواهی معتبر و یک نسخه پشتیبان. این مثال مربوط به Uptime Kuma است، اما تمام برنامه‌های موجود در لیست از الگوی مشابهی پیروی می‌کنند.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
    restart: unless-stopped

docker compose up -d
docker compose logs -f

به 127.0.0.1: توجه کنید؛ برنامه فقط روی localhost گوش می‌دهد و یک reverse proxy مانند Traefik یا nginx عملیات TLS termination را در مقابل آن انجام می‌دهد. اتصال مستقیم به 0.0.0.0:3001 همان روشی است که باعث می‌شود کاربران به‌طور تصادفی یک پنل مدیریتی رمزنگاری‌نشده را در دسترس کل اینترنت قرار دهند.

چه مواردی را (هنوز) نباید خودمیزبانی (self-host) کرد

• ایمیل. این صادقانه‌ترین توصیه است. پورت خروجی 25 توسط اکثر ارائه‌دهندگان VPS مسدود شده است، شما با Connection timed out از سمت telnet aspmx.l.google.com 25 مواجه خواهید شد و هیچ راهی برای رفع آن وجود ندارد، چرا که این یک سیاست کاری است. حتی اگر پورت 25 باز باشد، یک IP جدید بدون اعتبار (reputation)، رکورد PTR، SPF، DKIM و DMARC باعث می‌شود ایمیل‌های شما در پوشه اسپم قرار بگیرند یا مستقیماً رد شوند. این یک کار واقعی و مداوم است، نه یک پروژه آخر هفته. اگر بر انجام آن اصرار دارید، با آگاهی کامل از راهنمای self-hosted email with Mailcow استفاده کنید و انتظار داشته باشید که ماه‌ها برای حفظ قابلیت تحویل (deliverability) ایمیل‌ها وقت بگذارید.
• هر چیزی که نمی‌توانید به‌طور مطمئن از آن نسخه پشتیبان تهیه و بازیابی کنید. اگر هرگز یک بازیابی آزمایشی انجام نداده‌اید، شما نسخه پشتیبان ندارید، بلکه فقط امیدوارید که داده‌ها حفظ شوند. تا زمانی که فرآیند بازیابی اثبات نشده است، داده‌های غیرقابل جایگزین، تنها نسخه عکس‌های خود یا حساب‌های کاربری‌تان را روی یک سرویس قرار ندهید.
• تنها نسخه از یک وابستگی حیاتی. یک سرور DNS خودمیزبانی‌شده که با از کار افتادن آن، اینترنت کل شبکه شما قطع می‌شود، پروژه اول بدی است. همیشه یک جایگزین (fallback) بالادستی داشته باشید.
• سیستم‌های ایمنی بلادرنگ. هشدارهای خانگی، هشدارهای پزشکی و هر چیزی که در آن 5 دقیقه قطعی، یک مشکل جدی محسوب می‌شود، نباید روی یک سرور سرگرمی که یکشنبه‌شب‌ها آن را ارتقا می‌دهید، اجرا شود.

نحوه انتخاب اولین سرویس و دو اصل غیرقابل‌مذاکره

سرویسی را انتخاب کنید که هزینه‌ای که بابت آن ناراضی هستید را حذف کند یا نگرانی امنیتی که واقعاً حس می‌کنید را برطرف سازد. در عمل، بهترین گزینه‌ها برای اولین نصب، Vaultwarden و Uptime Kuma هستند: هر دو بسیار سبک‌اند، بلافاصله کاربردی هستند و اگر اشتباهی مرتکب شوید، خطاهای احتمالی را می‌بخشند. پیش از اضافه کردن سرویس دوم، یک سرویس را به‌طور کامل از ابتدا تا انتها راه‌اندازی کنید؛ شامل نصب، گواهی، پشتیبان‌گیری و تست بازیابی. مهارتی که در حال کسب آن هستید، عملیات (operations) است، نه صرفاً کلیک کردن روی دکمه نصب.

دو مورد در تمامی سرویس‌های ذکر شده در بالا غیرقابل‌مذاکره هستند و هیچ استثنایی ندارند:

1. استفاده از TLS برای هر سرویس عمومی. سرویسی که با IP خام و بدون رمزنگاری (plaintext) در دسترس باشد، یک نسخه نمایشی است، نه یک استقرار واقعی. با استفاده از Certbot and Let's Encrypt on nginx یک گواهی معتبر روی آن قرار دهید یا اجازه دهید Traefik این کار را به‌صورت خودکار انجام دهد. سپس ورودی اصلی را با Fail2ban for SSH on Ubuntu 24.04 ایمن کنید.
2. پشتیبان‌گیری‌هایی که واقعاً بازیابی کرده‌اید. یک فرآیند خودکار برای dump شبانه، شامل دیتابیس و حجم داده‌ها (data volume) ایجاد کنید، آن را به خارج از سرور بفرستید و ماهی یک‌بار آن را روی یک VPS موقت بازیابی کنید تا از صحت آن مطمئن شوید. روزی که دیسک شما از کار می‌افتد، بدترین زمان برای فهمیدن این است که فایل پشتیبان خالی بوده است.

اگر این دو مورد را به‌درستی انجام دهید، self-hosting لذت‌بخش خواهد بود. در غیر این صورت، تنها در حال شمارش معکوس برای بروز مشکل هستید.

گزینه‌ها از موارد کاربردی تا عجیب‌وغریب متغیرند؛ از یک Minecraft server on a VPS خانوادگی گرفته تا، اگر به داستان‌های عبرت‌آموز علاقه دارید، the world's least efficient datacenter.

FAQ

برای شروع، چه چیزی را باید روی سرور شخصی میزبانی کنم؟

Vaultwarden. یک مدیریت‌کننده رمز عبور، استفاده روزانه دارد، جایگزین اشتراک‌های پولی می‌شود و شما را وادار می‌کند کل چرخه کاری، Docker، یک reverse proxy، گواهی‌های TLS و پشتیبان‌گیری را یاد بگیرید. این برنامه آن‌قدر کوچک است که اگر آن را خراب کردید، در کمتر از 10 دقیقه می‌توانید دوباره آن را راه‌اندازی کنید. Uptime Kuma گزینه دوم بسیار خوبی است تا پیش از کاربران، از قطعی سرویس‌ها مطلع شوید.

واقعاً به چه میزان منابع VPS نیاز دارم؟

برای یک برنامه کوچک، 1 گیگابایت رم کافی است. برای داشتن یک سرور راحت که بتوانید چندین سرویس را روی آن اجرا کنید، 4 گیگابایت رم را هدف قرار دهید. در سطح 2 گیگابایت، کاربران اغلب با مشکل کشته‌شدن بی‌سروصدای کانتینرها به دلیل کمبود حافظه (OOM) مواجه می‌شوند و نمی‌توانند علت آن را پیدا کنند. رم تقریباً همیشه محدودکننده اصلی است؛ فضای دیسک را متناسب با داده‌هایی که قصد ذخیره دارید انتخاب کنید و در نظر داشته باشید که برنامه‌هایی مثل Immich، Ollama و هر چیزی که دیتابیس بزرگی دارد، بیشترین مصرف را از هر دو منبع خواهند داشت.

چه چیزی را نباید روی سرور شخصی میزبانی کنم؟

اول از همه، ایمیل. پورت خروجی 25 توسط اکثر ارائه‌دهندگان مسدود است و تضمین رسیدن ایمیل‌ها به مقصد، یک نبرد تمام‌وقتی است. پس از آن، هر چیزی که نمی‌توانید به‌طور مطمئن از آن پشتیبان بگیرید و بازیابی کنید، و هر نقطه شکست واحدی که خرابی آن آسیب جدی وارد می‌کند؛ مانند یک سرور DNS بدون جایگزین یا سیستم‌های ایمنی خانه. هر چیز دیگری در این لیست برای میزبانی مناسب است.

آیا برای همه این‌ها به Docker نیاز دارم؟

خیر، اما استفاده از آن توصیه می‌شود. هر برنامه‌ای در این لیست یک Docker image دارد و Docker نصب تمیز، حذف کامل، تثبیت نسخه (version pinning) و قابلیت انتقال به میزبان جدید را برای شما فراهم می‌کند. اگر ترجیح می‌دهید، چند برنامه (مانند WireGuard یا Zabbix) را می‌توان به‌صورت native با استفاده از apt نیز نصب کرد. وقتی یک فایل compose را یاد بگیرید، کار با بقیه آن‌ها را هم بلد خواهید بود؛ به همین دلیل است که کل این لیست قابل‌فهم می‌شود.

چگونه امنیت همه این‌ها را حفظ کنم؟

چهار عادت، اکثر موارد امنیتی را پوشش می‌دهد: برای همه سرویس‌ها از TLS استفاده کنید، دسترسی SSH را فقط با کلید محدود کنید و از Fail2ban برای مسدودسازی حملات brute-force بهره ببرید، فقط پورت‌هایی که واقعاً نیاز دارید را در معرض اینترنت قرار دهید و به بقیه سرویس‌ها از طریق WireGuard VPN متصل شوید، و به‌طور مرتب سیستم را به‌روزرسانی کنید؛ در حین به‌روزرسانی، release notes را بخوانید تا ارتقای نسخه شما را غافلگیر نکند. پشتیبان‌گیری عادت پنجم است؛ این راهکار بازیابی شما در زمانی است که اشتباهی از سد چهار مورد اول عبور کند.