Как запустить Wafrn на shared-хостинге без конфликтов

Когда хочется публиковать везде сразу

Федивёрс даёт возможность написать пост один раз — и он разойдётся по BlueSky, Mastodon, Lemmy и другим платформам. Wafrn как раз для этого и создан: единая панель, которая сама раскидывает контент. Но за удобством прячется нюанс — инструмент из коробки рассчитан на dedicated-сервер, где можно просто поднять Docker и отдать Caddy все порты.

Если у вас уже крутится WordPress, пара API-сервисов или другие приложения на одном VPS, стандартная схема не влезет.

Почему обычная установка не подходит

По умолчанию Wafrn поднимается в контейнере вместе с Caddy. Тот сам запрашивает сертификаты Let's Encrypt и отдаёт их для проверки по протоколу ATProto — это требование BlueSky-федерации. Сертификат подтверждает, что вы действительно владеете доменом.

Проблема возникает, когда на 443 порту уже висит Nginx или другой веб-сервер. Два разных процесса не могут одновременно управлять SSL для одного домена. Получается конфликт и на уровне портов, и на уровне сертификатов.

Решение: Caddy как отдельный сервис за основным прокси

Вместо того чтобы менять всю инфраструктуру, можно оставить Nginx на внешнем порту, а Wafrn с Caddy запустить изолированно внутри сети. Основной сервер будет просто пробрасывать нужные пути на внутренний Caddy.

Схема выглядит так:

Внешний клиент
    ↓
Nginx (порт 443)
    ↓
Caddy + Wafrn (внутренняя сеть)

Внешний трафик приходит на Nginx. Тот смотрит на путь — например /wafrn/* — и отправляет запрос дальше. Caddy внутри уже сам занимается сертификатами для ATProto и отдаёт ответы по протоколу.

Что даёт такой подход

Вы сохраняете текущую настройку домена и не трогаете работающие сервисы. Wafrn при этом получает всё необходимое для федерации: свой TLS и контроль над доменом на уровне протокола.

Когда AI помогает, а когда мешает

Если решите полностью перейти с Nginx на Caddy, AI хорошо справится с конвертацией конфигов. Синтаксис Caddyfile проще, и модель обычно выдаёт рабочий результат с первого раза.

А вот с настройкой Wafrn под гибридную схему всё сложнее. Нужно понимать, как именно ATProto проверяет сертификаты, какие переменные окружения отвечают за прокси, и где может возникнуть дыра в безопасности. Здесь лучше не полагаться на готовые подсказки — проще написать конфиг самому и потом отладить.

Что стоит задокументировать

Если вы уже настроили Wafrn под shared-инфраструктуру, скорее всего нашли места, где документация проекта упрощает реальность. Такие кейсы полезно описывать: публиковать обновлённые инструкции, выкладывать примеры конфигов в репозиторий или предлагать правки в официальную документацию. Следующий человек сэкономит несколько часов на тех же граблях.

Коротко

• ATProto требует валидных сертификатов — это не опция.
• Стандартная установка под dedicated-сервер не всегда вписывается в shared-среду.
• Caddy лучше держать отдельно, чтобы он управлял только своей частью TLS.
• AI удобно использовать для перевода конфигов, но не для проектирования архитектуры.
• Если решение рабочее — поделитесь им. Это экономит время сообществу.

Что дальше

Та же схема работает и с другими федеративными приложениями, которым нужен контроль над сертификатами. Главное — изолировать их прокси-слой и не мешать основному веб-серверу.

Если настраиваете похожий стек или ищете альтернативы для кросс-постинга — пишите в комментариях.