bolt Valebyte VPS от $4/мес — NVMe, запуск за 60 секунд.

Получить VPS arrow_forward
eco Начальный Туториал

Установка Fider на VPS: self-hosted сбор обратной связи, SSL и SMTP

calendar_month Oct 06, 2026 schedule 22 мин. чтения visibility 30 просмотров
Установка Fider на VPS: self-hosted сбор обратной связи, SSL и SMTP
info

Нужен сервер для этого гайда? Мы предлагаем выделенные серверы и VPS в 50+ странах с мгновенной настройкой.

Нужен сервер для этого гайда?

Разверните VPS или выделенный сервер за минуты.

Установка Fider на VPS: self-hosted сбор обратной связи, SSL и SMTP

TL;DR

Fider — self-hosted платформа для сбора идей, голосований и обратной связи от пользователей. В этом гайде вы развернёте Fider на Ubuntu VPS через Docker Compose, подключите PostgreSQL, настроите HTTPS с Caddy, SMTP-уведомления, резервные копии и базовую защиту сервера.

  • Для небольшой публичной доски идей достаточно VPS с 2 vCPU, 2 ГБ RAM и 25 ГБ SSD.
  • Fider запускается в Docker вместе с PostgreSQL, поэтому обновление и перенос сервиса остаются предсказуемыми.
  • Caddy автоматически выпускает и продлевает TLS-сертификаты Let's Encrypt.
  • SMTP обязателен для приглашений, подтверждения входа и уведомлений о новых идеях или комментариях.
  • В бэкап нужно включать дамп PostgreSQL, файл окружения, Docker Compose-конфигурацию и данные Caddy.
  • После установки сервис будет доступен по адресу вида https://feedback.example.com.

Что мы настраиваем и зачем

Схема: Что мы настраиваем и зачем
Схема: Что мы настраиваем и зачем

Fider — это open-source приложение для управления предложениями пользователей. Оно позволяет создать публичный или закрытый портал обратной связи: посетители публикуют идеи, другие пользователи голосуют, оставляют комментарии, а команда меняет статус предложений и сообщает о ходе работы.

Типичный сценарий — SaaS-продукт, интернет-магазин, игровое сообщество, внутренний корпоративный сервис или open-source проект. Вместо того чтобы собирать идеи в почте, Telegram, Discord, Google Forms и задачах Jira, вы предоставляете пользователям одну понятную точку входа.

После завершения настройки у вас будет отдельный поддомен, например feedback.example.com, с действующим HTTPS-сертификатом, PostgreSQL-базой данных, отправкой писем по SMTP и автоматизированным резервным копированием. Архитектура будет состоять из четырёх компонентов:

  • Fider — веб-приложение, доступное пользователям через браузер.
  • PostgreSQL — база данных с пользователями, голосами, постами, комментариями и настройками.
  • Caddy — reverse proxy, который принимает HTTPS-трафик, получает сертификаты и передаёт запросы в Fider.
  • Docker Compose — инструмент, описывающий контейнеры, сети, постоянные тома и переменные окружения.

Что умеет Fider

В базовой конфигурации Fider даёт возможность создавать пространства обратной связи, модерировать публикации, голосовать за идеи, комментировать предложения, помечать посты статусами и отправлять уведомления. Администратор может управлять доступом, настраивать домен, внешний вид и способы аутентификации.

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

Облачный сервис или self-hosted Fider

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

Self-hosted установка Fider на VPS оправдана, если вам важны контроль над данными, собственный домен, предсказуемая стоимость, возможность сделать закрытую внутреннюю доску или соблюсти требования к географии хранения данных. Вы самостоятельно отвечаете за обновления и бэкапы, но получаете полный контроль над инфраструктурой.

Критерий Cloud-managed сервис Fider на собственном VPS
Развёртывание Несколько минут без сервера Около 1–2 часов с настройкой домена и SMTP
Контроль данных Данные у внешнего поставщика Данные в вашей PostgreSQL-базе
Стоимость Обычно растёт с числом участников Фиксированная стоимость VPS и SMTP
Обновления Выполняет поставщик Выполняете вы по расписанию
Кастомизация Ограничена тарифом Доступны настройки, API и собственная инфраструктура

