Як розгорнути SimpleX SMP relay на VPS

Що робить self-hosted SimpleX chat server

Щоб розгорнути self-hosted SimpleX chat server, на VPS потрібно запустити один daemon: smp-server — relay для SMP (simplex messaging protocol). Він зберігає черги повідомлень, у які ваші контакти записують повідомлення та з яких їх читають. Другий, необов’язковий daemon під назвою xftp-server ретранслює передавання файлів. Обидва компоненти походять з одного проєкту simplexmq, і кожен із них складається з одного binary-файлу, config-файлу та append-only log.

Цей матеріал призначений для оператора, а не для користувача застосунку. Relay не зберігає облікових записів, списків контактів або історії чатів. Він зберігає черги, певний обсяг недоставлених ciphertext і certificate, який його ідентифікує. Від оператора потрібні доступність сервісу, невеликий обсяг дискового простору та контроль metadata, що проходять через ваш сервер.

Усі наведені нижче команди, шляхи, порти та flags взято з офіційної документації проєкту: сторінки хостингу SMP server, сторінки XFTP server і документа про безпеку протоколу. Якщо має значення певне число, поруч із ним зазначено сторінку, з якої його взято.

Чому мережі без ідентифікаторів користувачів усе одно потрібні ретранслятори

У SimpleX немає імен користувачів, номерів телефонів і ідентифікаторів облікових записів. Контакт — це односпрямована черга: адреса на певному ретрансляторі, до якої одна сторона записує повідомлення, а інша їх зчитує. Два ваші контакти не мають спільного ідентифікатора, за яким сервер міг би їх пов’язати.

Однак ці черги потрібно десь зберігати з простої причини. Два телефони рідко бувають онлайн в одну й ту саму секунду. Щось має прийняти повідомлення зараз і зберігати його, доки інший пристрій не запитає його. Це і є основне завдання SMP-ретранслятора. Це також означає, що два пристрої ніколи не з’єднуються безпосередньо один з одним, тому жоден із них не дізнається IP-адреси іншого. Натомість ретранслятор приховує цю інформацію.

Ім’я хоста ретранслятора є частиною адреси черги, тому воно міститься в кожному посиланні-запрошенні, яке ви надсилаєте через цей ретранслятор. Пам’ятайте про це, коли читатимете модель загроз наприкінці.

Що relay може і чого не може бачити

Проєкт описує цю модель загроз у protocol/security.md. Її варто прочитати перед інсталяцією, оскільки після виконання цього посібника relay буде під вашим контролем. Relay, зокрема повністю контрольований зловмисником, не може дізнатися вміст або тип повідомлень, непомітно додати, дублювати чи пошкодити окремі повідомлення, а також зламати end-to-end encryption за допомогою активної атаки.

На цій самій сторінці перелічено, що relay може робити. Він може дізнатися, коли одержувач queue перебуває в мережі. Він може підрахувати кількість повідомлень, що проходять через queue. Він може дізнатися IP-адресу одержувача. Він може видалити всі майбутні повідомлення в queue або повідомляти неправдивий стан цієї queue.

Отже, розподіл відповідальності чіткий. За конфіденційність відповідає client, і self-hosting на неї не впливає. За метадані та доступність відповідає оператор relay, а self-hosting передає обидві ці функції вам.

Що потрібно підготувати

• VPS з Ubuntu 22.04 або 24.04. Проєкт публікує бінарні файли релізів, зібрані саме для цих двох версій, під x86-64 і aarch64.
• Доменне ім’я із записом A, що вказує на VPS, а також записом AAAA, якщо у вас є IPv6. У документації як приклад використовується smp1.example.com.
• Доступ root або sudo і відкритий другий SSH-сеанс на час налаштування брандмауера.
• Місце за межами сервера для зберігання резервної копії, оскільки каталог конфігурації є ідентифікатором сервера.

На ARM-інстансі використовуйте ресурс aarch64 замість x86-64. В іншій частині цього посібника нічого змінювати не потрібно, а вибір між ARM- і x86-тарифами VPS залежить від ціни та швидкодії окремого ядра, а не від того, чи працює це програмне забезпечення.

Встановіть зафіксований реліз, а не "latest"

Проєкт постачає інсталяційний скрипт, який завантажує поточний реліз і реєструє команду simplex-servers-update. Це працює. Однак версію все одно слід зафіксувати: якщо бінарний файл relay змінюється без вашого контролю, причину збою стає важко визначити.

