Hacker News Digest

Автор сократил свои расходы на облачные услуги в 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.
• Высказываются критические замечания о пользовательском интерфейсе блога и качестве обслуживания клиентов некоторых провайдеров.

Веб-сервер на одноразовой вейпе

Сервер, с которого вы читаете этот текст, работает на микроконтроллере внутри одноразового вейпа.
Внутри — чип PUYA C642F15 (на деле PY32F002B): Cortex-M0+ 24 МГц, 24 КБ флеш, 3 КБ ОЗУ.
Для выхода в сеть используется старый протокол SLIP: pyOCD перенаправляет semihosting-вызовы в telnet, socat делает из этого виртуальный tty, slattach поднимает интерфейс sl0.
IP-стек — uIP 0.9, пришлось подправить выравнивание структур и чексуммы.
Файловая система упакована прямо во флеш; веб-страница, которую вы сейчас читаете, весит меньше 3 КБ.
Питание — от самого вейпа: 3,7 В, 550 мА·ч, хватает на сутки бесперебойной работы.
Скорость 115200 бод, latency < 20 мс — быстрее, чем модем 90-х.

• Участники обсуждают «одноразовые» вейпы с USB-C и перезаряжаемой батареей: юридически их продают как «многоразовые», чтобы обойти запреты, хотя по факту выбрасываются после 1-3 циклов.
• Пост Богдана с анализом внутренностей вейпа (Cortex-M0+ за копейки) лёг от нагрузки, подняли зеркало на GitHub и копию в Wayback Machine.
• Шутки про «вейп-кластер» и «Android на вейпе» сменились идеей собирать выброшенные девайсы для самодельных проектов: кормушки, mesh-сети, добыча бесплатных микроконтроллеров.
• Спор о безопасности хостинга домашнего сервера: кто-то открывает порт, кто-то DMZ или VPS + Tailscale, главное — изолировать VLAN/контейнер.
• Пользователи признают зависимость от никотина и бессмысленность выбрасывания техники, но всё равно продолжают покупать.

• Унаследовал iPad 2 на iOS 9: тормоз и нет приложений.
• Спустились до iOS 6.1.3 через jailbreak + Legacy-iOS-Kit: летает, красиво.

Что делать:

• Cydia: iFile, iTransmission, f.lux, старые игры без IAP.
• Через SSH root-доступ: учимся хостингу.

План: запустить блог на iPad и вывести в интернет.

1. lighttpd из Cydia – весит мало.
2. Jekyll-сайт закинул по SCP – открывается в Wi-Fi.
3. Туннели:
   – localhost.run: старый SSH не принимает RSA, домены случайные, платные.
   – Свой VPS + autossh: OpenSSL 0.9.8 ≠ современные алгоритмы, отказ.
4. Порт-форвард: роутер пускает наружу 80-й на iPad; VPS проксирует nginx → домен.
5. Uptime 3 дня, греется, но работает: старый планшет = живой сервер.

• Пользователь поднял iPad 2 2012 г. как веб-сервер, но сайт быстро выдал 502-ошибку Cloudflare.
• Комментаторы жалуются: Apple прекращает поддержку, устройство нельзя поставить Linux, оно превращается в «электронный хлам».
• Обсуждаются jailbreak, UTM, iSH, Termux+X11, но все способы ограничены, частично «тетеринг» и требуют копаться в сомнительных инструкциях.
• Кто-то делает из старых панелей Home Assistant, кто-то — настенные часы, но батарея всё равно периодически садится даже от сети.
• Общий вывод: пока Apple официально не разрешит ставить альтернативные ОС, старые iPad остаются либо музейными экспонатами, либо выбросом.

LandChad.net учит запускать сайты, почту и чаты за пару часов и копейки.
Базовый курс (≈1 ч):

1. Домен
2. Сервер
3. DNS
4. Nginx
5. HTTPS (Certbot)

Свои сервисы: Alps (почта), Calibre (библиотека), Cgit, Coturn, Dnsmasq, DokuWiki, ejabberd, Fosspay, Git, Gitea, i2p, IRC, Jitsi, Matrix (Synapse/Dendrite), Monero, Mumble, Nextcloud, PeerTube, Pleroma, Prosody, Radicale, Rainloop, RSS-Bridge, SearXNG, Tor, Transmission, WireGuard, Yarr.