Что понадобится до начала работы

  • VPS или dedicated-сервер с публичным IPv4-адресом.
  • Домен или поддомен, например feedback.example.com.
  • Возможность создать DNS-запись типа A.
  • Доступ к SMTP-провайдеру либо собственному почтовому серверу.
  • Локальный SSH-клиент: OpenSSH, Windows Terminal, PuTTY или аналог.
  • Операционная система Ubuntu Server 24.04 LTS или Debian 12/13. В примерах используется Ubuntu 24.04 LTS.

Не публикуйте Fider напрямую на порту 3000 в интернет. Контейнер приложения должен быть доступен только reverse proxy внутри Docker-сети, а снаружи нужно оставить только SSH, HTTP и HTTPS.

Какой VPS-конфиг нужен под эту задачу

Схема: Какой VPS-конфиг нужен под эту задачу
Схема: Какой VPS-конфиг нужен под эту задачу

Fider не является ресурсоёмким приложением, если речь идёт о нескольких сотнях или тысячах зарегистрированных пользователей и умеренной активности. Основное потребление памяти создают PostgreSQL, Docker-контейнеры и файловый кэш операционной системы. Поэтому 1 ГБ RAM формально может запустить сервис, но для стабильной эксплуатации лучше не использовать настолько минимальную конфигурацию.

Сценарий CPU RAM Диск Сеть
Тестовый стенд, до 100 активных пользователей 1 vCPU 1–2 ГБ 20 ГБ SSD 100 Мбит/с
Небольшой продукт, до 5 000 пользователей 2 vCPU 2–4 ГБ 25–40 ГБ NVMe/SSD 100 Мбит/с или 1 Гбит/с
Несколько досок и активное сообщество 4 vCPU 8 ГБ 80 ГБ NVMe 1 Гбит/с
Высокая нагрузка, отдельная БД 4–8 vCPU 16 ГБ 160 ГБ NVMe 1 Гбит/с

Практичный стартовый вариант — 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe и канал от 100 Мбит/с. Этого достаточно для Fider, PostgreSQL, Caddy, автоматических бэкапов и небольшого запаса под рост. Например, можно взять VPS с указанными характеристиками, установить Ubuntu 24.04 LTS и следовать командам из этого руководства.

Почему важен запас по памяти

При нехватке RAM Linux начинает активно использовать swap. Это не всегда приводит к падению Fider, но заметно увеличивает время ответа PostgreSQL и веб-приложения. С 2 ГБ памяти сервис обычно работает нормально, однако 4 ГБ дают более комфортный запас на обновления, резервное копирование и кратковременные пики активности.

Следите за свободным местом на диске. PostgreSQL растёт не только за счёт данных, но и из-за журналов транзакций, индексов и временных файлов. Docker также хранит образы и слои контейнеров. Не заполняйте файловую систему выше 80–85%: на переполненном диске база данных может перестать принимать записи.

Когда нужен dedicated, а не VPS

Для одной или нескольких обычных Fider-досок dedicated-сервер не нужен. VPS проще масштабировать, дешевле резервировать и быстрее переносить. Выделенный сервер имеет смысл при очень активном публичном сообществе, десятках тысяч ежедневных посетителей, жёстких требованиях к изоляции ресурсов или размещении нескольких тяжёлых систем рядом с Fider.

Если база данных вырастает до десятков гигабайт, а пользователи постоянно создают посты и комментарии, сначала разделите роли: оставьте Fider и Caddy на одном VPS, а PostgreSQL перенесите на отдельный сервер или managed PostgreSQL. Это обычно эффективнее, чем сразу переходить на большой dedicated.

Выбор локации

Локация сервера влияет на задержку, требования к обработке персональных данных и скорость отправки писем. Выбирайте регион, наиболее близкий к основной аудитории. Для команды и клиентов из Европы обычно логичен европейский дата-центр; для аудитории из Азии — азиатская локация.

Если Fider используется внутри компании, проверьте, можно ли хранить данные сотрудников и клиентов в выбранной юрисдикции. Кроме того, убедитесь, что SMTP-провайдер разрешает отправку писем из IP-адреса выбранного региона и что порт 25 не является единственным доступным вариантом: предпочтительнее использовать 587 с STARTTLS или 465 с TLS.

Подготовка сервера

Схема: Подготовка сервера
Схема: Подготовка сервера

Ниже предполагается, что вы получили IP-адрес сервера и временный пароль пользователя root. Подключитесь к серверу по SSH, выполните начальное обновление, создайте отдельного пользователя для администрирования и отключите опасные способы удалённого доступа.

