Hacker News Digest

Тег: #caddy

Постов: 5

You Don't Need Anubis (fxgn.dev)

В последние годы скраперы, используемые компаниями для обучения LLM, стали более агрессивными, игнорируя robots.txt и маскируясь под обычных пользователей. Это привело к росту популярности Anubis — решения на основе proof-of-work, требующего от посетителей решения криптографической задачи перед доступом к сайту. Однако автор утверждает, что Anubis неэффективен против LLM-скраперов, так как те просто не выполняют JavaScript, а вычислительные затраты для обхода всех установок Anubис составляют примерно $0.00.

В качестве альтернативы предлагается простой 12-строчный Caddyfile, который устанавливает cookie через JavaScript, эффективно блокируя ботов без 10-секундной задержки для посетителей. Оба решения являются временными, так как боты могут научиться их обходить — Huawei уже умеет решать задачи Anubis. Автор подчеркивает, что если единственная проблема — ClaudeBot, лучше использовать менее раздражающие решения, а Cloudflare остается наиболее надежным, хоть и монопольным, способом защиты от ботов.

by flexagoon • 02 ноября 2025 г. в 04:03 • 119 points

ОригиналHN

#javascript#caddy#cloudflare#web-scraping#llm#rate-limiting

Комментарии (97)

  • Обсуждение в основном вращается вокруг того, что Anubis и подобные системы защиты от скрапинга, по сути, не решают проблему, а лишь создают неудобства для пользователей и разработчиков, и что это больше похоже на "security theater", чем на реальную защиту.
  • Участники обсуждения подчеркивают, что LLM и скраперы уже давно научились обходить такие системы, и что единственный эффект — это лишнее время загрузки для обычных пользователей.
  • Также поднимается вопрос о том, что вместо того, чтобы развивать "arms race" вокруг защиты от скрапинга, было бы лучше сосредоточиться на создании устойчивых и этичных решений, которые бы не требовали таких мер.
  • Некоторые участники также отмечают, что вместо того, чтобы полагаться на подобные системы, разработчики могли бы использовать более прогрессивные подходы, такие как rate limiting, требование авторизации для доступа к API и другие методы, которые не требуют от пользователей выполнения сложных вычислений.
  • В конце концов, обсуждение смещается к тому, что вместо того, чтобы продолжать "гонку вооружений", было бы более продуктивно сосредоточиться на создании более этичных и устойчивых решений, которые не требуют таких мер.

Hold Off on Litestream 0.5.0 (mtlynch.io)

Новая версия Litestream 0.5.0 приносит значительные изменения: изменился формат резервных копий, что делает невозможным восстановление из бэкапов предыдущих версий, и обновилась структура конфигурационного файла. Автор подробно описывает процесс миграции, столкнувшись с несколькими проблемами.

Первая проблема возникла при попытке загрузить данные в Backblaze — система выдавала ошибку из-за неверного URI, что потребовало фикса от разработчиков.

Вторая проблема: в новой версии удалили флаг -if-replica-exists, критически важный для проверки наличия бекапов перед запуском приложения. Хотя флаг обещали вернуть в следующей версии, его отсутствие в 0.5.0 создавало сложности.

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

Автор подчеркивает, что несмотря на трудности, он продолжает использовать Litestream за его полезность, но советует подождать с апгрейдом до следующего релиза.

by mtlynch • 14 октября 2025 г. в 16:10 • 80 points

ОригиналHN

#litestream#backblaze#sqlite#docker#go#caddy

Комментарии (15)

  • The user is discussing issues they encountered while implementing lightweight read replicas for a Go SQLite driver, referencing a specific implementation and a GitHub repository.
  • They mention that while there are issues, the concept is workable, and they already have a version that mostly works, noting the massive changelog and that it's not unexpected to have issues given the scope.
  • Other users discuss the benefits of Litestream 0.5.0, including an official Docker image, though one user corrects that there has been an official Docker image for years, since version 0.3.4.
  • One user shares they are staying on an older version (0.3.13) for now due to similar issues but are excited for 0.5.x once it stabilizes, praising the integration of Litestream, SQLite, and Caddy for single-box operations.
  • A user notes the most disruptive part is the migration to a new LTX format, which is hard to do incrementally, and another user reflects on the versioning, noting that being a 0.x release means breaking changes are expected, though it might still be a minor footnote in the software's lifecycle.
  • The original poster concludes by correcting an oversight about the Docker image, noting the badge has been present for years, and speculates that the user who thought the image was new might have had a bad initial experience that discouraged them from trying again.

Native ACME support comes to Nginx (letsencrypt.org)

NGINX теперь с ACME
12 авг. NGINX официально добавил встроенный модуль ngx_http_acme (на Rust), который сам получает и продлевает сертификаты Let’s Encrypt.

Зачем

  • никаких внешних клиентов;
  • работает из коробки: от домашнего лаба до кластеров Kubernetes;
  • меньше рутины, больше шифрования.

