Встановлення Fider на VPS: self-hosted збір зворотного зв’язку, SSL і SMTP

Що ми налаштовуємо і навіщо

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 виправдане, якщо вам важливі контроль над даними, власний домен, передбачувана вартість, можливість створити закриту внутрішню дошку або дотриматися вимог щодо географії зберігання даних. Ви самостійно відповідаєте за оновлення та бекапи, але отримуєте повний контроль над інфраструктурою.

Що знадобиться до початку роботи

• 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-конфігурація потрібна для цього завдання

Fider не є ресурсоємним застосунком, якщо йдеться про кілька сотень або тисяч зареєстрованих користувачів і помірну активність. Основне споживання пам'яті створюють PostgreSQL, Docker-контейнери та файловий кеш операційної системи. Тому 1 ГБ RAM формально може запустити сервіс, але для стабільної експлуатації краще не використовувати настільки мінімальну конфігурацію.

Практичний стартовий варіант — 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 хвилин. Якщо потрібне перезавантаження ядра, спочатку переконайтеся, що бекап завершено, потім перезавантажте сервер і перевірте контейнери.

Усунення несправностей і 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-образів.