На локальном компьютере сначала создайте ключ, если его ещё нет. Не отправляйте приватный ключ на сервер и не передавайте его другим людям. Публичный ключ можно посмотреть командой cat ~/.ssh/id_ed25519.pub.


# Создайте современную пару SSH-ключей на локальном компьютере
ssh-keygen -t ed25519 -a 100 -C "admin@feedback-server"

Подключитесь к серверу как root. Вместо SERVER_IP укажите реальный IPv4-адрес. На первом входе SSH попросит подтвердить fingerprint сервера — сверяйте его с данными панели хостинга, если такая информация доступна.


# Подключитесь к новому серверу
ssh root@SERVER_IP

Обновите пакеты операционной системы. Команду лучше выполнять сразу после создания VPS и затем повторять регулярно. Если обновилось ядро, перезагрузите сервер в удобное время.


# Обновите индекс пакетов и установите все доступные обновления безопасности
apt update && apt upgrade -y

Создайте отдельную учётную запись, добавьте её в группу sudo и установите базовые инструменты. В примере используется пользователь deploy; можно выбрать другое имя без пробелов и специальных символов.


# Создайте пользователя для администрирования и выдайте ему права sudo
adduser deploy
usermod -aG sudo deploy
apt install -y curl wget git nano vim ufw fail2ban ca-certificates gnupg unzip

Скопируйте публичный SSH-ключ для нового пользователя. Эту команду нужно запускать на вашем локальном компьютере, а не на сервере. Затем откройте второе окно терминала и убедитесь, что вход под новым пользователем работает, прежде чем отключать root-доступ.


# С локального компьютера установите публичный ключ для пользователя deploy
ssh-copy-id deploy@SERVER_IP
ssh deploy@SERVER_IP

Защита SSH

После успешной проверки ключевого входа отключите вход root и аутентификацию по паролю. Это снижает риск перебора паролей ботами. Не закрывайте текущую SSH-сессию, пока не убедитесь, что новая сессия под пользователем deploy открывается без пароля.


# Создайте отдельный конфигурационный файл для усиления SSH
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
AllowUsers deploy
EOF

# Проверьте конфигурацию и перезапустите SSH-службу
sudo sshd -t && sudo systemctl restart ssh

Firewall и Fail2ban

Откройте только порты SSH, HTTP и HTTPS. Если вы уже изменили SSH-порт, замените в примере число 22. UFW не закрывает существующее подключение мгновенно, но ошибочная настройка firewall может оставить сервер недоступным, поэтому перед включением ещё раз проверьте правило для SSH.


# Разрешите только SSH, HTTP и HTTPS, затем включите firewall
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Fail2ban анализирует логи SSH и временно блокирует IP-адреса после повторяющихся неудачных попыток входа. Даже при отключённой парольной аутентификации он полезен как дополнительный уровень защиты.


# Включите Fail2ban и настройте базовую защиту SSH
sudo tee /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
EOF

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Проверьте текущую загрузку и состояние диска. На чистом сервере свободное место должно составлять большую часть раздела. В дальнейшем эти команды пригодятся для диагностики проблем с производительностью.


# Проверьте память, диск, нагрузку и активные сетевые порты
free -h
df -h
uptime
sudo ss -tulpn

Установка ПО — пошагово

Схема: Установка ПО — пошагово
Схема: Установка ПО — пошагово

Для Fider удобно использовать Docker Engine и Docker Compose Plugin. На Ubuntu 24.04 LTS не стоит полагаться на старый пакет docker.io из стандартного репозитория, если требуется актуальный Docker. Лучше подключить официальный репозиторий Docker и установить Docker Engine 28.x или более новую стабильную ветку, доступную на момент установки.

Ниже используются следующие компоненты: Ubuntu Server 24.04 LTS, Docker Engine 28+, Docker Compose v2, PostgreSQL 17 в контейнере и Caddy 2.x. Образ Fider будет использовать тег stable; перед обновлением всегда проверяйте changelog проекта и тестируйте новую версию на резервной копии.


# Добавьте официальный GPG-ключ и репозиторий Docker для Ubuntu
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Установите Docker Engine, CLI, Buildx и современный Docker Compose Plugin
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
docker version
docker compose version

Добавьте пользователя deploy в группу docker. Это позволит управлять контейнерами без sudo. Члены этой группы фактически получают привилегии уровня root, поэтому добавляйте в неё только доверенных администраторов.


# Разрешите пользователю deploy выполнять docker-команды без sudo
sudo usermod -aG docker deploy
newgrp docker
docker run --rm hello-world