Станом на August 2026 поточний реліз simplexmq — v6.5.0, опублікований 29 April 2026. Перевірте сторінку релізів, щоб вибрати потрібний тег, і використовуйте цей тег у всіх командах нижче.

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp не встановлює пароль, тому ніхто не входить безпосередньо як smp. Створіть ці два каталоги вручну до виконання будь-яких інших дій, оскільки /etc/opt належить root і має режим 755. Через це користувач smp не має доступу для запису у власний каталог конфігурації.

VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-server

Порівняйте цей хеш із контрольними сумами SHA2-256, опублікованими в примітках до релізу з таким самим тегом. Проєкт також підписує контрольні суми релізів ключем SimpleX Chat FB44AF81A45BDE327319797C85107E357D4A17FC, описаним на сторінці сервера. Тому можна перевірити підпис, а не довіряти сторінці, з якої ви отримали хеш.

sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server

Свідомо встановіть файл із власником root. Сервіс працює від імені smp, тому компрометація сервісу не дасть змоги перезаписати бінарний файл, з якого він запускається.

Ініціалізуйте сервер і збережіть два секрети, які він виведе

sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"

• --store-log (-l) записує журнал черг лише в режимі дописування до /var/opt/simplex/smp-server-store.log, тому relay зберігає стан після перезапуску. Без цього перезапуск видаляє всі черги, через що перестають працювати всі контакти, маршрутизовані через ваш relay.
• --daily-stats (-s) записує лічильники у форматі CSV до /var/opt/simplex/smp-server-stats.daily.log.
• --fqdn додає ваш домен до згенерованого сертифіката. Якщо у вас немає домену, використайте --ip.
• --no-password дає змогу будь-кому створювати чергу на вашому relay. Щоб зробити relay приватним, після ініціалізації задайте create_password у [AUTH] в /etc/opt/simplex/smp-server.ini, а не передавайте --password тут, оскільки командний рядок видно в історії shell і списку процесів під час виконання.

Init генерує сертифікат і виводить два значення, які потрібно зберегти. Перше — fingerprint, рядок у форматі base64, який також записується до /etc/opt/simplex/fingerprint. Друге — повна адреса сервера: fingerprint разом із вашим hostname. Скопіюйте обидва значення зараз.

Init також створює /etc/opt/simplex/ca.key. Документація рекомендує перемістити цей файл до offline-сховища. Причина важлива: клієнти фіксують fingerprint цього центру сертифікації, тому будь-хто, хто має ca.key, може видати новий сертифікат сервера, який ваші клієнти приймуть як сертифікат вашого сервера. Цей файл знадобиться лише для подальшої ротації сертифіката сервера за допомогою smp-server cert.

Вважайте init одноразовим кроком. Fingerprint у вашій адресі походить від згенерованого центру сертифікації, тому повторна генерація цього центру створить іншу адресу, а вже надана вами адреса перестане відповідати серверу.

Запустіть його через systemd від імені непривілейованого користувача

Запишіть /etc/systemd/system/smp-server.service саме так, як наведено в документації:

[Unit]
Description=SMP server systemd service

