Установка n8n на свой сервер — это восемь шагов и примерно 7,5 часа чистого времени, если вы уже когда-нибудь арендовали VPS и настраивали на нём HTTPS. Ещё 2,5 часа уйдёт на первый рабочий сценарий. Дальше начинается то, о чём инструкции обычно молчат: резервные копии, обновления версий и 40 часов администрирования в год, которые кто-то должен отработать.
Тема стала актуальной для российских компаний по простой причине. Zapier и Make (ранее Integromat) по состоянию на сентябрь 2026 года для российских компаний недоступны, оплата облачной подписки самого n8n из России тоже проблемна, а процессы никуда не делись. Остаются два рабочих варианта: российская облачная платформа с оплатой в рублях либо своя установка на своём сервере. Как выбирать между четырьмя путями замены, мы разбирали отдельно; эта статья — про то, что происходит, если выбран свой сервер.
Ниже — полный путь от аренды сервера до работающего сценария, с проверкой после каждого шага, и честная арифметика стоимости владения. Главный вывод из этой арифметики окажется неудобным для жанра: на объёмах малого бизнеса своя установка обычно дороже облака, и покупают её не ради экономии. Все цены и статусы сервисов — по состоянию на сентябрь 2026 года.
Что решается до того, как вы возьмёте сервер
Три решения принимаются до первой команды в терминале, и переигрывать их потом дорого. Первое — где физически стоит сервер. Второе — какая конфигурация нужна. Третье — кто в компании становится владельцем этой установки и отвечает за неё, когда она встанет в субботу.
С площадкой всё определяется одним вопросом: проходят ли через сценарии персональные данные. Имя, телефон, адрес доставки, запись разговора — это персональные данные, и база с ними должна находиться в России. Требование локализации распространяется на любую систему, где эти данные оказываются, включая журнал прогонов вашего конструктора: там сохраняются входящие пакеты целиком, вместе с телефонами. Поэтому зарубежный хостинг для такой установки не рассматривается вообще, а не «нежелателен».
С конфигурацией правило простое: n8n держит данные текущего прогона в оперативной памяти. Сценарий, который тянет выгрузку на 200 000 строк одним узлом, кладёт установку на 4 ГБ независимо от того, сколько у неё процессорных ядер. Поэтому конфигурацию выбирают не по числу сценариев, а по самой тяжёлой единичной операции.
| Конфигурация | Цена в месяц | На что хватает | Где заканчивается |
|---|---|---|---|
| Стартовая: 2 vCPU, 4 ГБ, 40 ГБ NVMe, база в контейнере рядом | 2 400 ₽ | 5–7 сценариев, до 20 000 операций в месяц, лёгкие вложения | Крупные выгрузки, несколько тяжёлых прогонов одновременно |
| Рабочая: 4 vCPU, 8 ГБ, 80 ГБ NVMe | 4 500 ₽ | 10–15 сценариев, до 90 000 операций в месяц, документы и файлы | История прогонов за год на том же диске съедает место |
| С отдельной базой: рабочая плюс управляемый PostgreSQL 2 vCPU, 4 ГБ | 4 500 ₽ + 3 000 ₽ | Парк от 15 сценариев, история прогонов за год, копии базы на стороне хостера | Дальше растёт не сервер, а требования к дежурству |
Дальше по тексту считаем стартовую конфигурацию: она закрывает задачи компании на 30–60 человек с пятью-семью сценариями. Более тяжёлый парк из двенадцати сценариев с потоком под 90 000 операций мы разбирали в отдельном материале — там и конфигурация другая, и стоимость владения выше.
Третье решение — про людей, и оно самое неудобное. У установки должен быть названный владелец: человек, чьё имя стоит в списке ответственных, к кому идут с вопросом «почему заявки не приходят» и кто получает сигнал мониторинга ночью. Не роль, не отдел, а конкретный сотрудник с фамилией. Второе имя в этом списке — заместитель на время отпуска, потому что сценарии не уходят в отпуск вместе с владельцем. Если оба имени назвать не получается, это уже ответ: своя установка вам пока не нужна, берите облачную платформу, где дежурство входит в подписку.
Проверить решение просто. Задайте себе три вопроса и ответьте на них вслух: кто пойдёт разбираться, если установка встанет в пятницу в 19:00; у кого есть доступ к серверу, кроме уволившегося в прошлом году системного администратора; где лежит запись о том, как всё это устроено, если владелец завтра сменит работу. Три невнятных ответа означают, что вы собираетесь построить систему, которая через год превратится в чёрный ящик, работающий по инерции. Как такие системы деградируют и во что обходится их реанимация, мы разбирали отдельно.
Карта связей в чертёжном стиле. В центре прямоугольник «VPS 2 vCPU / 4 ГБ / 40 ГБ, 2 400 ₽ в месяц», внутри него два вложенных блока: «n8n в контейнере» и «PostgreSQL в контейнере». Слева блок «обратный прокси и TLS-сертификат» со стрелкой снаружи внутрь, подпись на стрелке «443, только HTTPS». Снизу стрелка к блоку «объектное хранилище: резервные копии, 600 ₽ в месяц». Справа блок «внешний мониторинг доступности, 1 000 ₽ в месяц» со стрелкой-проверкой к прокси. Отдельно, вне контура сервера, маленький блок «менеджер секретов: ключ шифрования учётных данных» с пунктирной стрелкой и подписью «хранится не на сервере». Все подписи по-русски.
Программа работает на сервере, который арендует и администрирует ваша компания. Вы отвечаете за обновления, резервные копии, доступ и безопасность — и вы же единственный, у кого есть данные. Противоположность — облачная платформа, где всё это делает поставщик, а данные проходят через его контур.
n8n распространяется по Sustainable Use License: держать свою установку для внутренних задач компании можно, а перепродавать доступ к ней как услугу третьим лицам — нет. Для подавляющего большинства читателей это не ограничение вовсе, но если вы планируете предлагать сценарии своим клиентам как сервис, условия лицензии надо перечитать до начала работ: они менялись, и по состоянию на сентябрь 2026 года смотреть надо действующую редакцию, а не пересказ в статье.
Восемь шагов установки, с проверкой после каждого
Порядок важен: каждый следующий шаг опирается на результат предыдущего, а проверка после шага — единственный способ не искать потом ошибку сразу в восьми местах. Указанное время — для человека, который уже настраивал сервер хотя бы раз.
- 1Сервер и доступ по ключу — 1 час
Арендуйте VPS у российского хостера, заведите отдельного пользователя вместо работы под администратором, загрузите свой открытый ключ и отключите вход по паролю. Проверка: вы заходите по ключу, а попытка входа по паролю с другого компьютера отклоняется сервером.
- 2Домен и запись A — 30 минут
Заведите поддомен вида n8n.вашдомен.ru и направьте его на адрес сервера. Отдельный домен не нужен, поддомена рабочего достаточно. Проверка: имя резолвится в адрес вашего сервера с чужого компьютера, а не только из вашей сети.
- 3Файрвол — 30 минут
Закройте всё, кроме портов SSH, 80 и 443. Отдельно закройте порт, на котором позже будет слушать сам n8n: наружу он выходить не должен, только через прокси. Проверка: сканирование сервера снаружи показывает три открытых порта и ни одного лишнего.
- 4Обратный прокси и сертификат — 1 час
Поднимите обратный прокси, выпустите бесплатный сертификат Let's Encrypt и включите автопродление. Проверка: браузер показывает валидный сертификат, обращение по http автоматически уходит на https, а в календаре стоит напоминание проверить автопродление через 60 дней.
- 5Запуск в контейнерах — 2 часа
Опишите два сервиса: n8n и PostgreSQL. Данные обоих вынесите в отдельные тома на диске, а не внутрь контейнеров. Задайте базовый URL (иначе вебхуки будут выдавать внутренний адрес), часовой пояс и ключ шифрования учётных данных. Проверка: перезагрузите сервер целиком — оба контейнера должны подняться сами, без вашего участия.
- 6Первый вход и владелец — 30 минут
Сразу после первого запуска создайте учётную запись владельца и задайте длинный пароль. Пока владельца нет, интерфейс открыт любому, кто угадал адрес. Проверка: из режима инкогнито адрес отдаёт форму входа, а не готовый интерфейс с вашими сценариями.
- 7Ограничение доступа — 1,5 часа
Интерфейс должен быть доступен только из офисной сети или через VPN, а адреса вебхуков — из интернета, иначе формы перестанут работать. Это два разных правила на прокси, а не одно. Проверка: путь вебхука отвечает с постороннего адреса, корень интерфейса с того же адреса — не отвечает.
- 8Ключ шифрования в хранилище — 30 минут
Скопируйте ключ шифрования учётных данных в корпоративный менеджер секретов, а не в переписку и не в файл на том же сервере. Проверка: ключ достаётся из хранилища человеком, у которого нет доступа к серверу. Где вообще держать ключи и пароли компании, разбирали отдельно.
Итого 7,5 часа. У человека, который сервер до этого не держал, реалистичная оценка — 20–30 часов, растянутых на две-три недели, и это нормально: большая часть времени уйдёт не на установку, а на чтение про сертификаты, права на тома и поведение контейнеров при перезапуске.
Внутри установки лежат токены доступа к вашей CRM, почте и учётной системе — в зашифрованном виде, но расшифровываются они ключом с того же сервера. Открытый в интернет интерфейс без ограничения доступа означает, что через него читается и правится всё, к чему подключены сценарии. Это самая частая находка при аудите чужих установок: адрес не в индексе, но и не защищён, а внутри — рабочие подключения к боевым системам. Обратная ошибка не менее дорогая: ключ шифрования сохранён только на сервере, сервер погиб — резервная копия базы восстанавливается, но все подключения в ней превращаются в нечитаемый набор символов и заводятся заново руками.
Первый рабочий сценарий: заявка, журнал, уведомление
Правильный первый сценарий — не «hello world», а тот, который вы всё равно собирались собрать: приём заявки с формы сайта. Он проверяет разом вебхуки, запись в базу, исходящие запросы и поведение при ошибке. На сборку уходит около 2,5 часа вместе с проверками.
- 1Поставьте узел-вебхук и переведите его в тестовый режим. Отправьте одну заявку с настоящей формы и убедитесь, что данные пришли целиком: с русскими буквами, длинным комментарием и пустым необязательным полем.
- 2Сразу за вебхуком поставьте запись в свою таблицу или базу — до всех остальных узлов. Это главное правило приёма заявок: сначала сохранить у себя, потом отправлять дальше. Разбор того, почему порядок именно такой и что писать в журнал, — в опорной инструкции по связке формы с CRM.
- 3Добавьте узел отправки в CRM и узел уведомления ответственному в мессенджер. Проверьте, что в уведомлении есть то, по чему можно действовать: имя, телефон, текст обращения и источник, а не только слово «новая заявка».
- 4Добавьте ветку ошибки: если CRM не ответила, статус доставки в вашем журнале меняется на «не доставлено», а вам приходит отдельное оповещение. Проверка: временно подставьте неверный токен CRM и убедитесь, что заявка всё равно сохранилась у вас, а оповещение пришло.
- 5Переведите сценарий из тестового режима в рабочий и поменяйте адрес вебхука в форме. Боевой и тестовый адреса отличаются — забытая замена даёт самый обидный сбой: в интерфейсе всё зелёное, а заявки не приходят.
Схема процесса слева направо, чертёжный стиль. Блоки: «Вебхук формы» → «Запись в свой журнал заявок» → развилка на два блока: «CRM: создать сделку» и «Уведомление ответственному в мессенджер». От каждого из двух правых блоков вниз штриховая стрелка «ошибка» к общему блоку «статус: не доставлено, оповещение дежурному». Над первой стрелкой подпись «сначала к себе, потом наружу». Внизу подпись «сборка и проверка — 2,5 часа». Все надписи по-русски.
Когда этот сценарий работает, установка считается запущенной. Дальше добавляются остальные — какие именно задачи в таком конструкторе собираются надёжно, а какие только выглядят простыми, мы разбирали на двенадцати примерах с оценкой часов.
Резервные копии: копия без учения — это не копия
Копировать надо четыре вещи, и три из них обычно забывают. Первая — база: в ней сценарии, учётные данные и история прогонов. Вторая — том с файлами самой установки. Третья — файл описания сервисов и переменные окружения, без которых копию некуда разворачивать. Четвёртая — ключ шифрования учётных данных, и он единственный, кто хранится отдельно от всего остального.
Есть ещё пятая мера, самая дешёвая из всех: выгружать сценарии в виде файлов и складывать их в систему контроля версий. Это пять минут настройки и полчаса работы, зато вы получаете историю изменений сценария и возможность откатить вчерашнюю правку, не поднимая всю резервную копию целиком.
Дальше — то, чего почти никто не делает. Копия, которую ни разу не разворачивали, не является резервной копией: это файл с надеждой. Раз в квартал копия разворачивается на отдельном сервере, замеряется время и записывается результат. Разница между компанией, которая проводит такие учения, и компанией, которая их не проводит, измеряется в часах простоя.
Расчёт модельный, и подставлять в него нужно свои числа: поток заявок, маржу и долю, которая теряется, если заявка не записалась вовсе. Но соотношение устойчивое — два часа работы раз в квартал против шести часов простоя в неудачный день.
Сравнение в две колонки. Левая «Учение проводилось»: есть записанный порядок восстановления, ключ шифрования достаётся из хранилища, версия зафиксирована, время восстановления 40–90 минут, потери близки к нулю. Правая «Учения не было»: порядок восстанавливается по памяти, ключ ищут, версия образа не совпадает с базой, подключения заводятся заново, время 4–8 часов, потери 18 000 ₽ при 30 заявках под ударом. Внизу общая подпись «разница — 6 часов простоя». Чертёжный стиль, подписи по-русски.
Обновления: нельзя откладывать и нельзя ставить автоматом
Конструктор обновляется часто — новые версии выходят несколько раз в месяц. Это создаёт ловушку с двумя одинаково плохими выходами. Обновляться автоматически на боевом контуре нельзя: поведение отдельных узлов между версиями меняется, и сценарий, который вчера разбирал ответ поставщика, сегодня начинает возвращать пустоту. Не обновляться тоже нельзя: разрыв в полтора года означает, что миграция базы пойдёт через десяток промежуточных версий, и вероятность пройти её без потерь стремительно падает.
Самая распространённая ошибка в чужих установках: в конфигурации указан образ с тегом latest. Пока сервер не перезагружался, всё стабильно. В день, когда хостер проводит работы или вы сами перезапускаете контейнеры, установка молча приезжает на свежую версию — вместе со всеми изменениями поведения узлов. Указывайте конкретный номер версии и меняйте его руками, осознанно.
Рабочий порядок — раз в квартал, четыре раза в год, по одному и тому же чек-листу: снять копию, поднять её на отдельном сервере, обновить версию там, прогнать пять контрольных сценариев, сверить результат с эталонным и только потом повторить на боевом. Времени это занимает около двух часов на прогон. Если контрольные сценарии не проходят, обновление откладывается до следующего квартала, а причина записывается — на неё придётся вернуться.
Схема процесса в чертёжном стиле, слева направо. Блоки: «Снять копию» → «Развернуть на отдельном сервере» → «Обновить версию там» → «Прогнать 5 контрольных сценариев» → развилка: вверх «Совпало с эталоном → обновить боевой», вниз «Не совпало → откат, причина в журнал, перенос на следующий квартал». Над схемой подпись «раз в квартал, 2 часа на прогон». Сбоку выноска «в конфигурации — номер версии, не latest». Все подписи по-русски.
Диск и история прогонов: где установка кончается через полтора месяца
Есть отказ, который случается почти у всех и почти всегда неожиданно: заканчивается место на диске. Конструктор по умолчанию сохраняет историю прогонов целиком — со всеми данными, которые прошли через сценарий. Пока сценарии гоняют текстовые заявки, это незаметно. Как только появляется сценарий с вложениями — счетами, накладными, фотографиями, — история начинает расти на порядок быстрее, и через несколько недель установка встаёт на ровном месте.
Рабочее правило: успешные прогоны хранить 14 дней, прогоны с ошибками — 90 дней. Успешный прогон недельной давности не нужен никому, а вот ошибочный трёхмесячной давности — единственное доказательство при разборе с подрядчиком, у которого «всё работало». Настраивается это в первый же день, а не тогда, когда диск заполнен: на заполненном диске база перестаёт принимать записи, и порядок восстановления сложнее обычного.
Отсюда же второй сигнал мониторинга. Первый очевиден — установка не отвечает. Второй настраивают редко: свободное место меньше 20 %. Между этими двумя сигналами обычно проходит несколько дней, за которые проблему можно решить спокойно, а не в аварийном режиме. Тот же принцип действует и для самих сценариев: отдельно оповещать надо не только об ошибке обмена, но и о подозрительной тишине, когда за несколько часов не пришло ни одного события.
Двухосевой график. Горизонтальная ось — месяцы от 0 до 6, вертикальная — занятое место в гигабайтах от 0 до 28. Горизонтальная красная линия-порог на отметке 28 ГБ подписана «диск заполнен». Три линии из нуля: пологая серая «только текстовые заявки, 0,7 ГБ в месяц» с подписью «запас 40 месяцев», крутая синяя «плюс сценарий с документами, 18 ГБ в месяц», пересекающая порог между первым и вторым месяцем с выделенной точкой «полтора месяца», и горизонтальная штриховая на уровне 8,4 ГБ с подписью «хранение успешных прогонов 14 дней — дальше не растёт». Оси и подписи по-русски.
Сколько это стоит на самом деле: год эксплуатации
Считаем стартовую установку у российского хостера: пять сценариев, около 18 000 операций в месяц, база в контейнере на том же сервере. Внутренний час сотрудника — 1 100 ₽: оклад 120 000 ₽ плюс страховые взносы и рабочее место, поделённые на 160 рабочих часов в месяц. Разовая настройка контура считается отдельно от эксплуатации.
Нижняя граница разовой настройки — 35 000 ₽ за базовый контур без персональных данных. Верхняя — 75 000 ₽, когда через сценарии идут телефоны и адреса клиентов: добавляются разделение доступов, шифрование копий, журналирование и описание контура для поручения обработки. Своими силами эта же настройка обходится в 7,5 часа у опытного человека и 20–30 часов у неопытного, то есть в 8 250 ₽ или 22 000–33 000 ₽ рабочего времени по той же ставке.
Сервер, хранилище, мониторинг и домен вместе дают 50 000 ₽ в год. Администрирование — 44 000 ₽, почти половину. И это при условии, что нужный человек в компании уже есть и его час стоит 1 100 ₽. Если его нет и те же 40 часов покупаются у подрядчика по 3 500 ₽, строка превращается в 140 000 ₽, а год эксплуатации — в 190 000 ₽. Это и есть настоящая развилка «своё или облачное»: не про технологии, а про то, есть ли у вас свой администратор.
Точка безубыточности: когда облако дешевле
Сравнивать надо честно, вычтя одинаковое. Часы владельца сценариев — того, кто правит логику, добавляет поля и разбирается, почему клиент не получил уведомление, — одинаковы в обоих вариантах, поэтому в сравнении они сокращаются. Различаются только инфраструктура с администрированием, которых у облака нет, и подписка, которой нет у своей установки.
Годовые расходы своей установки почти не зависят от объёма: сервер за 2 400 ₽ и 40 часов администратора стоят одинаково при 5 000 и при 40 000 операций в месяц. Расходы облака растут линейно вместе с потоком. Берём модельную цену 0,15 ₽ за операцию — по массовым тарифам российских площадок вилка укладывается в 0,10–0,25 ₽ и зависит от объёма; у ApiX-Drive младший тариф начинается примерно от 2 200 ₽ в месяц, у Albato тарификация идёт по операциям.
Двухосевой график. Горизонтальная ось — операции в месяц от 0 до 120 000, вертикальная — рубли в год от 0 до 220 000. Серая горизонтальная линия на отметке 94 000 ₽ подписана «своя установка, свой администратор». Вторая серая горизонтальная штриховая линия на 190 000 ₽ подписана «своя установка, администратор с рынка по 3 500 ₽/час». Синяя наклонная прямая из нуля — «облако, 0,15 ₽ за операцию». Две точки пересечения выделены и подписаны: «52 000 операций» и «106 000 операций». Вертикальная пунктирная отметка на 18 000 операций подписана «модельная компания: облако дешевле на 61 600 ₽ в год». Оси подписаны по-русски.
Из графика следует вывод, который редко пишут в инструкциях по установке. Если у вас пять сценариев, поток меньше 50 000 операций в месяц и в данных нет ничего чувствительнее адреса доставки пиццы — своя установка вам не нужна, российская облачная платформа выйдет дешевле и не потребует администратора. Ниже точки безубыточности свой сервер покупают за другое: за то, что данные не проходят через контур третьего лица.
И здесь важно не переоценить аргумент. Своя установка на сервере в России действительно снимает вопрос трансграничной передачи. Но и российская облачная платформа с юрлицом и серверами в России требование локализации закрывает: у Albato и ApiX-Drive этот вопрос решён, ApiX-Drive к тому же есть в реестре Минцифры. Разница не в локализации, а в том, что при работе с облаком появляется третье лицо, которому вы поручаете обработку: нужен договор, поручение обработки и понимание, что именно и на какой срок остаётся в журналах прогонов на его стороне. Свой сервер нужен там, где третье лицо недопустимо в принципе: коммерческая тайна, документы с реквизитами, сведения о здоровье. Что именно меняется, когда данные компании уходят в чужой облачный контур, разбирали отдельно.
Установка в России снимает вопрос хранения данных за рубежом. Она не снимает остального: согласий субъектов, журналирования доступа, ротации токенов, ограничения круга лиц с доступом к интерфейсу и защиты резервных копий. Копия базы прогонов с телефонами клиентов, лежащая в открытой папке на том же сервере, формально находится в России и фактически является утечкой, которая ждёт своего часа.
Что стоит отдать инженерам, а что оставить себе
Граница проходит не по сложности, а по цене ошибки и по тому, кто окажется на телефоне в субботу. Установка, первые сценарии и правки логики — посильная внутренняя работа, и отдавать её наружу расточительно. Контур с персональными данными, дежурство и отказоустойчивость — работа, у которой есть цена простоя, и она обычно выше стоимости подряда.
| Зона | Делать самому | Отдавать инженерам | Почему граница здесь |
|---|---|---|---|
| Установка и первый сценарий | Да, 7,5 + 2,5 часа | Только если своего человека нет вовсе | Ошибка на этом этапе видна сразу и стоит времени, а не денег |
| Правки сценариев и новые поля | Да | Нет | Кто ближе к процессу, тот и правит; иначе каждая мелочь стоит заявки подрядчику |
| Контур с персональными данными | Нет | Да, входит в 75 000 ₽ разовой настройки | Цена ошибки — не простой, а уведомление в надзорный орган |
| Мониторинг и дежурство | Частично: настроить можно самому | Реакция вне рабочего времени | Сигнал в 23:40 в субботу должен кто-то принять и отработать |
| Отказоустойчивость: второй сервер, переключение | Нет | Да | Нужна проверка отказом, а не вера в то, что переключение сработает |
| Обновления версий | Да, по чек-листу | Мажорные переходы через несколько версий | Квартальный прогон посилен; разрыв в год — уже отдельный проект |
Две вертикальные колонки. Левая «Оставляем себе»: установка 7,5 часа, первый сценарий 2,5 часа, правки логики, обновления по чек-листу 4 раза в год. Правая «Отдаём инженерам»: контур с персональными данными, дежурство вне рабочего времени, отказоустойчивость, мажорные переходы версий. Между колонками вертикальная разделительная линия с подписью сверху «цена ошибки: время или деньги». Внизу подпись «разовая настройка контура 35 000–75 000 ₽». Чертёжный стиль, подписи по-русски.
Когда свою установку делать не надо
Есть четыре ситуации, в которых мы сами отговариваем от своего сервера. Ни одна из них не про то, что технология плохая, — все про то, что расходы окажутся больше пользы.
- Меньше пяти сценариев и нет чувствительных данных. На таком объёме российская облачная платформа обходится в 26 000–33 000 ₽ в год против 94 000 ₽ у своей установки, а администратор ей не нужен вовсе. Разница в 61 600 ₽ ничем не компенсируется.
- В компании нет человека, который держал сервер. Тогда 40 часов администрирования в год покупаются по 3 500 ₽ и превращаются в 140 000 ₽, а годовая стоимость — в 190 000 ₽. Точка безубыточности уезжает к 106 000 операций в месяц, и до неё вы почти наверняка не дотянете.
- Установка задумана как замена системы учёта или CRM. Конструктор сценариев связывает системы и переносит данные между ними, но он не место для хранения бизнес-логики целиком. Где проходит граница между сценарием и разработкой, разбирали отдельно.
- Процессы ещё не описаны. Автоматизировать несуществующий порядок нельзя: сценарий закрепит текущий беспорядок и сделает его труднее для исправления. Сначала описание процесса и данных, потом сервер.
И последнее, что стоит держать в голове при чтении любой инструкции по установке, включая эту. Интерфейсы, названия пунктов меню и расположение настроек меняются от версии к версии, а версии здесь выходят несколько раз в месяц. Поэтому выше описана логика действий и проверок, а не расположение кнопок: если экран у вас выглядит иначе — ищите ту же сущность под другим названием, а порядок шагов и смысл проверок останутся теми же.
Своя установка покупается не за экономию на подписке, а за то, что данные не выходят за периметр. Если этого требования нет, честный ответ — облако.