Создайте каталог проекта. Все важные файлы Fider будут храниться в /opt/fider: Compose-манифест, файл секретов, Caddyfile и каталог для резервных копий. Такой подход упрощает миграцию на другой сервер.


# Создайте структуру каталогов для приложения, proxy и резервных копий
sudo mkdir -p /opt/fider/{caddy,backups,scripts}
sudo chown -R deploy:deploy /opt/fider
cd /opt/fider

Сгенерируйте криптографически стойкие секреты для PostgreSQL и JWT. Не используйте простые пароли, не копируйте примерные значения из статьи и не храните файл .env в публичном Git-репозитории. Пароль базы данных и JWT-secret понадобятся на следующем шаге.


# Сгенерируйте отдельные секреты для PostgreSQL и подписи пользовательских сессий
openssl rand -base64 32
openssl rand -hex 48

До запуска контейнеров создайте DNS-запись. В панели регистратора или DNS-провайдера добавьте запись типа A: имя feedback, значение — IPv4 вашего VPS. Если нужен корневой домен, используйте @ вместо имени поддомена.


# Проверьте с сервера, что DNS-запись указывает на нужный IP-адрес
getent hosts feedback.example.com

Вывод должен содержать IP-адрес вашего VPS. Если DNS ещё не распространился, подождите: обычно это занимает несколько минут, но зависит от TTL и DNS-провайдера. Caddy не сможет получить сертификат Let's Encrypt, пока домен не указывает на сервер и порты 80/443 доступны извне.

Проверка образов перед запуском

Образы будут загружены автоматически командой docker compose up, но предварительная загрузка помогает быстрее обнаружить проблемы с сетью или DNS. Для базы используется PostgreSQL 17 Alpine: ветка 17 стабильна, компактна и хорошо подходит для этого сценария. Fider должен работать с поддерживаемой версией PostgreSQL, указанной в официальной документации проекта.


# Загрузите образы приложения и базы данных до запуска стека
docker pull getfider/fider:stable
docker pull postgres:17-alpine
docker image ls | grep -E 'getfider|postgres'

Тег stable удобен для первого развёртывания, но в production лучше после проверки зафиксировать версию или digest образа. Так автоматическое пересоздание контейнера не приведёт к неожиданному обновлению приложения.

Конфигурация Fider, SSL и SMTP

В этом разделе создаются три файла: .env с секретами, docker-compose.yml с описанием контейнеров и Caddyfile для HTTPS. Подставьте свой домен, email-адрес отправителя и реальные SMTP-реквизиты. Не оставляйте в конфигурации значения из примера.

Файл переменных окружения

Создайте /opt/fider/.env. Переменные Compose автоматически подхватит из этого файла. Установите права 600, чтобы пароль базы и SMTP не могли прочитать другие пользователи системы.


# Создайте файл секретов и измените значения перед первым запуском
cd /opt/fider
cat > .env <<'EOF'
FIDER_DOMAIN=feedback.example.com

POSTGRES_DB=fider
POSTGRES_USER=fider
POSTGRES_PASSWORD=CHANGE_TO_A_LONG_RANDOM_DATABASE_PASSWORD

JWT_SECRET=CHANGE_TO_A_LONG_RANDOM_JWT_SECRET

SMTP_HOST=smtp.example-mail-provider.com
SMTP_PORT=587
SMTP_USERNAME=SMTP_LOGIN_OR_API_KEY
SMTP_PASSWORD=SMTP_PASSWORD_OR_API_KEY
SMTP_FROM=Feedback Team <[email protected]>
EOF

chmod 600 .env

Для SMTP используйте отдельные учётные данные для транзакционных писем. Не указывайте основной пароль от корпоративного ящика. Большинство почтовых провайдеров поддерживают API-ключи или app password. Для порта 587 используется STARTTLS; для 465 часто требуется implicit TLS, и переменные могут отличаться в зависимости от версии Fider и SMTP-провайдера.

Docker Compose для Fider и PostgreSQL

Ниже PostgreSQL не публикует порт наружу: он доступен только контейнеру Fider во внутренней Docker-сети. Сам Fider также не имеет открытого host-порта — доступ к нему будет только через Caddy. Это уменьшает поверхность атаки.


