Hacker News Digest

Cloud in a Bottle — это открытая платформа для личного облака, которая делает самохостинг простым и приятным, как использование смартфона. Она запускает веб-приложения в изолированных rootless-контейнерах на Ubuntu-машине, обеспечивая безопасность и минимальные изменения в существующем ПО. В отличие от простых хостеров контейнеров вроде Coolify, Cloud in a Bottle предоставляет интегрированную платформу: единый вход, общий доступ к данным между приложениями и единый дашборд для управления. Цель — создать ощущение «облачного смартфона», где установка и использование приложений так же просты, как в закрытых сервисах, но без слежки, рекламы и привязки к корпорациям.

Платформа включает curated каталог приложений с высоким порогом качества, хотя сейчас он небольшой и растёт еженедельно. Управление доступно через веб-интерфейс, поддерживается бесконтактный вход во все приложения после авторизации, а также механизмы безопасного обмена данными между ними. Проект полностью открыт, без телеметрии, и может быть развёрнут самостоятельно на VPS, локальном железе или виртуальной машине. Также предлагается управляемый вариант от компании Imbue с бесплатным кредитом — он использует тот же код и служит бизнес-моделью для поддержки open-source версии. Авторы видят в Cloud in a Bottle способ вернуть цифровую суверенность пользователям и стимулировать создание удобного открытого ПО для широкой аудитории, а не только для технических энтузиастов.

Самохостинг остаётся сложным из-за резервного копирования, доступа к белым IP и доменам, а также долгосрочной поддержки — даже при упрощённой установке пользователи не справляются дольше 3–4 лет из-за износа оборудования и энтропии. Потеря данных без надёжного восстановления — главная причина отказа от проектов; многие не хотят управлять бэкапами вручную, нужен автоматизированный механизм. Без двух машин и репликации самохостинг не решает проблему отказоустойчивости. Совет из прода: каждый сервис должен иметь отдельный sidecar-бэкап, иначе координация между компонентами (например, в Immich) становится неподъёмной. Авторитетный DNS на порту 53 мешает использовать Cloudflare и CDN, что критично для пользователей, заботящихся о безопасности. Ограничения провайдеров и бюрократия при получении белого IP и домена остаются барьером. Пользователи с 2 ГБ ОЗУ и 1–2 ядрами сталкиваются с нестабильностью при запуске нескольких сервисов на одном VPS. Проект теряет уникальность: Cloudron, SelfPrivacy, FreedomBox, Proxmox + community-scripts.org уже предлагают аналогичные функции. Отсутствие Home Assistant и Immich в каталоге приложений — существенный недостаток. Многие предпочитают Tailscale Aperture и exe.dev за простоту подключения и интеграцию с AI, а не изолированные контейнеры. AI-агенты уже помогают в настройке и диагностике, делая самохостинг доступнее для нетехнических пользователей. Для массового принятия нужна мобильная версия с настройкой домена и оплатой с телефона, но это конфликтует с правилами магазинов приложений. Отдельно: часть пользователей обвиняет авторов в спаме в репозиториях без раскрытия связи с проектом, что ставит под сомнение этичность продвижения.

Herdr — инструмент для управления CLI-агентами в терминале — начался как личный проект одного разработчика, который устал от сложных решений и решил создать простой, встроенный runtime. Он построил систему, где агенты работают в терминальных сессиях, сохраняют состояние, работают часами и даже днями, а их управление привязано к проектам, а не к отдельным процессам. Ключевая идея — агенты должны работать где угодно и оставаться доступными: через SSH, на VPS, даже с телефона. TUI-интерфейс стал основным инструментом, но его сила — в открытости: за месяц после запуска маркетплейса появилось более 500 сторонних плагинов — от Raycast до Stream Deck и iOS-приложений — все без участия автора.

Herdr набрал 25 тыс. звёзд и 340 тыс. скачиваний, и один человек больше не справлялся. Проект вступил в Y Combinator, но runtime останется открытым и бесплатным — лицензия сменилась с AGPL на Apache-2.0. Цель — не расширять ядро, а делать его надёжным, быстрым и легко расширяемым. В будущем планируется соединить разрозненные среды (лэптоп, VPS, санбоксы) в единую сеть, но без лишних функций: ядро останется минималистичным, а всё остальное — через экосистему плагинов. Главное — сохранить лёгкость, которую любят пользователи.

Тред дополняет статью опытом использования Herdr, опасениями по поводу влияния венчурного капитала на открытый проект и его коммерциализацией, а также обсуждением альтернатив — zmx.sh, zellij и tmux. Пользователи признают Herdr полезным для управления CLI-агентами в терминале, но расходятся во мнениях: одни считают, что венчурное финансирование ухудшит инструмент, другие — что улучшит. Рекомендуется рассмотреть альтернативы на случай ухудшения качества после инвестиций.

