بهترین برنامه‌های خودمیزبانی برای سال 2026: لیست 25 تایی

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

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

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

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

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

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 مواجه شدند، مرحله مربوط به گروه کاربری را نادیده گرفته‌اید یا شل جدیدی باز نکرده‌اید؛ از سیستم خارج شده و دوباره وارد شوید. اگر docker compose خروجی docker: 'compose' is not a docker command را برمی‌گرداند، شما نسخه قدیمی و مستقل (standalone) را دارید؛ اسکریپت بالا پلاگین مدرن Compose را نصب می‌کند که باید آن را به صورت docker compose (با فاصله، نه خط تیره) فراخوانی کنید.

سه واقعیت، شکلِ تمام موارد زیر را تعیین می‌کنند. نخست، رم محدودیت اصلی است، نه دیسک یا پردازنده. یک VPS با 1 گیگابایت رم فقط یک برنامه کوچک را اجرا می‌کند و نه بیشتر. 4 گیگابایت رم نقطه ایده‌آل برای سروری است که قرار است «چند سرویس را میزبانی کند». 2 گیگابایت رم وضعیت دشواری است که در آن کاربر تازه‌کار سرویس سوم را اضافه می‌کند، با خطای Out-Of-Memory مواجه می‌شود و هرگز نمی‌فهمد چرا کانتینر ناپدید شده است؛ sudo dmesg خط مربوط به Out of memory: Killed process را که توسط دیمون بلعیده شده است، نشان می‌دهد. دوم، هر سرویس عمومی به یک نام دامنه و گواهی‌نامه نیاز دارد؛ استفاده از IP خام فقط برای تست مناسب است و به محض اینکه بخواهید یک اپلیکیشن موبایل یا مرورگر به آن اعتماد کند، با مشکل مواجه می‌شوید. سوم، دو پورت نیمی از گزینه‌های شما را تعیین می‌کنند: پورت ورودی 80 باید برای چالش استاندارد گواهی HTTP-01 در دسترس باشد (چالش DNS-01 با اثبات مالکیت از طریق رکورد DNS این مرحله را دور می‌زند و زمانی که پورت 80 بسته است، بسیار کاربردی است) و پورت خروجی 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) بخش پرمصرف آن است و فضای دیسک مورد نیاز برابر با حجم کتابخانه شما به اضافه حدود 20 درصد برای تصاویر بندانگشتی (thumbnails) است. نکته مهم: Immich از زمان اولین نسخه پایدار خود یعنی v2.0.0 در اکتبر 2025 از نسخه‌سازی معنایی (semantic versioning) پیروی می‌کند که تغییرات ساختارشکن را به نسخه‌های اصلی (major) محدود می‌کند. از آنجایی که این پروژه اکنون به v3 رسیده است، هرگز کورکورانه از تگ latest استفاده نکنید، زیرا شما را مستقیماً به نسخه اصلی بعدی می‌برد؛ همیشه نسخه را ثابت (pin) کنید و پیش از هر ارتقا، یادداشت‌های انتشار (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 تنظیم کنید، زیرا توکن متنی ساده (plaintext) در فایل 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 است که با یک ابزار بصری برای ساخت گردش‌کار، کنترل کامل را به شما می‌دهد و هزینه بر اساس تعداد تسک ندارد. برای این سرویس 400 MB تا 1 GB رم در نظر بگیرید. نکته مهم: n8n اعتبارنامه‌های ذخیره‌شده را با کلیدی که در اولین اجرا تولید می‌کند، رمزنگاری می‌کند. اگر این کلید را گم کنید یا فراموش کنید N8N_ENCRYPTION_KEY را تنظیم کنید و اجازه دهید کلید دوباره تولید شود، تمام اعتبارنامه‌های ذخیره‌شده غیرقابل خواندن می‌شوند و باید دوباره آن‌ها را وارد کنید. راهنمای n8n خودمیزبان با HTTPS کلید را ثابت نگه می‌دارد و یک گواهی معتبر برای URLهای webhook قرار می‌دهد.
• Ollama جایگزینی برای اشتراک ChatGPT جهت استنتاج محلی و خصوصی LLM است. بودجه رم را بر اساس مدل تعیین کنید: یک مدل 7–8B به حدود 8 GB رم نیاز دارد و حجم آن روی دیسک به کوانتیزاسیون بستگی دارد؛ تقریباً 4 تا 5 GB برای دانلود معمول 4-bit و 13 GB یا بیشتر برای نسخه با دقت کامل fp16. نکته مهم: روی یک VPS که فقط CPU دارد، استنتاج صادقانه اما کند است؛ به جای پاسخ‌های آنی که از APIهای میزبانی‌شده دریافت می‌کنید، سرعت را بر حسب کلمه در ثانیه در نظر بگیرید. بنابراین انتظارات خود را تنظیم کنید یا یک سرور مجهز به GPU اجاره کنید. راهنمای اجرای Ollama برای میزبانی محلی LLM اعداد واقع‌بینانه‌ای ارائه می‌دهد.

ارتباطات

• Rocket.Chat جایگزینی برای Slack در تیم‌ها است که امکاناتی نظیر رشته‌گفتگوها (threads)، تماس‌ها و یکپارچه‌سازی‌ها را فراهم می‌کند. حداقل 2 گیگابایت رم برای آن در نظر بگیرید، زیرا این سرویس روی MongoDB اجرا می‌شود که منبع‌مصرف اصلی آن است. نکته مهم: هر نسخه اصلی Rocket.Chat فقط از بازه محدودی از نسخه‌های MongoDB پشتیبانی می‌کند (نسخه 8.x به MongoDB 8.0 یا جدیدتر نیاز دارد، در حالی که 7.x روی 6.0 یا 7.0 اجرا می‌شد). دستورالعمل‌های ارتقای Rocket.Chat تأکید دارند که باید نسخه‌های اصلی را به ترتیب طی کنید؛ پریدن از یک نسخه به نسخه دیگر باعث می‌شود دیتابیس شما غیرقابل استفاده شود، بنابراین ارتقا را مرحله‌به‌مرحله انجام دهید. راهنمای Rocket.Chat با Docker Compose مسیر ارتقای نسخه‌ها را توضیح می‌دهد.
• Matrix (Synapse) جایگزینی برای Slack و Discord است که یک شبکه فدرال با رمزنگاری سرتاسری (end-to-end) ارائه می‌دهد که در آن مالکیت homeserver با خود شماست. 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 گیگابایت عملکرد بهتری دارد. نکته مهم: این ابزار بسیار سخت‌گیرانه عمل می‌کند و می‌خواهد کنترل کامل سرور را در دست بگیرد؛ در واقع، به‌جای اجرا به عنوان یک کانتینر، با اسکریپت اختصاصی cloudron-setup روی یک سرور تازه Ubuntu نصب می‌شود. مستندات آن استفاده از ARM، LXC، Docker و میزبان‌های OpenVZ را رد می‌کند. همچنین، این محصول فقط تا 2 برنامه رایگان است و پس از آن نیاز به پرداخت هزینه دارد.
• CasaOS یک داشبورد نامنظم هوم‌لب را با یک شبکه برنامه‌های کاربرپسند، رایگان و سبک جایگزین می‌کند. این ابزار با اسکریپت اختصاصی خود (curl -fsSL https://get.casaos.io | sudo bash) روی میزبان نصب می‌شود (نه به عنوان کانتینر) و سپس برنامه‌های شما را در Docker اجرا می‌کند. برای خود 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 است که بودجه‌بندی پاکتی سریع، محلی و خصوصی را فراهم می‌کند. حدود 150 مگابایت رم در نظر بگیرید. نکته مهم: همگام‌سازی خودکار بانکی در آن تعبیه شده اما اختیاری است؛ این قابلیت تنها پس از ثبت‌نام در یک ارائه‌دهنده منطقه‌ای مانند SimpleFIN Bridge یا Enable Banking و افزودن اعتبارنامه API شخصی کار می‌کند، بنابراین در حالت پیش‌فرض، تراکنش‌ها را باید به‌صورت دستی وارد کنید.
• 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 مواجه خواهید شد و هیچ راهی برای رفع آن از سمت شما وجود ندارد، چرا که این یک سیاست از سوی ارائه‌دهنده است. برخی ارائه‌دهندگان در صورت درخواست شما این محدودیت را برمی‌دارند (برای مثال AWS به شما اجازه می‌دهد درخواست حذف این محدودیت را ثبت کنید)، اما این یک درخواست است، نه یک تنظیم ساده. حتی با باز بودن پورت 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

اولین چیزی که باید خودمیزبانی (self-host) کنم چیست؟

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

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

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

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

ایمیل، در درجه اول؛ پورت خروجی 25 توسط اکثر ارائه‌دهندگان مسدود است و تضمین تحویل ایمیل (deliverability) یک نبرد تمام‌وقت است. پس از آن، هر چیزی که نمی‌توانید به‌طور مطمئن از آن پشتیبان بگیرید و بازیابی کنید، و هر نقطه شکست واحد (single point of failure) که خرابی آن آسیب واقعی وارد می‌کند، مانند یک سرور DNS بدون جایگزین یا سیستم‌های ایمنی خانه. هر چیز دیگری در این لیست برای خودمیزبانی مناسب است.

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

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

چگونه همه این‌ها را امن نگه دارم؟

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