services:
  db:
    image: postgres:17-alpine
    container_name: fider-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10
    networks:
      - fider_internal

  fider:
    image: getfider/fider:stable
    container_name: fider-app
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      BASE_URL: https://${FIDER_DOMAIN}
      DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}?sslmode=disable
      JWT_SECRET: ${JWT_SECRET}
      EMAIL_NOREPLY: ${SMTP_FROM}
      EMAIL_SMTP_HOST: ${SMTP_HOST}
      EMAIL_SMTP_PORT: ${SMTP_PORT}
      EMAIL_SMTP_USERNAME: ${SMTP_USERNAME}
      EMAIL_SMTP_PASSWORD: ${SMTP_PASSWORD}
      EMAIL_SMTP_ENABLE_STARTTLS: "true"
    networks:
      - fider_internal
      - proxy
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://localhost:3000/ > /dev/null || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5

  caddy:
    image: caddy:2-alpine
    container_name: fider-caddy
    restart: unless-stopped
    depends_on:
      - fider
    ports:
      - "80:80"
      - "443:443"
    environment:
      FIDER_DOMAIN: ${FIDER_DOMAIN}
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - proxy

volumes:
  postgres_data:
  caddy_data:
  caddy_config:

networks:
  fider_internal:
    internal: true
  proxy:

Сохраните этот файл как /opt/fider/docker-compose.yml. Перед стартом проверьте, что Compose видит переменные корректно. Команда не должна печатать пароль в общий лог или скриншоты; если вы работаете на shared-системе, не используйте docker compose config без необходимости, поскольку он раскрывает подставленные значения.


# Проверьте синтаксис Compose-файла и подготовьте конфигурацию контейнеров
cd /opt/fider
docker compose config --quiet

Настройка Caddy и автоматического HTTPS

Caddy автоматически запрашивает сертификат Let's Encrypt, перенаправляет HTTP на HTTPS и продлевает сертификат. Для этого домен должен уже указывать на сервер, а firewall и внешний сетевой фильтр должны пропускать TCP-порты 80 и 443.


{
    email [email protected]
    acme_ca https://acme-v02.api.letsencrypt.org/directory
}

{$FIDER_DOMAIN} {
    encode zstd gzip

    reverse_proxy fider:3000 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }

    log {
        output stdout
        format console
    }
}

Сохраните конфигурацию в файле /opt/fider/caddy/Caddyfile. В директиве email укажите рабочий адрес администратора: на него могут поступить уведомления от центра сертификации. Caddy-хранилище caddy_data содержит сертификаты и аккаунт ACME, поэтому его тоже нужно включать в резервные копии.

Запустите стек в фоновом режиме и сразу посмотрите журналы. При первом запуске Fider создаёт необходимые таблицы в PostgreSQL, а Caddy получает сертификат. В зависимости от скорости DNS и сети это обычно занимает от нескольких секунд до пары минут.


# Запустите PostgreSQL, Fider и Caddy в фоновом режиме
cd /opt/fider
docker compose up -d
docker compose ps
docker compose logs --tail=100 -f

Выйдите из режима просмотра логов сочетанием Ctrl+C. В таблице состояния контейнеры должны быть running или healthy. Если Caddy не получил сертификат, не создавайте десятки повторных запросов: сначала проверьте DNS, firewall и доступность портов с внешней сети.

Первичная настройка Fider

Откройте в браузере https://feedback.example.com. При первом посещении Fider предложит создать пространство и первого администратора. Используйте адрес, который способен получать письма через настроенный SMTP. Если письма не приходят, сначала исправьте SMTP, а не создавайте новые пространства и пользователей.

После первого входа настройте название портала, описание, логотип, статусы публикаций и правила модерации. Полезно сразу создать статусы Запланировано, В работе, Реализовано и Не планируется. Это делает обратную связь прозрачной: пользователи видят, что идеи не исчезают без ответа.

Проверка работоспособности

Проверьте HTTPS-заголовки и HTTP-перенаправление с самого сервера. В норме запрос к HTTP должен вернуть перенаправление 308 или 301, а HTTPS — код 200, 302 или 303 в зависимости от состояния первичной настройки.


# Проверьте HTTP-перенаправление, HTTPS и состояние контейнеров
curl -I http://feedback.example.com
curl -I https://feedback.example.com
docker compose ps
docker inspect --format='{{.State.Health.Status}}' fider-db

Проверьте логи отправки писем после регистрации тестового пользователя или отправки приглашения. Успешное SMTP-соединение не всегда означает доставку: проверьте также папку входящих, спам и журналы SMTP-провайдера.