[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity

[Install]
WantedBy=multi-user.target

Upstream unit також містить AmbientCapabilities=CAP_NET_BIND_SERVICE. Цей рядок потрібен, оскільки процес працює від імені smp, а порти з номерами менше 1024 закриті для процесів, що працюють не від root. Без цього daemon не зможе прив’язатися до портів 80 або 443. Додайте цей параметр, якщо обслуговуєте ці порти. LimitNOFILE=65535 важливий, оскільки кожен підписаний клієнт утримує відкрите TCP-з’єднання, а стандартний ліміт значно нижчий за потреби завантаженого relay. ExecStopPost копіює журнал store у файл .bak під час кожної зупинки. Це дає одну безкоштовну точку для rollback.

sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server

Під час успішного запуску в журналі з’являється адреса сервера. Потім переконайтеся, що sockets справді відкриті:

sudo ss -tlnp | grep -E ':(443|5223)'

В обох рядках має бути вказано smp-server. Запуск daemon під власним обліковим записом без прав sudo — це той самий підхід, що й у випадку окремих облікових записів для кожного сервісу на VPS. Саме він не дає помилці в одному мережевому daemon перетворитися на root shell.

Які порти відкрити, а який залишити закритим

У документації наведено три порти: 5223/tcp, 443/tcp і 80/tcp. Порт 5223 — це транспорт SMP. Поставлений разом файл конфігурації задає port: 5223,443 у [TRANSPORT], тому той самий протокол також відповідає на 443. Це важливо, оскільки багато мереж з обмеженнями дозволяють вихідний трафік лише через 443. Порт 80 потрібен лише для необов’язкової інформаційної сторінки та перенаправлення на HTTPS.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable

Не відкривайте 5224. Це порт керування. Документація звертається до нього з самого сервера за допомогою nc 127.0.0.1 5224. Він виводить стан сервера та видаляє черги, тому має бути доступний лише через loopback. Паролі адміністратора та користувача потрібно задати в [AUTH]. Якщо ви вперше працюєте з цим інструментом, у матеріалі основи ufw на VPS описано порядок правил і способи не втратити доступ до сервера.

Є ще один параметр керування, який часто спричиняє проблеми. Більшість провайдерів використовує мережевий firewall у панелі керування окремо від ufw на сервері. Порт може бути відкритий у ufw, але трафік до нього все одно буде відкинуто ще до того, як він досягне сервера.

Адреса сервера, яка потрібна вашим клієнтам

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

Цей рядок містить усю конфігурацію на стороні клієнта. Вставте його в налаштування сервера в застосунку або запропонуйте користувачу відсканувати QR-код, який застосунок для нього відображає. У документації зазначено, що QR-код містить пароль, тому користувач, який його відсканує, також зможе отримувати повідомлення через ваш сервер.

Є одна задокументована особливість, яка дивує майже всіх. Додавання вашого сервера в застосунку впливає лише на контакти, створені після цього. Наявні контакти залишаються на relay-серверах, на яких було створено їхні черги, і не переносяться. Саме тому не можна вимкнути relay наступного дня після його заміни.

Додавання файлового ретранслятора XFTP

XFTP (SimpleX file transfer protocol) — файлова частина мережі. Це окремий daemon із власною адресою. Згідно з анонсом XFTP від проєкту, ретранслятори взагалі не мають метаданих файлів. Вони бачать лише окремі фрагменти розміром 256kb, 1mb або 4mb. Доступ до них авторизується анонімними обліковими даними. Відправник може розподілити фрагменти одного файлу між кількома ретрансляторами. Тому ваш сервер зберігає фрагменти, а не файли.

sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"

Конфігурація зберігається в /etc/opt/simplex-xftp/, стан — у /var/opt/simplex-xftp/, а фрагменти файлів — у каталозі, який указує -p. Структура systemd unit така сама, із User=xftp і ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS. Init виводить адресу xftp:// у тому самому форматі, що й адресу SMP, а власний fingerprint зберігається в /etc/opt/simplex-xftp/fingerprint.

Потрібно заздалегідь врахувати конфлікт портів. Документований порт XFTP server — 443, і конфігурація SMP також містить 443. Два процеси не можуть прив’язати один порт на одній адресі, тому на одному VPS доведеться змінити один із параметрів. Найпростіше встановити port: 5223 у секції SMP [TRANSPORT] і залишити 443 файловому ретранслятору. Недолік цього рішення — клієнти з мереж із жорсткими обмеженнями втратять можливість використовувати fallback через 443. Альтернативи — додати другу IP-адресу на тому самому VPS або використати другий VPS.

Розраховуйте квоту реалістично. -q '20gb' — це обсяг дискового простору, який ви фактично можете надати. Файловий ретранслятор споживає основну частину дискового простору та пропускної здатності. Ретранслятор повідомлень майже не використовує ні те, ні інше.

Що зберігається на диску і що відновлює резервна копія

Важливі два каталоги. /etc/opt/simplex/ — це ідентифікаційні дані: smp-server.ini, сертифікат і ключ сервера, ca.key та fingerprint. /var/opt/simplex/ — це стан: smp-server-store.log містить черги, а якщо restore_messages: on — недоставлені повідомлення, а також файл щоденної статистики.

sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-server

Чітко визначте призначення цього архіву. Це не архів повідомлень: елементи в черзі є зашифрованими даними для ключів, яких relay ніколи не мав, а штатна конфігурація [STORE_LOG] у будь-якому разі видаляє повідомлення через 21 days. Це копія ідентифікаційних даних сервера, включно з ca.key, тому будь-хто, хто отримає цей файл, зможе видати себе за ваш relay перед вашими контактами. Зашифруйте його та зберігайте за межами сервера.

Перевага проявляється під час відновлення. Відновіть /etc/opt/simplex на новому VPS, спрямуйте на нього те саме DNS-ім’я, і fingerprint не зміниться, тому всі видані вами адреси й надалі працюватимуть. Якщо втратити цей каталог, відновлення неможливе: нова інсталяція означає новий fingerprint, а отже, нову адресу. Це означає, що всі контакти, маршрутизовані через ваш relay, буде втрачено.

TLS: два сертифікати для різних завдань

Транспорт SMP не використовує загальнодоступний центр сертифікації. Init створює приватний центр сертифікації та сертифікат сервера, а відбиток цього центру сертифікації передається в адресі сервера. Клієнт порівнює дані, які надає сервер, із цим зафіксованим відбитком. Саме це, за описом проєкту, захищає з’єднання між клієнтом і сервером від атак «людина посередині». На цьому порту не потрібно запускати клієнт ACME (automatic certificate management environment), а ротація виконується вручну за допомогою smp-server cert з установленим параметром SMP_SERVER_CFG_PATH.

Необов’язкова інформаційна сторінка використовує інший сертифікат. Її розділ [WEB] містить назви static_path, https: 443, cert: /etc/opt/simplex/web.crt і key: /etc/opt/simplex/web.key. Браузер не довіряє вашому приватному центру сертифікації, тому саме тут потрібен сертифікат від загальнодовіреного центру сертифікації. У швидкому запуску Docker з документації перед сервером саме для цього використовується Caddy, який автоматично випускає сертифікат.

Підключення до relay через Tor

Документація містить розділ про Tor, у якому Tor встановлюється з репозиторію Tor Project і в /etc/tor/torrc додається hidden service:

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

Уважно прочитайте два рядки режиму. Single hop і non-anonymous означають, що власне розташування relay не приховується. Onion-адреса забезпечує швидке підключення та дає клієнтам спосіб підключатися так, щоб їхня IP-адреса ніколи не розкривалася вам, але сам сервер залишається доступним для пошуку за публічною IP-адресою. Onion hostname із /var/lib/tor/simplex-smp/hostname додається в кінці адреси сервера після коми. Якщо потрібно приховати також розташування сервера, потрібна інша конфігурація; у розділі розгортання справжнього onion service на VPS описано відповідні компроміси. Відмінності в тому, що приховує кожен інструмент, розглянуто в розділі Tor порівняно з VPN, і вони безпосередньо стосуються цього випадку.

Модель загроз: що змінює self-hosting

Що це дає. Метадані — які черги існують, коли їх читають і які адреси підключаються — зберігаються на машині під вашим контролем, а ви визначаєте, як довго їх зберігати. Ви також не входите до великого пулу, дані з якого можна запросити одним запитом.

Чого це не дає, без зайвих уточнень:

• Шифрування не змінюється. Повідомлення були зашифровані end-to-end до того, як ви розгорнули цей сервіс, і залишаються зашифрованими end-to-end після цього. Self-hosting — це рішення щодо метаданих, а не криптографії.
• Ваш VPS-провайдер бачить трафік до вашої IP-адреси та зберігає ваші платіжні дані. Ви перенесли довіру від оператора сервісу обміну повідомленнями до хостинг-провайдера. Ви її не усунули.
• Ваш relay — це невелика група користувачів. Якщо він обслуговує одне домогосподарство, підключення до нього ідентифікує це домогосподарство, а його hostname міститься в кожному invitation link, який ви надсилаєте через нього. Завантажений публічний relay краще приховує вас саме в цьому аспекті, і це є реальним компромісом.
• Тепер доступність залежить від вас. Переповнений диск або несправний сервер означає, що повідомлення перестануть доставлятися, а ваші контакти не зможуть обійти вас під час маршрутизації.

Це саме міркування стосується будь-якого приватного сервісу, який ви розміщуєте на власному сервері, незалежно від того, чи це цей relay, чи WireGuard VPN на власному VPS. Ви обираєте, яка сторона бачить метадані. Ви не робите їх невидимими.

Коли сервіс не працює

Сервіс запускається й одразу зупиняється. Перегляньте sudo journalctl -u smp-server -n 50. Помилка прив’язування вказує порт, який не вдалося зайняти. Потім виконайте sudo ss -tlnp | grep :443, щоб визначити процес, який уже використовує цей порт. На щойно налаштованому сервері це зазвичай nginx, Caddy або XFTP server, який ви встановили годину тому.

Init не може записати конфігурацію. Виконання smp-server init від імені користувача smp до появи /etc/opt/simplex спричиняє помилку доступу, оскільки /etc/opt належить root. Спочатку створіть каталог із правильним власником, а потім повторно запустіть init.

Клієнти не можуть підключитися до relay. Перевірте, чи ім’я розв’язується в правильну адресу, за допомогою dig +short smp1.example.com. Потім перевірте порт із ноутбука, а не із сервера: nc -vz smp1.example.com 5223. Якщо зовнішнє підключення не вдається, а ss показує, що сокет відкритий на сервері, проблема, імовірно, у мережевому firewall провайдера. Це окремий засіб керування, не пов’язаний із ufw.

Контакт не може підключитися через ваш relay. Відбиток у надісланій вами адресі має збігатися з поточним вмістом /etc/opt/simplex/fingerprint. Якщо ви задали create_password у [AUTH], адреса також має містити цей пароль. Інакше клієнту заборонено створювати чергу.

Після додавання сервера в застосунку нічого не перемістилося. Це очікувана поведінка. Новий relay використовують лише нові контакти. Наявні контакти продовжують використовувати черги, які вони вже мають.

FAQ

Чи робить self-hosting сервера SimpleX мої повідомлення безпечнішими?

Ні, і це передбачено архітектурою. SimpleX шифрує повідомлення наскрізним шифруванням між пристроями, тому relay не має ключів, незалежно від того, хто ним керує. Self-hosting змінює того, хто бачить метадані цих повідомлень: які черги існують, коли їх читають і які IP-адреси підключаються. Це рішення щодо метаданих. Якщо причина self-hosting — сильніше шифрування, воно вже було доступне.

Що насправді може бачити оператор relay SimpleX?

Це описано в protocol/security.md проєкту. Relay не може читати вміст або типи повідомлень, непомітно змінювати окремі повідомлення чи зламати наскрізне шифрування шляхом активної атаки. Він може бачити, коли одержувач черги перебуває онлайн, підраховувати повідомлення, що проходять через чергу, дізнатися IP-адресу одержувача, видаляти майбутні повідомлення з черги або повідомляти неправдивий стан цієї черги. Саме такі повноваження ви отримуєте, коли relay належить вам.

Чи потрібні мені доменне ім’я та TLS-сертифікат?

Для придатної до використання конфігурації потрібен домен, а smp-server init приймає --ip, якщо у вас справді немає домену. Для порту обміну повідомленнями не потрібен сертифікат від публічного центру сертифікації: init створює власний центр сертифікації, а клієнт фіксує відбиток, указаний у вашій адресі smp://. Сертифікат, якому довіряє загальнодоступна інфраструктура, потрібен лише для додаткової вебсторінки з інформацією, налаштованої як cert і key у розділі [WEB] файлу smp-server.ini.

Що станеться, якщо я втрачу /etc/opt/simplex?

Усі адреси, які ви надали, перестануть працювати. У цьому каталозі зберігається центр сертифікації, відбиток якого вбудовано в адресу вашого сервера, тому після повторного розгортання буде створено інший відбиток, а отже, і інший сервер. Контакти, чиї черги розміщені на цьому relay, не можна відновити на стороні клієнта. Створюйте резервну копію каталогу в зашифрованому вигляді та зберігайте її за межами сервера. Зберігайте ca.key офлайн відповідно до документації, оскільки той, хто має цей файл, може видати себе за ваш relay.

Чи можна запустити SMP relay і файловий relay XFTP на одному VPS?

Так, але потрібно усунути один конфлікт. Документований порт сервера XFTP — 443, а стандартна конфігурація SMP містить port: 5223,443, тому обидва сервіси намагаються використовувати один і той самий сокет. Призначте порт 443 одному з них: установіть port: 5223 для SMP-сервера або перенесіть файловий relay на другу IP-адресу чи другий VPS. Також установіть квоту сховища відповідно до фактично доступного дискового простору, оскільки саме файловий relay споживає диск і пропускну здатність мережі.