Кто ещё
Traefik, Caddy, Apache уже умеют; теперь к ним присоединился самый популярный веб-сервер и прокси.

Разработчикам
Протокол ACME, библиотеки и обсуждение — на форуме Let’s Encrypt.

by Velocifyer • 11 сентября 2025 г. в 17:28 • 120 points

ОригиналHN

#nginx#acme#letsencrypt#rust#tls#kubernetes#apache#traefik#caddy

Комментарии (44)

  • Кто-то рад встроенному ACME в nginx, кто-то считает, что «сертификат должен получать отдельный клиент», а не каждый сервис в отдельности.
  • Спор о безопасности: модуль на Rust, но в нём много unsafe-блоков для взаимодействия с Си-ядром nginx.
  • Вопрос «зачем ждать столько лет?» — ответ: корпоративные заказчики F5/medленный релиз-цикл.
  • Практика: можно отключить встроенный ACME и продолжать использовать certbot/cert-manager.

SSL certificate requirements are becoming obnoxious (chrislockard.net) 💬 Длинная дискуссия

SSL-сертификаты превратились в головную боль
Я утверждаю SSL для компании: процесс отлажен, но частота задач выросла с «раз в квартал» до «еженедельно». Сертификаты критичны, но их администрирование уже даёт обратный эффект.

Методы валидации
Издатель отказался от файловой проверки для wildcard и усложнил её для обычных сертификатов. Остались TXT-записи и email, но почту для test.lab.corp.example.com никто не создаёт, так что фактически выбор один — DNS.

Новые защиты
Следующий месяц принесёт MPIC: CA будет проверять домен с нескольких географических точек, чтобы победить BGP-hijacking.

  • Сколько компаний ограничивают доступ по регионам?
  • Сколько сертификатов реально выдали злоумышленники? В Википедии один случай за 2021 год — $1,9 млн ущерба. Стоит ли оно внедрения?

Сроки и коммуникации
О «прорывных» изменениях узнаю за пару недель. Приходится смущённо просить коллег «проверьте, не сломается ли прод» — это подтачивает доверие.

Срок жизни сертификатов
Самая мерзкая новинка — постепенное сокращение сроков валидации…

by unl0ckd • 26 августа 2025 г. в 12:50 • 167 points

ОригиналHN

#ssl#certificates#dns#bgp#lets-encrypt#acme#caddy#automation

Комментарии (213)

  • Современные инструменты (Let’s Encrypt, ACME, Caddy) уже автоматизировали SSL для большинства сайтов, оставляя минимум ручной работы.
  • Сокращение срока жизни сертификатов до 47 дней сознательно заставляет команды автоматизировать процесс и снижает риски отзыва.
  • В крупных и регулируемых компаниях всё ещё много ручных процессов: аудиты, внутренние CA, специфические требования к сертификатам.
  • Для старых устройств, вендорских продуктов и внутренней инфраструктуры автоматизация остаётся нетривиальной или невозможной.
  • Некоторые считают, что всё это — способ «контроля» и вытеснения пользователей в облачные платформы.

Static sites with Python, uv, Caddy, and Docker (nkantar.com)

Стек для Python-статики: uv + Caddy + Docker

Я почти полностью перешёл на uv — он быстрый, удобен и сам ставит нужный Python. Статические сайты собираю Python-скриптами, а раздаю через Caddy в многоступенчевом Docker-контейнере.

Пример на sus

Dockerfile (сжато):

FROM ghcr.io/astral-sh/uv:debian AS build
WORKDIR /src
COPY . .
RUN uv python install 3.13
RUN uv run --no-dev sus

FROM caddy:alpine
COPY Caddyfile /etc/caddy/Caddyfile
COPY --from=build /src/output /srv/
  1. Берём образ с uv, копируем код.
  2. uv ставит Python 3.13 и зависимости, запускает sus, который кладёт сайт в /output.
  3. Вторая стадия — лёгкий Caddy. Копируем конфиг и готовые статические файлы в /srv.

Caddyfile минимален:

:80
root * /srv
file_server

Запуск:

docker build -t sus .
docker run -p 80:80 sus

Итог: быстрая сборка, маленький образ, автоматический HTTPS при нужном домене.

by indigodaddy • 22 августа 2025 г. в 15:15 • 124 points

ОригиналHN

#python#uv#caddy#docker#dockerfile#sus#coolify#nginx#apache#https

Комментарии (75)

  • Почти все комментаторы считают выбранный стек (Docker, uv, Caddy, Coolify) избыточным для статического личного сайта.
  • Критика сводится к тому, что достаточно «HTML → Nginx/Apache» или даже «HTML → FTP».
  • Автор отвечает: хотел остаться в экосистеме Coolify ради единого CI/CD и «zero-SSH» деплоя.
  • Некоторые предлагают минимальные Dockerfile (nginx:alpine + COPY) или вообще отказаться от контейнеров.
  • Обсуждение выродилось в дискуссию о «культуре овер-инжиниринга» и самоучках, использующих сложные инструменты без понимания базовых.