# Отфильтруйте журналы приложения по почтовым и SMTP-сообщениям
cd /opt/fider
docker compose logs --since=15m fider | grep -iE 'smtp|mail|email|error'

Для хорошей доставляемости настройте DNS-записи почтового домена: SPF, DKIM и DMARC. Если отправитель — [email protected], домен example.com должен быть подтверждён у SMTP-провайдера. Иначе письма могут попадать в спам, даже если Fider подключается к SMTP без ошибок.

Бэкапы и обслуживание

Схема: Бэкапы и обслуживание
Схема: Бэкапы и обслуживание

Docker volume не является резервной копией. Если диск VPS выйдет из строя, случайно удалится том или база будет повреждена, вернуть данные без внешнего бэкапа будет невозможно. Минимальная стратегия для Fider — ежедневный логический дамп PostgreSQL, копия конфигурации и отправка архива за пределы основного сервера.

Что нужно сохранять

  • Дамп PostgreSQL — все пользователи, предложения, голоса, комментарии и системные настройки.
  • /opt/fider/docker-compose.yml — описание инфраструктуры.
  • /opt/fider/.env — секреты, SMTP-реквизиты и доменное имя.
  • /opt/fider/caddy/Caddyfile — настройки reverse proxy.
  • Docker volume Caddy — сертификаты и данные ACME. Их можно перевыпустить, но сохранение ускоряет восстановление.
  • Документация с DNS-записями, способом доступа к SMTP и процедурой восстановления.

Не стоит рассчитывать только на snapshot VPS. Снимки полезны для быстрого отката, но они обычно находятся в той же инфраструктуре, что и сервер. Правило 3-2-1 остаётся актуальным: минимум три копии данных, на двух разных носителях, одна копия вне основного сервера.

Скрипт ежедневного резервного копирования

Следующий скрипт создаёт сжатый дамп базы, архивирует конфигурацию и отправляет каталог в S3-совместимое хранилище через Restic. Restic шифрует данные на стороне сервера до отправки. Можно использовать Backblaze B2 S3, Wasabi, MinIO на отдельном сервере или другое совместимое объектное хранилище.


# Установите Restic и инструменты для архивирования
sudo apt install -y restic tar

Создайте файл с параметрами Restic. Значения доступа к S3 должны иметь права только на запись и чтение нужного бакета, без доступа к другим проектам. Файл также содержит пароль шифрования репозитория: потеря этого пароля безвозвратно делает резервные копии нечитаемыми.


# Создайте защищённый файл окружения для Restic и S3-хранилища
sudo tee /etc/fider-restic.env <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example-storage.net/fider-backups"
export RESTIC_PASSWORD="CHANGE_TO_A_LONG_RESTIC_REPOSITORY_PASSWORD"
export AWS_ACCESS_KEY_ID="S3_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="S3_SECRET_KEY"
EOF

sudo chmod 600 /etc/fider-restic.env

Инициализируйте удалённый репозиторий только один раз. После этого Restic создаст структуру для зашифрованных snapshots. Выполняйте команду под пользователем, который будет запускать бэкап; в примере это root через cron, потому что файл окружения находится в /etc.


# Создайте новый зашифрованный репозиторий Restic в удалённом S3-бакете
sudo bash -c 'source /etc/fider-restic.env && restic init'

Создайте скрипт. Он использует pg_dump внутри контейнера PostgreSQL, поэтому не требует установки PostgreSQL-клиента на хост. Скрипт хранит локальные дампы семь дней, а Restic применяет отдельные правила хранения удалённых snapshots.


#!/usr/bin/env bash
set -euo pipefail

APP_DIR="/opt/fider"
BACKUP_DIR="${APP_DIR}/backups"
DATE="$(date +%F_%H-%M-%S)"
DUMP_FILE="${BACKUP_DIR}/fider_${DATE}.sql.gz"
CONFIG_FILE="${BACKUP_DIR}/fider_config_${DATE}.tar.gz"

mkdir -p "${BACKUP_DIR}"

cd "${APP_DIR}"

docker compose exec -T db sh -c \
  'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" --format=plain' \
  | gzip -9 > "${DUMP_FILE}"

tar -czf "${CONFIG_FILE}" \
  "${APP_DIR}/docker-compose.yml" \
  "${APP_DIR}/.env" \
  "${APP_DIR}/caddy/Caddyfile"

source /etc/fider-restic.env

