Bedolaga-бот: установка и связка с Remnawave

Установка Bedolaga занимает четыре команды из README. Остальное время уходит на то, чтобы понять, почему бот не видит панель, платёжка не может достучаться до вебхука, а после git pull всё упало. Ниже порядок, при котором этих вопросов меньше.

#Что это и из чего состоит

Bedolaga ( BEDOLAGA-DEV/remnawave-bedolaga-telegram-bot) принимает оплату и управляет подписками через API панели Remnawave. На ноды бот не ходит: он создаёт, продлевает и отключает пользователей в панели, а панель уже раздаёт конфиги нодам. Без развёрнутой панели бот бесполезен, это прямо указано в требованиях документации.

Официальный docker-compose.yml (ветка main на 2026-09-24) поднимает три сервиса:

Веб-кабинет ( bedolaga-cabinet, React) живёт в отдельном репозитории и в этот compose не входит.

#Установка

Нужны Docker 20.10+ с Compose v2 и уже работающая панель (если её нет, начни с Remnawave с нуля). Команды из README, плюс закрепление на релизном теге:

git clone https://github.com/BEDOLAGA-DEV/remnawave-bedolaga-telegram-bot.git
cd remnawave-bedolaga-telegram-bot
git checkout v4.15.0          # релизный тег вместо живой ветки main
cp .env.example .env

Контейнер бота работает от пользователя с UID 1000 (так задано в Dockerfile), а каталоги logs, data, locales, uploads монтируются с хоста. Сообщество регулярно ловит Permission denied и Locale directory is not writable, и лечится это одинаково ( ошибки, с 2025 года; кейсы, 03.04.2026):

mkdir -p logs data/backups locales uploads
sudo chown -R 1000:1000 logs data locales uploads

#Порт 8080 не должен смотреть в мир

В официальном compose порт опубликован как '${WEB_API_PORT:-8080}:8080', то есть на всех интерфейсах. Docker при этом обходит ufw (подробно в гайде Docker для панелей). Чтобы не править docker-compose.yml и не ломать себе git pull, положи рядом override-файл. Compose подхватывает его автоматически, а !override заменяет список портов целиком, а не дописывает к нему:

services:
  bot:
    ports: !override
      - "127.0.0.1:8080:8080"

Проверь итог командой docker compose config | grep -A3 ports: в выводе должен остаться один порт на 127.0.0.1.

Запуск:

docker compose up -d --build
docker compose logs -f bot

#Минимальный .env

Документация называет обязательными четыре переменные. Всё остальное в .env.example (почти 1400 строк) имеет значения по умолчанию, и большую часть настроек удобнее менять из админки бота. Сообщество советует держать .env коротким и не раскомментировать лишнее ( установка и обновление, май 2026).

# Токен от @BotFather
BOT_TOKEN=1234567890:AA...                 # ← свой
# Telegram ID админов через запятую
ADMIN_IDS=123456789                        # ← свой

# Адрес панели без /api на конце
REMNAWAVE_API_URL=https://panel.example.com  # ← свой домен
# Токен из Remnawave Settings → API Tokens
REMNAWAVE_API_KEY=<токен_из_панели>          # ← свой
REMNAWAVE_AUTH_TYPE=api_key

# База: пароль по умолчанию из compose (secure_password_123) не оставляй
POSTGRES_PASSWORD=сгенерируй_openssl_rand_hex_24   # ← свой

POSTGRES_PASSWORD читают и контейнер базы, и бот. Образ postgres применяет его только при первой инициализации пустого тома, поэтому пароль нужно выбрать до первого up. Если сменить его позже только в .env, бот не сможет подключиться к базе: в самой базе остался старый пароль.

#Связь с панелью

Токен создаётся в панели: Remnawave Settings → API Tokens. Бот передаёт его в заголовке Authorization: Bearer. Для панелей за дополнительной защитой есть другие режимы REMNAWAVE_AUTH_TYPE (basic_auth, caddy), а для панелей, поставленных скриптом eGames, переменная REMNAWAVE_SECRET_KEY в формате ключ:значение.

Адрес зависит от того, где стоит бот:

• Отдельный сервер. REMNAWAVE_API_URL=https://panel.example.com, запросы идут через reverse proxy панели. По опыту сообщества, вариант с /api на конце даёт API Error 404 ( env, апрель–май 2026).
• Тот же сервер. Бот подключается к Docker-сети панели remnawave-network, а адрес становится REMNAWAVE_API_URL=http://remnawave:3000. Для этого в репозитории есть docker-compose.local.yml (запуск с -f docker-compose.local.yml). В документации сеть описана с external: true: тогда Compose её не создаёт, и панель должна быть поднята первой. Подробно про внешние сети в гайде по Docker.

