Hacker News Digest

• DuckDB + S3 + WASM = браузер без бэкенда, но с потенциальными проблемами с памятью и стоимостью трафика.
• Пользователи спрашивают, где учиться таким техникам и как избежать OOM-крашей.
• Обсуждается, что S3 не так уж и дешёв при публичном доступе, а R2/Cloudflare и MinIO могут быть альтернативами.
• Появляется вопрос, как защититься от DDoS и нестабильности памяти в браузере.
• Участники делятся опытом, что DuckDB не всегда стабилен и требует тонкой настройки потоков и памяти, особенно при работе с большими данными.

Инженеры Nanit сэкономили $500,000 в год, создав собственную систему хранения N3 на Rust вместо использования AWS S3 для обработки видео. При тысячах загрузок в секунду, плата за запросы PutObject в S3 становилась основной статьей расходов, а минимальный период хранения в 24 часа правил out стоимость обработки, занимавшей всего 2 секунды.

N3 работает как in-memory landing zone, используя S3 только как буфер перегрузки. В исходной архитектуре камеры загружали видео чанками напрямую в S3 через presigned URL, после чего Lambda отправлял ключи в SQS FIFO очередь для обработки. Подход сохранил надёжность и строгую последовательность данных, но исключил плату за запросы на основном пути и сократил затраты на хранение.

• Стоимость S3 для короткоживущих файлов оказалась настолько высокой, что компания вместо него реализовала собственное in-memory хранилище, что позволило сэкономить $500k, но оставляет вопрос о том, что будет, если этот кэш упадёт.
• Обсуждение вылилось в критику концепции "serverless" архитектуры, где-то между линиями прочиталось, что сама архитектура была проблемой, а не решением.
• Участники обсуждения также подняли вопросы о приватности: камера в детской комнате передаёт аудио/видео в облако без шифрования, и кто-то может прослушивать ваш дом.
• Несколько комментаторов отметили, что вместо того, чтобы писать собственные сервисы, компании могли бы использовать существующие open-source решения, такие как MinIO или SeaweedFS, но при этом они также отметили, что даже эти решения не предоставляют той же степени удобства, что и делает S3.

В предоставленном тексте отсутствует содержимое самого issue #21647 "Docker release?" в репозитории minio/minio. Видна только навигационная структура GitHub без основного текста обсуждения. Для создания точного пересказа необходимо содержимое самого issue, включая описание проблемы, комментарии и любые детали, связанные с выпуском Docker-образа MinIO.

• MinIO прекращает публикацию готовых Docker-образов, что вызвало волну обсуждений о «rug pull» и ожиданиях от OSS-проектов.
• Участники обсуждают, что компания имеет право прекратить предоставлять бесплатные образы, но отсутствие предупреждения и альтернативы вызывает раздражение.
• Появились альтернативы в виде Garage и SeaweedFS, но у них есть свои ограничения.
• Некоторые участники подчеркивают, что OSS-проекты не обязаны предоставлять бинарники, но при этом они также напоминают, что и сообщество не обязано использовать именно этот проект, если он становится менее удобным.

Автор успешно развернул самодельный S3-совместимый сервер на 10 ТБ, используя б/у Framework-ноутбук без экрана и внешний JBOD-массив дисков. В качестве ПО выбраны ZFS для файловой системы и Garage S3 для объектного хранилища. Система стабильно работала автономно несколько месяцев, накопив 10 ТБ данных, а после перезагрузки и обновления Garage с v1 до v2 продолжила работу без сбоев.

Изначально возникали проблемы из-за хранения метаданных SQLite на JBOD, подключённом по USB, что вызывало ошибки ZFS при высокой нагрузке. Решением стало перенос метаданных на внутренний накопитель ноутбука. Проект демонстрирует, что даже нестандартные конфигурации могут быть надёжными при грамотной настройке.

• Обсуждаются альтернативы для создания домашнего NAS: использование старого ноутбука Framework в корпусе Cooler Master, Raspberry Pi с LVM2, Dell T30 с ZFS или готовые решения вроде Ubiquti.
• Сравниваются S3-совместимые объектные хранилища: Minio (критика из-за урезания бесплатной версии), Garage (простота настройки), Ceph (сложность, но гибкость) и SeaweedFS (меньше ручной конфигурации).
• Поднимаются вопросы о конфигурации ZFS (использование RAIDZ1, зеркал, отправка снапшотов) и её пригодности для USB-подключений, а также альтернативах вроде btrfs.
• Обсуждаются сценарии использования самодельного S3: бэкапы (включая гибридные сценарии с AWS Glacier), хранение логов, APK и медиатеки.
• Высказываются опасения по поводу надежности JBOD over USB, рисков потери данных при случайном отключении и отсутствия избыточности для метаданных.