restic backup "${DUMP_FILE}" "${CONFIG_FILE}" --tag fider
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

find "${BACKUP_DIR}" -type f -mtime +7 -delete

Сохраните код как /opt/fider/scripts/backup.sh, сделайте его исполняемым и выполните вручную. Первый запуск важен: он показывает, есть ли доступ к Docker, S3-бакету и достаточно ли места на диске.


# Установите права на скрипт и выполните тестовый бэкап вручную
sudo chmod 700 /opt/fider/scripts/backup.sh
sudo /opt/fider/scripts/backup.sh
sudo bash -c 'source /etc/fider-restic.env && restic snapshots'

Добавьте задачу в root-cron, например ежедневно в 03:25. Время выбирайте вне периодов высокой активности. Вывод будет записываться в журнал; если на сервере не настроена локальная почта, удобнее перенаправить сообщения cron в централизованную систему мониторинга.


# Добавьте ежедневный запуск резервного копирования в root-cron
sudo crontab -e

25 3   * /opt/fider/scripts/backup.sh >> /var/log/fider-backup.log 2>&1

Проверка восстановления

Бэкап считается рабочим только после тестового восстановления. Раз в квартал создайте временный VPS или отдельный Docker-проект, скачайте snapshot Restic, поднимите чистую PostgreSQL-базу и импортируйте дамп. Проверьте, что видны пространства, идеи и пользователи.


# Пример восстановления SQL-дампа в чистую базу PostgreSQL
gunzip -c fider_YYYY-MM-DD_HH-MM-SS.sql.gz | \
docker compose exec -T db psql -U fider -d fider

При реальном восстановлении сначала остановите Fider, восстановите базу в пустой PostgreSQL-контейнер, верните файлы конфигурации и только затем запускайте приложение. Не импортируйте дамп поверх работающей production-базы без чёткого плана: это может создать несогласованные данные.

Обновления Fider, PostgreSQL и Docker

Для Fider обычно подходит модель короткого maintenance window. Обновление занимает несколько минут, но перед ним обязательно сделайте бэкап и прочитайте release notes. Особенно внимательно относитесь к major-обновлениям PostgreSQL: их нельзя выполнять простой заменой тега контейнера, потому что формат каталога данных между major-версиями меняется.


# Создайте бэкап, загрузите свежие образы и безопасно пересоздайте контейнеры
cd /opt/fider
sudo /opt/fider/scripts/backup.sh
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 fider

Не запускайте бездумно docker system prune -a на production-сервере. Команда может удалить образы, которые нужны для быстрого отката. Вместо этого периодически просматривайте использование Docker и удаляйте только неиспользуемые слои после подтверждения.


# Проверьте объём Docker-данных и удалите только безопасно неиспользуемые ресурсы
docker system df
docker image prune -f

Обновления Ubuntu устанавливайте еженедельно или ежемесячно после просмотра списка пакетов. Для небольшого Fider-инстанса допустимо плановое окно в 15–30 минут. При необходимости перезагрузки ядра сначала убедитесь, что бэкап завершён, затем перезагрузите сервер и проверьте контейнеры.

Troubleshooting и FAQ

Почему Caddy не получает SSL-сертификат и в логах есть ACME error?

Сначала проверьте DNS: команда getent hosts feedback.example.com должна возвращать публичный IP вашего VPS. Затем убедитесь, что в UFW открыты порты 80 и 443, а в панели провайдера нет дополнительного firewall. Проверяйте доступность с внешней сети, а не только с сервера. Также убедитесь, что для домена нет конфликтующей записи AAAA: если IPv6 указан, но не настроен на сервере, центр сертификации может пытаться подключиться по IPv6 и завершить проверку ошибкой.

Fider открывается, но выдаёт ошибку подключения к базе данных. Что проверить?

Посмотрите журналы контейнеров командами docker compose logs db и docker compose logs fider. Чаще всего проблема в несовпадении POSTGRES_PASSWORD и строки DATABASE_URL, либо база уже была создана с другим паролем. Изменение пароля в .env не меняет пароль существующего пользователя PostgreSQL автоматически. Если инстанс новый и данных нет, удалите volume и создайте его заново; если данные уже есть, меняйте пароль через SQL-команду внутри PostgreSQL.

Почему после регистрации не приходят письма от Fider?