Автор сократил свои расходы на облачные услуги в 10 раз, переведя все проекты с AWS на самостоятельное хостинг, при этом улучшив производительность в 2 раза. Его месячный счет AWS снизился с $1,400 до менее $120, а инфраструктура стала мощнее. Автор утверждает, что страх перед управлением серверами обходится компаниям в 10 раз дороже, чем необходимо.

Многие разработчики в индустрии облаков заинтересованы в сохранении компаний на облачных платформах, так как их зарплаты зависят от сложности инфраструктуры. Облачные инженеры и DevOps специалисты не чувствуют финансовой боли от переплат, так как тратят чужие деньги, и заинтересованы в поддержании vendor lock-in.

Перейдя на Hetzner, автор получил доступ к серверам с 80 ядрами менее чем за $190 в месяц, в то время как аналогичные экземпляры в AWS стоят $2,500-$3,500 (в 13-18 раз дороже). Даже с резервированием экземпляров AWS остается в 7 раз дороже. Для небольших проектов доступны VPS с 8 ядрами и 32 ГБ ОЗУ за $50 в месяц.

• Обсуждение в основном свелось к тому, что для большинства проектов хостинг в облаке (AWS, GCP, Azure) в 2024 году оказывается дороже, чем аренда bare-metal в Hetzner/OVH, и что это не всегда оправдано.
• Участники споров подчеркнули, что «облако» всё ещё полезно для MVP, стартапов и сценариев с непредсказуемым трафиком, но при этом критикуют его стоимость для устойчивых рабочих нагрузок.
• Несколько человек упомянули, что большие компании могут позволить себе облако, потому что у них есть команды и бюджет на инфраструктуру и DevOps, тогда как мелкий бизнес и индивидуальные разработчики вынуждены искать более дешёвые решения.
• Также было отмечено, что важно различать «облако» как способ разработки (CI/CD, managed services) и как способ хостинга (IaaS), и что первое может быть дешевле, чем второе.

Идеалист.орг удалось сократить расходы на хостинг с $3000 в месяц на Heroku до всего $55 в месяц, используя альтернативное серверное решение. Это сокращение расходов более чем в 54 раза представляет значительную экономию для любой организации, особенно для некоммерческого проекта. Хотя детали миграции не предоставлены, такой резкий decrease в затратах демонстрирует потенциал для оптимизации инфраструктуры. Вероятно, организация перешла на более экономичную инфраструктуру, возможно, используя собственные серверы или более доступные облачные решения.

• Обсуждение показало, что стоимость облачных PaaS-платформ (Heroku и т.д.) в десятки раз превышает стоимость VPS с теми же характеристиками, что вызвало обсуждение альтернатив и самостоятельного хостинга.
• Участники обсуждали, что при переходе с Heroku на собственный VPS с использованием open-source PaaS вроде Dokku или Disco, можно существенно сократить расходы, но при этом придется взять на себя обязанности по обслуживанию сервера.
• Были упомянуты такие вещи, как использование zram для экономии RAM и earlyoom для предотвращения OOM, а также то, что Hetzner предлагает выгодные цены на серверы в США.
• Некоторые участники подчеркнули, что стоимость облачных платформ может быть оправдана удобством и отсутствием необходимости заниматься системным администрированием, особенно для небольших команд без выделенного DevOps-специалиста.
• Также было отмечено, что при использовании open-source PaaS на собственном сервере, пользователь сам отвечает за мониторинг, обновления и безопасность, что может быть неприемлемо для некоторых пользователей.

Автор делится детальным чеклистом по настройке защищённого VPS для self-hosting, основанным на личном опыте развёртывания. Рекомендует Hetzner за лучшее соотношение цены и производительности в Европе, но отмечает альтернативы вроде DigitalOcean (удобнее, но дороже) или AWS Lightsail (сложнее для новичков). Ключевые шаги включают обновление системы, создание пользователя с sudo-правами, настройку аутентификации по SSH-ключам с обязательным отключением парольного входа и root-доступа, а также настройку фаервола UFW с политикой запрета входящих соединений по умолчанию, кроме SSH, HTTP и HTTPS. Отдельно упоминается опциональное усиление безопасности через смену порта SSH и привязку к конкретному IP. Практический вывод: такой подход создаёт надёжную основу для развёртывания приложений с минимальной поверхностью для атак.

• Пользователи отмечают отсутствие подробного описания Coolify в статье, несмотря на его упоминание в заголовке.
• Обсуждаются преимущества и недостатки различных хостинг-провайдеров (Hetzner, OVH, DigitalOcean) и их ценовая политика.
• Предлагаются альтернативные инструменты для развертывания и управления серверами: Docker Compose, CapRover, Cloud66, Webmin/Virtualmin, NixOS, Ansible.
• Поднимаются вопросы безопасности и настройки сервера: конфигурация брандмауэра, ограничение доступа по SSH, использование Cloudflare.
• Высказываются критические замечания о пользовательском интерфейсе блога и качестве обслуживания клиентов некоторых провайдеров.