Выпуск Litestream v0.5.0 знаменует переход от простого резервного копирования к эффективному восстановлению на определённый момент времени (PITR). Ключевое нововведение — формат LTX, позаимствованный из проекта LiteFS. Вместо потоковой передачи отдельных страниц базы данных Litestream теперь группирует изменения в рамках транзакций, что значительно ускоряет восстановление после сбоя.

Формат LTX решает проблему "горячих страниц" — например, при частых вставках в таблицу с автоинкрементным ключом, когда изменения концентрируются на ограниченном числе страниц. Раньше Litestream обрабатывал каждую страницу отдельно, что замедляло процесс. Теперь транзакции записываются целиком, сокращая количество операций ввода-вывода и ускоряя восстановление. Это делает SQLite ещё более надёжным решением для полноценных приложений.

• Пользователи обсуждают сложности развертывания SQLite-приложений на Fly.io, включая проблемы с инициализацией и миграцией баз данных.
• Litestream получает положительные отзывы за простоту использования, низкую стоимость репликации в S3 и надежность как инструмента для резервного копирования и репликации.
• Обсуждаются технические детали Litestream: поддержка S3-совместимых хранилищ, условные записи для реализации временных lease и планы по реализации read-replicas через VFS.
• Участники сравнивают Litestream с другими решениями (LiteFS, rsync, управляемые БД), отмечая его операционную простоту и отсутствие необходимости в отдельном сервере.
• Поднимаются вопросы о практическом применении SQLite и Litestream: восстановление после сбоев, работа с нестабильным интернетом, целесообразность использования против PostgreSQL/MySQL для разных сценариев.