Проверьте параметры EMAIL_SMTP_HOST, порт, логин, пароль и адрес EMAIL_NOREPLY. Для большинства провайдеров порт 587 требует STARTTLS, что включено в примере конфигурации. Посмотрите логи приложения по словам smtp и email. Если SMTP-соединение успешно, но письмо не доставлено, проверьте спам, журналы провайдера, SPF, DKIM и DMARC. Адрес отправителя должен принадлежать подтверждённому домену или sender identity.

Контейнер Fider постоянно перезапускается. Как найти причину?

Выполните docker compose ps, затем docker compose logs --tail=200 fider. Ищите первую ошибку перед перезапуском: обычно это неверная строка подключения к PostgreSQL, отсутствующая обязательная переменная окружения, ошибка миграции или недостаток памяти. Проверьте free -h и dmesg -T | grep -i oom. Если ядро завершило процесс из-за нехватки памяти, увеличьте RAM VPS до 2–4 ГБ и временно добавьте swap.

Какой VPS-конфиг минимально подойдёт для Fider?

Для тестовой или небольшой закрытой доски минимально подойдёт 1 vCPU, 2 ГБ RAM и 20–25 ГБ SSD. Конфигурация с 1 ГБ памяти возможна только как временный стенд: PostgreSQL, Docker и система будут работать почти без запаса. Для production с SMTP, HTTPS, бэкапами и несколькими сотнями пользователей разумнее начать с 2 vCPU, 4 ГБ RAM и 40 ГБ NVMe. Учитывайте рост базы и храните минимум 15–20% диска свободным.

Что выбрать — VPS или dedicated для этой задачи?

Для Fider почти всегда достаточно VPS. Сервис создаёт относительно небольшую нагрузку, а VPS проще масштабировать, резервировать и переносить. Dedicated оправдан при большом числе активных пользователей, десятках сопутствующих сервисов, собственной почтовой инфраструктуре или требованиях к гарантированным физическим ресурсам. На практике при росте Fider сначала полезнее вынести PostgreSQL на отдельный сервер или managed-базу, чем покупать выделенную машину только для веб-приложения.

Можно ли открыть PostgreSQL на порт 5432 для подключения с домашнего компьютера?

Технически можно, но это плохая практика для постоянной работы. В текущем Compose-файле база изолирована во внутренней сети Docker и не доступна извне. Для диагностики используйте docker compose exec db psql на сервере или SSH-туннель. Если внешнее подключение действительно необходимо, ограничьте доступ конкретным IP-адресом в firewall, используйте отдельного пользователя с минимальными правами и TLS. Никогда не открывайте PostgreSQL для всего интернета без ограничений.

Как перенести Fider на другой VPS без потери данных?

Подготовьте новый сервер, установите Docker и создайте такой же каталог /opt/fider. Скопируйте Compose-файл, Caddyfile и .env через защищённый канал, восстановите последний SQL-дамп в чистую PostgreSQL-базу, затем запустите контейнеры. После проверки измените DNS-запись домена на новый IP. Перед переключением снизьте TTL DNS до 300 секунд. Старый сервер не удаляйте несколько дней: оставьте его выключенным или закрытым firewall до подтверждения стабильной работы нового инстанса.

Выводы и следующие шаги

Схема: Выводы и следующие шаги
Схема: Выводы и следующие шаги

Теперь у вас есть self-hosted Fider на VPS: приложение работает за HTTPS, хранит данные в PostgreSQL, отправляет уведомления по SMTP и регулярно создаёт зашифрованные резервные копии. Такая установка подходит для публичной доски идей, закрытого корпоративного портала или канала обратной связи SaaS-продукта.

  1. Создайте первое пространство, настройте статусы предложений и опишите правила публикации идей.
  2. Проверьте регистрацию, голосование, комментарии и доставку писем с тестового пользовательского аккаунта.
  3. Добавьте мониторинг доступности HTTPS, места на диске, статуса Docker-контейнеров и результата ночного бэкапа.
  4. При росте нагрузки вынесите PostgreSQL на отдельный сервер, добавьте централизованный сбор логов и зафиксируйте версии Docker-образов.

Был ли этот гайд полезен?

Ваш отзыв помогает нам улучшать гайды.

Поделиться записью:

Отправьте гайд тому, кому он может пригодиться.

Telegram VKVK WhatsApp Facebook LinkedIn XX

установка fider на vps: self-hosted сбор обратной связи, ssl и smtp
support_agent
Valebyte Support
Usually replies within minutes
Hi there!
Send us a message and we'll reply as soon as possible.