Почтовый курс (≈1 ч + 1 день на открытие портов):

1. SMTP
2. rDNS
3. DNS-записи
4. Входящая почта
5. Защита

Администрирование: Certbot, Cron, Gemini и др.

• Участники спорят, что название «landlord»/«landchad» некорректно: арендуя VPS и домен, ты всё равно арендатор, а не собственник.
• Многие хвалят сайт за простые гайды по самостоятельному хостингу, но отмечают, что материал рассчитан на «интернет-сантехников», а не новичков.
• Поднят вопрос о бесполезности собственного почтового сервера из-за попадания писем в спам; однако некоторые пишут, что у них всё работает без проблем.
• Ключевой пробел — почти нет информации о надёжных бэкапах и восстановлении.
• Упоминаются риски юридического преследования за несоблюдение регуляций и то, что мобильный интернет сместил фокус с «домашних» сайтов.

• Проблема цены: Heroku, контейнеры и serverless дорожают при росте проектов.
• Проблема админки: VPS дешёв, но требует обновлений и бекапов.

Решение

1. coreOS/Flatcar — минималистичная ОС, обновляется сама, ставится один раз.
2. Dokploy — open-source PaaS в контейнере: деплой из Git, БД, логи, оркестрация.
3. Итог: VPS-прайс + Heroku-удобство, независимость от облаков.

Когда не подходит: резкие пики нагрузки или совсем старт проекта — бери serverless или Heroku.

• Лицензия Dokploy вызывает вопросы; авторы обещают её переработать.
• Пользователи хвалят простоту и «Heroku-вайб», но жалуются на отсутствие удобного «pull latest», слабое управление секретами и эпизодические проблемы с деплоем.
• Часть аудитории предпочла Coolify (чуть богаче фичами) или старый добрый Dokku/Portainer.
• Для статических сайтов и CI по git-push многие используют Coolify как «домашний Netlify».
• Арм64 поддерживается; wildcard-домены и резервное копирование volume-ов приходится настраивать вручную.

• Цель: перенести все сервисы с VPS домой на Minisforum UM880 Plus (Ryzen 7 8840U, 32 ГБ ОЗУ).
• Задачи: безопасные эксперименты, изучение k3s → k8s/Talos, отказ от облаков.
• Угрозы: кража, выход железа, человеческий фактор.
• Меры: полное шифрование диска, автоматические бэкапы, восстановление по Ansible, Wake-on-LAN через KVM.

Подготовка хоста Proxmox

1. Чистая установка Debian 12 с LVM-on-LUKS, отдельный /boot на флешке.
2. Proxmox VE 8 ставится поверх Debian:
   • добавить репу pve-no-subscription;
   • после установки сломалась сеть — оказалось, ifupdown2 не ставится, надо ifupdown + ручной /etc/network/interfaces.
3. Bridge vmbr0 на основе enp3s0 для ВМ.

Автоматизация Ansible

• Плейбук proxmox.yml:
  • ставит ключи, репу, пакеты, настраивает сеть, отключает подписку.
• Запуск:

  ansible-playbook -i hosts.ini proxmox.yml -K
  

Итого: за час получаем переустанавливаемый, зашифрованный, готовый к ВМ кластер без облаков.

• Участники обсуждают, стоит ли вообще строить домашний сервер: кто-то считает это дорогим хобби и источником постоянных проблем, кто-то — отличным способом учиться и сохранять контроль над данными.
• Главные минусы: высокая стоимость электричества в ряде регионов, отсутствие ECC-памяти у дешёвых железок, риск отключения питания и необходимость ручного восстановления.
• Часть людей экономит на VPS и облаке, собирая NAS из подержанных Dell Wyse 5070 или Minisforum-мини-ПК; другие предпочитают б/у серверные Xeon-ы за расширяемость.
• Безопасность и надёжность: кто-то ставит UPS и даже солнечные панели, кто-то сознательно принимает простои и использует WireGuard для удалённого включения.
• Подводный итог: если цель — учёба и полный контроль, хоумлаб «свой»; если нужен 100 % uptime и минимум времени — дешевле и проще взять облако или VPS.