Хоумлаб легко оценивать по количеству сервисов.
Сколько контейнеров. Сколько машин. Какие приложения подняты. Какая модель запущена локально.
Через время эти цифры перестают впечатлять. Гораздо важнее другое: пользуюсь ли я этим вообще и понимаю ли, как оно связано.
Сервис без сценария быстро становится мусором
Поднять приложение легко. Особенно через готовый compose-файл.
Первые полчаса всё выглядит интересно. Ты заходишь в интерфейс, меняешь настройки, кидаешь ссылку друзьям. Потом сервис месяц работает в фоне, а ты ни разу его не открываешь.
Таких проектов у меня тоже хватало.
Сейчас я стараюсь задавать более неприятный вопрос: что именно эта штука улучшит в моём обычном процессе?
Если ответа нет, возможно, её не нужно оставлять включённой.
Связи между частями системы важнее самих частей
Сайт стал полезнее, когда перестал быть отдельной страницей.
Заметки связались с проектами. Проекты — с работающими сервисами. Уведомления начали приходить в Matrix. Автоматизация стала обновлять материалы. Локальный ИИ получил доступ к инструментам и файлам.
По отдельности всё это обычные технологии. Интерес начинается между ними.
Именно в этих соединениях появляется ощущение личной цифровой среды.
Простые решения переживают сложные
Самые надёжные части системы обычно самые скучные.
Markdown-файлы. Статический сайт. Понятные каталоги. Контейнер с одной задачей. Небольшой скрипт, который можно прочитать целиком.
Сложная автоматизация впечатляет, пока не приходится возвращаться к ней через полгода.
Если я не могу быстро понять, почему сервис работает именно так, значит документации мало или решение слишком хитрое.
Self-hosting не освобождает от платформы — ты сам становишься платформой
Это звучит смешно, но по факту так и есть.
Хочешь независимость — получаешь обновления, резервные копии, журналы, сертификаты, диски и внезапные проблемы после перезапуска.
Крупный облачный сервис прячет эту работу. Домашняя инфраструктура показывает её полностью.
Иногда это раздражает. Иногда именно ради этого всё и затевалось.
Не всё нужно выводить наружу
Чем дольше работает система, тем больше в ней деталей.
Есть соблазн показать их все, чтобы статья выглядела технически убедительно. Но публичному тексту не нужна полная схема сети, логины, административные адреса и список каждого открытого порта.
Опыт интереснее инвентаризации.
Что сломалось. Почему я разделил роли. Как изменился процесс. Что оказалось лишним. Вот это полезно.
И наконец: законченной версии не будет
mrgnl.ru не станет однажды «готовым».
Какие-то сервисы исчезнут. Некоторые статьи устареют. Архитектура поменяется. Возможно, несколько проектов объединятся в один, а что-то я вообще вынесу наружу.
Раньше это ощущалось как недостаток. Сейчас — как основная идея.
Я не строю продукт с финальным релизом. Я выращиваю пространство, которое меняется вместе с моими интересами. Поэтому Digital Garden здесь подходит лучше любого идеального корпоративного сайта.
Техническая схема лежит в Архитектуре, безопасность — в правилах публикации, смысл — в Личном портале.