سلف‌هاستینگ (Self-hosting) برای من با یک هدف ساده آغاز شد: کنترل بیشتر بر نرم‌افزارها و داده‌هایی که هر روز از آنها استفاده می‌کنم. اما پس از سال‌ها اجرای سرویس‌های شخصی به این نتیجه رسیدم که راه‌اندازی اولیه یک سرویس، آسان‌ترین بخش کار است و چالش اصلی، ادامه دادن با آن ساختار در گذر زمان است. برخی تصمیم‌ها که در ابتدا کاملاً منطقی به نظر می‌رسیدند، بعدها کارهای اضافی و بیهوده‌ای ایجاد کردند و برخی دیگر درس‌هایی بودند که هیچ راهنمای نصب و راه‌اندازی (Setup Guide) نمی‌توانست به من بیاموزد.
۱. سلف‌هاست کردن همه‌چیز، فقط به این دلیل که امکان‌پذیر بود
نخستین اشتباه من این بود که سلف‌هاستینگ را به یک رقابت برای انتقال هرچه بیشتر زندگی دیجیتالم به سرور شخصی تبدیل کردم. هر زمان نسخه‌ای متن‌باز (Open-source) از سرویسی که استفاده می‌کردم پیدا می‌کردم، می‌خواستم آن را آزمایش کنم. طولی نکشید که کانتینرهایی (Container) برای ابزارهایی ساختم که به‌ندرت از آنها استفاده می‌کردم، فقط به این دلیل که اجرایشان ممکن بود.
این رویکرد روی کاغذ چشمگیر به نظر می‌رسید، اما ساختار کاری من را بی‌دلیل پیچیده می‌کرد. هر سرویس جدید یک رابط کاربری تازه برای یادگیری و یک برنامه دیگر برای پیگیری اضافه می‌کرد. برخی ابزارها مشکلی را حل می‌کردند که اصلاً وجود نداشت و برخی دیگر صرفاً آزمایش‌هایی سرگرم‌کننده بودند که پس از چند هفته فراموش می‌شدند.
در نهایت پرسش خود را تغییر دادم؛ به‌جای «آیا می‌توانم این را سلف‌هاست کنم؟» پرسیدم «آیا واقعاً نیاز دارم این را سلف‌هاست کنم؟» همین تغییر کوچک باعث شد ساختاری بسیار سبک‌تر بسازم که واقعاً از آن استفاده می‌کنم، نه مجموعه‌ای از پروژه‌ها که تنها برای اثبات توانایی نگهداری می‌شوند.
۲. در معرض گذاشتن مستقیم سرویس‌ها روی اینترنت
به‌سختی آموختم که در دسترس بودن یک سرویس از هر نقطه، به معنای نیاز آن به افشای مستقیم روی اینترنت نیست. در آغاز، هر زمان به دسترسی از راه دور نیاز داشتم پورت‌ها (Port) را باز می‌کردم و چندان به این موضوع فکر نمی‌کردم که چه چیزهای دیگری نیز قابل دسترسی شده‌اند.
این روش راحتی زیادی داشت، اما نگرانی‌ها را نیز افزایش می‌داد. هر سرویس افشاشده به یک نقطه ورود بالقوه تبدیل می‌شد؛ به‌ویژه زمانی که داشبوردها و پنل‌های مدیریتی (Admin Panel) را اجرا می‌کردم که هرگز برای دسترسی عمومی طراحی نشده بودند.
در نهایت شیوه مدیریت دسترسی از راه دور را تغییر دادم. اکنون بیشتر سرویس‌هایم را پشت یک پروکسی معکوس (Reverse Proxy) همراه با پروتکل HTTPS قرار می‌دهم و برای هر چیزی که نیازی به دسترسی عمومی ندارد، از روش‌های دسترسی خصوصی استفاده می‌کنم. همچنین افشای رابط‌های مدیریتی را تنها به این دلیل که سریع‌ترین راه دسترسی بود، متوقف کردم. امروز دسترسی اینترنتی چیزی است که آگاهانه پیکربندی می‌کنم، نه گزینه‌ای که به‌صورت پیش‌فرض فعال می‌شود.
۳. پشتیبان‌گیری یک گزینه اختیاری نیست
مدتی با پشتیبان‌گیری (Backup) مانند کاری برخورد کردم که بعداً انجام خواهم داد. اگر سرویسی درست کار می‌کرد و همه فایل‌ها روی سرور بودند، تصور می‌کردم همه‌چیز تحت کنترل است. این نگرش زمانی تغییر کرد که با داده‌های ازدست‌رفته یا آسیب‌دیده روبه‌رو شدم و دریافتم یک مشکل کوچک با چه سرعتی می‌تواند به فاجعه‌ای بزرگ تبدیل شود.
اکنون پشتیبان‌گیری بخشی از فرایند راه‌اندازی هر سرویسی است که داده‌های مهم را ذخیره می‌کند. از فایل‌ها، پایگاه‌های داده (Database) و داده‌های برنامه‌ای که جایگزین کردنشان دشوار یا ناممکن است، نسخه پشتیبان تهیه می‌کنم و نسخه‌ها را در مکان‌های مختلف نگه می‌دارم، نه فقط روی همان ماشینی که سرویس‌ها را اجرا می‌کند.
مهم‌تر از همه، فرایند پشتیبان‌گیری را خودکار کرده‌ام؛ نمی‌خواهم به یادآوری خودم برای اجرای دستی نسخه پشتیبان هر چند روز یک‌بار وابسته باشم. سلف‌هاستینگ کنترل داده‌ها را به من می‌دهد، اما این کنترل تنها زمانی ارزشمند است که راهی مطمئن برای بازیابی آنها داشته باشم.
۴. به‌روزرسانی فوری همه‌چیز
پیش‌تر هر به‌روزرسانی موجود را چیزی می‌دانستم که باید بی‌درنگ نصب شود. هر بار داشبورد داکر (Docker) را باز می‌کردم و فهرستی از نسخه‌های جدید ایمیج (Image) می‌دیدم، چند سرویس را همزمان به‌روزرسانی می‌کردم. این کار راهی مناسب برای به‌روز نگه داشتن همه‌چیز به نظر می‌رسید، اما اغلب مشکلاتی غیرمنتظره ایجاد می‌کرد.
یک به‌روزرسانی می‌تواند نحوه کار یک برنامه را تغییر دهد، گزینه‌ای را حذف کند یا ناسازگاری (Compatibility Issue) با مؤلفه‌ای دیگر ایجاد کند. وقتی چند سرویس همزمان به‌روزرسانی می‌شوند، یافتن عامل اصلی مشکل بسیار دشوارتر می‌شود.
اکنون رویکردی آهسته‌تر در پیش گرفته‌ام. برای سرویس‌هایی که هر روز به آنها وابسته‌ام، پیش از به‌روزرسانی یادداشت‌های انتشار (Release Notes) را بررسی می‌کنم و از اعمال چند تغییر بزرگ به‌صورت همزمان پرهیز می‌کنم. همچنین به نسخه‌های جدید فرصت می‌دهم تا در محیط واقعی آزمایش شوند، به‌ویژه وقتی برنامه‌ای سابقه تغییرات شکننده (Breaking Changes) داشته باشد. به‌روز نگه داشتن همه‌چیز مهم است، اما دیگر «جدیدترین» را با «ضروری‌ترین» اشتباه نمی‌گیرم.
۵. مستندسازی، یک ضرورت انکارناپذیر
پیش‌تر تغییرات کوچک در ساختار کاری‌ام را یادداشت نمی‌کردم، چون مطمئن بودم آنها را به خاطر خواهم سپرد. این روش تا زمانی جواب داد که ماه‌ها بعد مجبور شدم مشکلی را عیب‌یابی (Troubleshoot) کنم. به فایل Compose یا پیکربندی نگاه می‌کردم و هیچ ایده‌ای نداشتم که چرا یک تنظیم خاص آنجا قرار دارد یا اگر آن را حذف کنم چه اتفاقی می‌افتد.
اکنون تغییراتی را که بدیهی نیستند مستند می‌کنم. یادداشت‌هایی درباره پیکربندی‌های سفارشی، پورت‌ها، مسیرهای پوشه، متغیرهای محیطی (Environment Variables) و هر مرحله غیرمعمول برای راه‌اندازی یک سرویس نگه می‌دارم. فایل‌های Compose را نیز سازمان‌دهی می‌کنم تا پیکربندی‌های مهم در پوشه‌های مختلف پراکنده نشوند.
این کار بیش از یک بار هنگام بازسازی یا تغییر یک سرویس نجاتم داده است. دیگر لازم نیست به حافظه تکیه کنم یا پست‌های قدیمی انجمن‌ها را دنبال کنم تا بفهمم چه کاری انجام داده بودم. سلف‌هاستینگ به‌خودی‌خود عیب‌یابی کافی دارد؛ نمی‌خواهم تصمیم‌های فراموش‌شده خودم به مشکلی تازه تبدیل شوند.
سلف‌هاستینگ با ساده‌سازی بهتر می‌شود
پس از سال‌ها اجرای سرویس‌های شخصی دریافته‌ام که سلف‌هاستینگ به معنای ساختن چشمگیرترین ساختار نیست، بلکه به معنای خلق چیزی است که به‌طور قابل‌اعتماد کار کند و مداوم توجه من را طلب نکند. اشتباهاتی که مرتکب شدم به من آموختند فراتر از راه‌اندازی اولیه فکر کنم و تلاش بلندمدت را در نظر بگیرم. اکنون تمرکزم بر آزمایش‌های تازه کمتر و بر ساختن محیطی بیشتر است که بتوانم با آسودگی در آن زندگی کنم.