#Вебхуки от панели

Без них бот узнаёт об изменениях в панели только при синхронизации. Секрет общий для обеих сторон. openssl rand -hex 32 даёт ровно 64 символа [0-9a-f] и подходит под требования обеих сторон: бот просит минимум 32 символа, .env.sample панели требует ровно 64 из a-z, A-Z, 0-9.

REMNAWAVE_WEBHOOK_ENABLED=true
REMNAWAVE_WEBHOOK_PATH=/remnawave-webhook
REMNAWAVE_WEBHOOK_SECRET=<вывод openssl rand -hex 32>   # ← одинаковый в обоих файлах

WEBHOOK_ENABLED=true
WEBHOOK_URL=https://hooks.example.com/remnawave-webhook  # ← свой домен
WEBHOOK_SECRET_HEADER=<тот же секрет>

Проверка: curl -s https://hooks.example.com/remnawave-webhook должен вернуть {"status": "ok", "service": "remnawave_webhook", "enabled": true}. Ошибка RemnaWave webhook: invalid signature в логах бота означает, что секреты не совпали ( env и вебхуки, 21.08.2026).

#Вебхуки платёжек через reverse proxy

Все платёжки, Telegram webhook и Web API обслуживает один FastAPI-сервер на порту 8080. У каждой платёжки свой путь: /yookassa-webhook, /platega-webhook, /cryptobot-webhook и так далее. Снаружи нужен HTTPS-домен (в документации hooks.domain.com) и reverse proxy, который отдаёт эти пути на 127.0.0.1:8080 или на remnawave_bot:8080, если прокси в той же Docker-сети.

location = /yookassa-webhook {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Три грабли из базы ( env и вебхуки, август 2026):

• Роут вебхука монтируется только при *_ENABLED=true в .env. Если включить платёжку только из админки, вебхук отдаёт 404, а платёж зависает.
• «В платёжке оплачено, в боте нет» обычно значит, что URL вебхука не прописан в личном кабинете платёжки.
• HTTP 405 на хук почти всегда виноват reverse proxy.

Для YooKassa бот проверяет IP отправителя. Если перед ботом стоит свой прокси, его сеть указывают в YOOKASSA_TRUSTED_PROXY_NETWORKS. Приватные сети и диапазоны Cloudflare бот доверяет сам. Если прокси идёт через Cloudflare или анти-DDoS, документация требует пропускать метод POST и заголовок X-Telegram-Bot-Api-Secret-Token. Для режима webhook в .env задаются BOT_RUN_MODE=webhook, WEBHOOK_URL, WEBHOOK_SECRET_TOKEN и WEB_API_ENABLED=true. Состояние видно на /health/unified.

#Бэкапы

У бота есть встроенные автобэкапы (BACKUP_AUTO_ENABLED=true по умолчанию, раз в 24 часа, хранится 7 копий в /app/data/backups) с отправкой в Telegram-чат и паролем архива BACKUP_ARCHIVE_PASSWORD. Только лежат они на том же сервере. Внешний дамп снимай отдельно, имя роли бери из окружения контейнера:

docker exec remnawave_bot_db sh -c \
  'pg_dump -Fc -U "$POSTGRES_USER" -d "$POSTGRES_DB"' > bot_$(date +%F).dump

В документации пример с -U postgres, но в compose бота роль называется remnawave_user, отсюда частая ошибка role "postgres" does not exist ( кейсы, апрель 2026). Шифрование, выгрузка в S3 и проверка восстановления разобраны в гайде Бэкапы через restic.

#Типовые ошибки из базы

#Источники

• Bedolaga: README, docker-compose.yml, .env.example, Dockerfile, релиз v4.15.0
• Документация Bedolaga: Требования, Переменные окружения, Docker развёртывание, Интеграция с Remnawave, Обслуживание, Устранение неполадок
• Remnawave: .env.sample, Environment variables, Subscription page: API token
• Docker: compose restart, Merge и !override, образ postgres
• База host.pink: Установка и обновление, Env-переменные, Ошибки и фиксы, Кейсы, Env и вебхуки платёжек, API, Индекс env, Индекс ошибок