AWS S3 достигает экстремальной производительности в 1 петабайт в секунду и 150 миллионов запросов в секунду, несмотря на использование медленных жёстких дисков (HDD). Ключ к масштабированию — дешёвая экономика HDD: их цена за байт упала в 6 миллиардов раз с поправкой на инфляцию, а ёмкость выросла в 7,2 миллиона раз. Однако физические ограничения — механическое движение считывающих головок и скорость вращения пластин (~7200 оборотов в минуту — держат IOPS на уровне всего ~120 на диск уже 30 лет.

Система компенсирует это массовым параллелизмом: десятки миллионов дисков работают вместе, распределяя нагрузку. S3 использует многопользовательскую архитектуру, обеспечивая высокую доступность и долговечность данных при низкой стоимости. Это инженерное чудо, превращающее медленные, но дёшевые компоненты в мощнейший бэкбон современного интернета.

• Обсуждается архитектура AWS S3, включая использование HDD для хранения данных и SSD для метаданных и кеширования, а также применение эратур-кодирования и шардинга для повышения надежности и производительности.
• Поднимается вопрос о том, как S3 достигает высокой пропускной способности благодаря массовому параллелизму миллионов дисков, что позволяет превысить производительность отдельного HDD.
• Участники обсуждают возможные альтернативы S3 для развертывания в homelab или частных облаках, такие как Ceph, MinIO, SeaweedFS, Garage и Gluster, отмечая их особенности и требования к железу.
• Затрагивается экономический аспект: несмотря на падение цен на HDD, стоимость S3 остается стабильной годами, что связывают с недостатком конкуренции и высокой рентабельностью для AWS.
• В комментариях уточняются технические детали, например, расчет среднего времени поиска на диске и использование различных схем шардинга, отличных от упомянутых в исходной статье.

Зачем и как мы сделали Vectroid

Почти все векторные БД заставляют выбирать: скорость, точность или цена. Мы решили, что жертвы не нужны, и собрали serverless-решение, где всё хорошо одновременно.

Ключевая идея:

• нагрузка скачет ⇒ ресурсы выделяем динамически;
• алгоритм HNSW жрёт память, но его можно «сплющить» квантованием и развернуть обратно при необходимости.

Что умеет Vectroid

• Поиск по HNSW: 90 % recall при 10 QPS и P99 = 34 мс (MS Marco, 138 M векторов).
• Индексация 1 M векторов в минуту, 1 B — за 48 мин.
• Записи становятся видны почти сразу после вставки.
• Масштаб до миллиардов векторов в одном пространстве.
• Пишущая и читающая части масштабируются отдельно, данные живут в GCS/S3, индексы подгружаются лениво и выгружаются при простое.

Архитектура
Два независимых микросервиса: ingest и query. Все слои (вставка, индекс, поиск) масштабируются отдельно, память экономится квантованием и покадровой выгрузкой.

Попробовать бесплатно — 100 ГБ индексов навсегда.

• Предложена идея «векторного движка» как лёгкой встраиваемой библиотеки для быстрого построения и поиска эмбеддингов, без переизобретения велосипеда в каждом продукте.
• Участники спорят о масштабируемости: 1 млрд 4096-мерных векторов теоретически невозможно держать в одной VRAM-карте (4 Т скаляров), но можно разбить на кластеры или сжать квантованием.
• Ключевой вызов — не алгоритм (HNSW/IVF), а распределённая архитектура: отдельное масштабирование записи и чтения, баланс цена-точность-латентность.
• Уже есть похожие open-source решения (USearch в ClickHouse, TurboPuffer), но новые SaaS-продукты (Vectroid и др.) обещают серверлесс, объектное хранилище и «редисо-подобный» кэш.
• Часть аудитории критикует закрытость кода и риск вендор-локина; стартапы отвечают, что opensource пока замедляет релизы, а вектора легко экспортировать.

• Palantir Gotham — платформа для госорганов, которая объединяет разрозненные базы (ДМВ, полиция, соцсети, камеры) в единую «интеллект-карту».
• Поиск по татуировке, статусу мигранта, номеру авто — за минуты вместо недель.
• ICE потратила >$200 млн, строя досье на миллионы: связи, передвижения, переписки.
• Результат: государство видит всё, гражданин — ничего.

• Palantir — это не уникальная технология, а «умные джойны» между SAP, S3, ArcGIS и прочими источниками, завёрнутые в удобные дашборды.
• Главный продукт — глобальная видимость: «покажи кластеры нелегалов» или «узкие места в строительстве».
• Критики считают компанию «цифровым СС»: работают на госзаказ, обходят конституционные ограничения, продают преследование и геноцид под соусом «аналитики».
• Данные берутся из государственных архивов и частных трекеров; третьи стороны (Google, Facebook, телекомы) дают доступ без судебных ордеров.
• Моральная ответственность снимается формулой «технология нейтральна», но сотрудники делают выбор, подписывая контракты на слежку.
• Акции растут на хайпе «ИИ для госструктур»; когда пузырь лопнет, бизнесу конец, считают скептики.

Spiral: Data 3.0
Новая эпоха — машины потребляют и выдают данные петабайтами.
Postgres и Lakehouse были рассчитаны на человека: входы и выходы — килобайты.
AI-хранилище должно отдавать 4 млн изображений в секунду, иначе H100 простаивает 70 % времени.

Почему ломается стек
Parquet → Arrow → tensors → кэш → GPU: 5 лишних шагов, 10× память, 55 ч сети на 1 с GPU-нагрузки.
Мелкие файлы (100 КБ) убивают S3, эмбеддинги и картинки застревают в «мертвой зоне» 1 КБ–25 МБ.

Побочные эффекты

1. Цена/скорость: инженеры крутят ETL вместо обучения.
2. Безопасность: в угони скорости открывают S3 и сливают базы через MCP-коннекторы. Долг превращается в 10× технический долг.

Spiral = хранилище для машин

• Потоковое чтение петабайтов без распаковки.
• Поиск, сэмплы, случайные чтения за миллисекунды.
• Модель доступа «по-умолчанию закрыто» → безопасность не тормозит.

Результат
GPU загружен, инженеры пишут модели, а не пайплайны.

• Сайт красивый, но без технических деталей: это пресс-релиз нового формата Vortex и СУБД Spiral, а не продукт.
• Vortex — колонковый формат «для эры ИИ», обещает прямую разгрузку из S3 в GPU, минуя CPU и сетевые задержки.
• Критика: нет цифр, нет сравнений с Parquet/Lance/Delta, много маркетинга («AI-scale», 22 млн $ сид-раунда) и мало кода.
• Потенциальная польза — ускорение OLAP-пайплайнов обучения моделей, но вопросы к транзакциям, изменяемости и реальному бенчмарку остаются.

• tarsnap — «бэкапы для параноиков»; CLI как tar, предоплата, анонимность.
• cron-совместим, мегабайты «ценных данных» → $5 хватит на 1000+ лет.
• калькулятор стоимости: hiandrewquinn.github.io/tarsnap-calculator

• Пользователи массово уходят из Tarsnap: сервис в 50–250 раз дороже Restic/Borg + S3/Glacier/Backblaze (≈$250/ТБ против $3–8/ТБ).
• Скорость восстановления остаётся низкой (≈100 Кб/с) и не улучшается годами.
• Нет API и нормального мониторинга расходов/остатка кредита; приходится вручную следить через браузер.
• Альтернативы (Restic, Borg, Duplicacy) дают те же дедупликацию и шифрование, но на любом S3-подобном хранилище.
• Tarsnap подходит лишь для совсем маленьких объёмов, где важны prepaid и write-only ключи; для всего остального считают его «дорогим реликтом».

Сборник коротких серверлес-кошмаров

• $1189 – Webflow снял за месяц вместо $69.
• $100 000 – DoS на игровом сайте → счёт за Firebase за сутки.
• $738 – Vercel Pro + лимит $120 ≠ защита от «сюрприза».
• $70 000 – Проснулся с таким счётом за Firebase при тарифе $50.
• $22 640 – BigQuery на публичных данных.
• $250/мес – 9 тыс. просмотров в Framer.
• $1274 – AI Devin случайно устроил ддос в PostHog.
• $530 – Платный PostHog после нулевого периода.
• $384 – Документация на Mintlify.
• $103 – AWS Free Tier ловушка.
• $96 281 – Vercel: «я просто молчу».
• $120 000 – Cloudflare выключает сайт, требуя деньги за сутки.
• $1301 – Пустой приватный S3 + ддос.
• $11 000 – Mailgun во время атаки.
• $104 500 – Письмо от Netlify «переплата».
• $23 000 – Спам-атака на EchoFox в Vercel.
• $3000 – Тестовый деплой в Vercel.
• $620 – Sitemap.txt сожрал трафик.
• $72 000 – Тест Firebase + Cloud Run чуть не разорил.

Хочешь поделиться своим счётом-ужасом — пиши в твиттере или PR на GitHub.

• Пользователи делятся историями о «серверлес-ужасах» — внезапных счетах за десятки и сотни тысяч долларов из-за DDoS, ошибок в конфигурации или забытого ресурса.
• Критика сосредоточена не на технологии serverless, а на модели оплаты «плати за использование» без жёстких потолков: бюджет — лишь уведомление, а не отключение.
• Многие считают, что провайдеры могли бы автоматически отключать сервис при превышении лимита, но не делают этого, теряя деньги на «ошибках» новичков.
• Участники советуют: ставить rate-limit, использовать VPS с фиксированной ценой, поднимать bare-metal или хотя бы включать billing-alerts и «пауz-лимиты» вроде Vercel.
• Поддержка AWS/GCP/Azure часто прощает счета после публичных твитов, но это выживший эффект: официальной политики нет, и никто не гарантирует прощение.

Предупреждение: это сатира, не используйте в проде. Читая, вы клянётесь не повторять описанное.

Проблема

Managed NAT Gateway в AWS тарифицирует исходящий трафик по 0,07 $/ГБ и убивает стартапы счетами за облако.

Решение

Вместо него для веб-хуков можно:

• поднять exit-ноду Tailscale с публичным IP;
• привязать её к той же VPC;
• получить шифрование и экономию до 700 %.
  Это единственный безопасный фрагмент статьи.

---

S3 как очередь

AWS начинался с S3, SQS и EC2. S3 — это malloc() для облака:

• выделяете «память» (бакет);
• кладёте туда объекты любой длины;
• освобождаете, когда надоедает.

Аналогия с C: malloc() → указатель, free() → удаление объекта. Ошибка выделения → ENOMEM, дальше — краш.

---

Как превратить S3 в очередь

1. Писать сообщения в виде объектов с ключом queue/<uuid>.json.
2. Читать через ListObjectsV2 и GetObject.
3. Удалять после обработки.
4. Повторять раз в секунду — получаем «очередь» с задержкой ~1 с и бесплатным исходящим трафиком внутри региона.

Плюсы:

• нет платы за NAT Gateway;
• S3 дёшев и масштабируем;
• можно шифровать объекты.

Минусы:

• eventual consistency: сообщения могут дублироваться или задерживаться;
• rate limit 3 500 PUT/COPY/POST/DELETE и 5 500 GET/HEAD на префикс;
• ListObjects дорогой (0,005 $ за 1 000 запросов);
• придётся реализовать ack/nack, dead-letter и backoff самому.

---

«Продвинутые» техники

• Long polling: ждать, пока в бакете появится новый объект.
• Fan-out: несколько читателей по префиксам.
• Batching: складывать сообщения в один объект gzipом.
• Priority: префиксы high/, low/.
• FIFO: ключ queue/<timestamp>-<uuid>.json.
• DLQ: префикс failed/.
• Крон: Lambda по расписанию чистит старые сообщения.

---

Итог

S3-очередь — это пародия на архитектуру, но она работает и экономит деньги. Для настоящих задач используйте SQS, Kafka или RabbitMQ.

• Участники вспомнили, как в 90-х использовали Microsoft Exchange вместо дорогого TIBCO, а Amazon Video — S3 вместо очереди, и оба решения оказались «костылями».
• Подчеркивают, что очередь — это просто быстрый конечный автомат, но самописные варианты на SQL или Git-вебхуках быстро ломаются под нагрузкой.
• Некоторые шутят, что любую технологию можно превратить в очередь или базу, если использовать её «достаточно неправильно».
• Обсуждают юридические проблемы с IP, когда хобби-проект пересекается с работой, и сравнивают цены AWS с Whole Foods.
• В итоге сходятся во мнении: костыль может работать, но рано или поздно придётся платить за правильное решение.

Мы перенесли Docker-реестр в собственный дата-центр на Harbor, отказавшись от Docker Hub и ECR.
Причины: счета за лицензию и трафик, 45-секундные задержки деплоя, риски утечек, лимиты API.

Критерии нового решения: надёжность, скорость, простота, open-source.
Выбрали Harbor: богаче функций, чем «голый» distribution, ставится через docker-compose.

v1-дизайн

• Хранилище: S3-совместимый Pure FlashBlade.
• Две независимые копии в Ashburn и Chicago (пока без HA PostgreSQL/Redis).
• Политики очистки для экономии места.

Минимальные права на бакет
s3:AbortMultipartUpload, DeleteObject, GetBucketLocation, GetObject, ListBucket, ListBucketMultipartUploads, ListMultipartUploadParts, PutObject

harbor.yml (фрагмент)

hostname: "#{node['fqdn']}"
http: { port: 80 }
data_volume: /data
storage_service:
  s3:
    bucket: docker-registry-bucket
    accesskey: "#{bucket_credentials['access_key']}"
    secretkey: "#{bucket_credentials['secret_key']}"
    regionendpoint: "https://purestorage.#{node['domain']}"
metric: { enabled: true, port: 9090, path: /metrics }

Конфиг разворачивается Chef на выделенных нодах, SSL-терминация на F5.

• Harbor удобен: SSO, Terraform-провайдер, но нет API для токена при docker login, приходится создавать robot-аккаунты.
• Ресурсы 32 CPU / 64 GB RAM выглядят завышенными для 32 000 пуллов за два месяца; скорее всего, просто оверпровижн.
• Многие используют один «источник истины» Harbor + региональные кэши или просто registry в режиме pull-through-cache.
• У Harbor нет OIDC-доступа из GitHub Actions, апгрейды ручные; Nexus проще для Maven/NuGet, но тоже прожорлив и иногда не чистит блобы.
• ECR в AWS дешёв (~3 $/мес) и без хостинга, но не on-prem; для S3-подобного хранилища советуют SeaweedFS, Garage или Pure Flashblade.

• EC2

  • Менять IAM-роли и security-groups можно без остановки инстанса.
  • EBS можно расширять, подключать и отключать «на горячую».
  • Принудительный stop/terminate без ожидания таймаута.
  • Live-migration между хостами почти убрала деградацию инстансов.
  • Надёжность выросла: «исчезновение» инстансов стало редкостью.
  • Spot-рынок стал стабильнее, без аукционов.
  • Dedicated Instances почти не нужны — даже для HIPAA.
  • AMI Block Public Access включён по умолчанию.

• S3

  • Стал строго согласованным (read-after-write).
  • Не нужно рандомить префиксы ключей для равномерного распределения.
  • ACL устарели и отключены по умолчанию.
  • Block Public Access включён на новых бакетах.
  • Шифрование покоя включено по умолчанию.

• AWS теперь по умолчанию блокирует публичный доступ к новым S3-бакетам; это снижает утечки, но усложняет легитимное открытие доступа.
• Пользователи обсуждают, что многие «улучшения» AWS — это просто исправление первоначально неудобных решений, и это влияет на репутацию.
• По-прежнему спорны детали: нужно ли случайное префиксирование ключей S3, почему NAT Gateway взимается за трафик внутри одного региона и почему Transit Gateway дороже peering.
• Некоторые разработчели «деградируют» от сложных serverless-стеков к простым EC2 + S3 + Route 53 ради простоты и экономии времени на IAM.
• Участники просят ежегодные сводки изменений и жалуются на ослабление платной поддержки AWS.

Большие файлы — давний враг Git: раздувают репозиторий, замедляют клонирование и дорого обходятся хостингам. С 2015 г. GitHub предлагает Git LFS, но он влечёт vendor-lock, плату за хранение, сложности отката и необходимость ставить расширение всем участникам.

Сегодня можно обойтись без LFS:

• Partial clone (--filter=blob:limit=100k) скачивает только нужные большие файлы, ускоряя клонирование в 30–50 раз и уменьшая дисковый след до размеров LFS-чекаутов.
• Недостаток: команды вроде git blame требуют до-загрузки, но для PNG-файлов это редко нужно.

Будущее — large object promisors:
Git-сервер будет прозрачно выгружать большие объекты в специальный remote, избавляя пользователей от LFS и хостинги — от лишних затрат.

• Критикуют Git LFS за «проприетарность», но многие отмечают, что протокол открыт и работает и с GitLab, и с S3.
• Основные боли: сломанные офлайн-режимы, многократная аутентификация, высокие расходы на трафик и неочевидные команды при клоне.
• Альтернативы — git-annex, DVC, Oxen, datamon и просто «не класть большие файлы в git», а хранить их в Artifactory.
• Часть участников ждёт нативную поддержку больших файлов в самом Git, чтобы не помнить про --filter=blob:none и LFS-указатели.

• Edka Digital — упростите Kubernetes и выкатывайте всё, что нужно, за 2 минуты.
• Сэкономьте до 70 % на облаке: кластеры k3s в вашем аккаунте Hetzner без потери контроля.
• Первый кластер бесплатно — попробовать.

---

Ваш собственный платформенный слой

• Мгновенное развёртывание — production-ready кластер за минуты.
• GitOps — CI/CD из GitHub/GitLab, превью на PR.
• Дополнения в один клик — БД, ingress, мониторинг.
• Мониторинг и аналитика в реальном времени.
• Резервные копии (скоро) — S3 одним кликом.
• Открытые стандарты CNCF — без вендор-лока.

---

Цены

• Оплата по прайсу Hetzner + фикс. подписка за кластер.
• Уходите в любой момент — ресурсы остаются вашими.

---

Кейсы

• Aicole — 64 % экономии, 20 деплойментов в день.
• TROI Ticketing — 72 % экономии, 6 k DAU.

---

Готовые приложения и адд-оны

Cert Manager, CloudNative PG, Keel и другие — смотреть все.

• Проект Edka взлетел на HN, но столкнулся с rate-limit от GitHub и частичным аутейджем Hetzner, из-за чего новые кластеры зависали в статусе «creating».
• Пользователи сравнивают Edka с kops, kube-hetzner/terraform, Syself и Linode, спрашивают про bare-metal, root-серверы, масштабирование, безопасность, обновления, сторедж, GitLab-реестр и другие провайдеры.
• Недоверие вызывает отсутствие импринта, юр. данных и реального адреса компании (упоминается «Edka Digital S.L.»).
• Некоторые просто ставят microk8s/Proxmox на bare-metal Hetzner и считают это надёжнее.
• Автор обещает улучшать платформу и благодарит за интерес к сайд-проекту.