Почему я перестал устанавливать каждый новый софт и сократил свой локальный стек

Каждую неделю в сети появляется масса новых open-source и self-hosted приложений, которые обещают заменить подписки, а инструкции по установке всегда выглядят так, будто всё решается одной командой в терминале. Я решил поделиться опытом оптимизации своей локальной системы и рассказать, к чему приводит бесконтрольное развертывание контейнеров.

Для всех, кто пишет о технологиях или просто любит тестировать свежий софт, пройти мимо таких новинок непросто. В итоге на жестком диске накапливается бесконечное число контейнеров. Проблема заключается в том, что подобные программы редко приходят в одиночку — они тянут за собой ворох специфических настроек. Моя система разрослась до такой степени, что я перестал понимать назначение половины запущенных служб. В последние годы я стал гораздо разборчивее, и могу с уверенностью сказать: более простой и компактный стек напрямую повышает продуктивность.

Скрытые издержки постоянного тестирования новых программ

Работа с современным софтом для самостоятельного хостинга почти всегда начинается с Docker, но на этом дело не заканчивается. На ПК под управлением Windows это означает запуск Docker Desktop и ожидание, пока фоновые службы придут в готовность. Платформа Docker на Windows прогоняет процессы через WSL2 — полноценную виртуальную машину Linux, работающую прямо внутри операционной системы. Когда я попытался полностью вычистить Linux-компоненты с компьютера, выяснилось, что без них Docker просто перестает функционировать.

Эта виртуальная машина по умолчанию получает лишь часть системной оперативной памяти. Например, когда я пытался запустить Open Notebook с моделью Gemma 4 на машине с 8 ГБ RAM, процесс аварийно завершался из-за нехватки памяти. Подобные эксперименты отнимают массу времени, а на выходе получается далеко не самый удобный рабочий процесс. Кроме того, каждая утилита требует своего ритуала: создания отдельной папки и прописывания параметров в compose.yaml через текстовый редактор перед тем, как вообще браться за PowerShell.

Со временем ситуация не упрощается. Помню, как однажды я забыл пароль от Odysseus, и банальное удаление контейнеров не помогло сбросить доступы, так как файл авторизации хранился в системной папке на компьютере, которую пришлось искать вручную. Несмотря на многолетний опыт работы с локальным софтом, многие вещи до сих пор вызывают технические трудности или требуют глубокого погружения в документацию.

Избранные приложения, которые прошли жесткий отбор

Некоторые инструменты дались мне легко при настройке, другие потребовали больше усилий, но в итоге заняли постоянное место в рабочем процессе. Первой программой, которую я развернул самостоятельно много лет назад через управляемый хостинг Elestio, стал Penpot — тогда я еще с трудом представлял себе устройство контейнеров.

Запуск Penpot локально на собственном железе остается одной из самых сложных задач, поскольку система состоит из множества взаимодействующих сервисов, требующих базовых знаний Docker, DNS и прокси. Тем не менее, это мой основной инструмент для дизайна, поэтому затраченные усилия полностью оправданы для проектов, требующих полной конфиденциальности.

Excalidraw и OmniTools оказались гораздо проще в развертывании: для каждого из них достаточно одной команды Docker run, после чего инструмент сразу доступен в браузере. Официальный образ Excalidraw не содержит систем аналитики или трекинга, а локальная версия отлично подходит для личных зарисовок. OmniTools закрывает мои потребности в разделении и слиянии PDF-файлов после отказа от продуктов Adobe.

Это невероятно компактный образ весом всего 28 МБ, причем обработка файлов происходит прямо в браузере. Если бы мне пришлось рекомендовать всего один локальный инструмент, я бы выбрал именно OmniTools, так как он работает не только с PDF, но также обрабатывает JSON, изображения, тексты, видео и аудио.

SiYuan также работает в виде одиночного контейнера, где можно задать собственный код доступа для защиты заметок. По своей архитектуре это ближайший open-source аналог Obsidian с блочной структурой Markdown-редактора, позволяющий создавать ссылки на конкретные абзацы, а не только на целиком заметки.

Забавно, что моя система для работы с локальными языковыми моделями вовсе не использует контейнеры. LM Studio устанавливается как обычная программа, запускает модели Qwen 3.5 9B и Gemma 4 E4B на моей скромной видеокарте с 8 ГБ памяти, а ее локальный сервер служит точкой притяжения для остальных утилит. Такие проекты, как AnythingLLM и Cherry Studio, также представляют собой классические десктопные инсталляторы, не требующие сложных манипуляций.

Какие критерии важны для новых локальных приложений

Чтобы не погружаться в бесконечный цикл установки софта просто из любопытства, я выработал свод жестких вопросов, на которые приложение должно ответить перед созданием для него отдельного контейнера.

• Реально ли эта программа заменяет коммерческий сервис по подписке или избавляет от необходимости загружать файлы на сторонние серверы?
• Буду ли я действительно использовать этот инструмент на регулярной основе?
• Требуется ли для работы утилиты больше одного контейнера?

Если я продолжаю пользоваться старыми привычными аналогами, то держать контейнер дольше недели «на всякий случай» нет никакого смысла. Под такие критерии подошли Penpot, Siyuan и OmniTools. Практически все многоконтейнерные архитектуры отсеялись, и Penpot остался единственным исключением исключительно благодаря интенсивной дизайнерской работе.

Теперь список в моем Docker Desktop выглядит компактным, и я четко понимаю назначение каждого активного процесса без лишних фоновых служб вроде nginx, висящих мертвым грузом. Docker запускается исключительно тогда, когда это действительно необходимо для работы, а не расходует оперативную память в фоновом режиме.