Как оценить стоимость n8n на своём VPS: сервер, обслуживание и лицензия

В карточке тарифа VPS написана аккуратная сумма в месяц. В смете автоматизации её обычно ставят первой строкой и на этом считают дело законченным. А потом выясняется, что настоящий расход спрятан в другом месте: во вторник вечером администратор разбирается, почему после обновления перестал отвечать один вебхук, в среду восстанавливает учётные данные, в четверг ищет, куда делось место на диске. Счёт за сервер при этом не изменился ни на рубль. Изменился счёт за людей.

Поэтому стоимость собственного n8n лучше считать не как «цену сервера», а как цену конкретного процесса за год: от заявки на сайте до записи в CRM, от входящего письма до уведомления в мессенджере. Ниже разберём, из чего складывается эта цена, где сидят самые неприятные строки и как настройки хранения выполнений превращаются в деньги.

Сначала выясняем, кто и для чего этим пользуется

Первый вопрос сметы не техническая, а юридическая и организационная: кто будет пользоваться автоматизацией и в каких целях. Лицензия Sustainable Use, под которой распространяется основной код n8n, ограничивает использование собственными внутренними деловыми, личными или некоммерческими целями (текст лицензии). Для компании, которая автоматизирует собственные заявки, отчёты и рассылки, это обычно понятная ситуация. Если же вы собираетесь строить на n8n услугу для чужих клиентов или встраивать его в продукт, условия нужно читать отдельно и внимательно, а возможно, и обсуждать с правообладателем. Это не повод пугаться, это повод не обнаружить проблему после запуска.

Второй нюанс из той же лицензии: файлы Enterprise из неё исключены. Это значит, что часть функциональности живёт на других условиях. Для бюджета вывод простой: «бесплатно» относится к тому, что покрыто лицензией для внутреннего использования, а не ко всему, что вы увидите в описании продукта.

Практический способ не запутаться: в первой строке сметы записать одним предложением, кто пользователь процесса (сотрудники компании, вы лично, внешние клиенты) и под какие условия это подпадает. Если ответ звучит как «наши сотрудники, наши данные», дальше идём по обычной схеме. Если иначе, то все последующие цифры пока условны.

Редакция: что нужно, а что просто хочется

Второй шаг отделяет обязательное от желательного. В описании сравнения редакций сказано, что Community не включает проекты, совместное использование credentials, external secrets и внешнее бинарное хранилище; кроме того, queue mode и multi-main имеют разные условия доступности (сравнение редакций n8n). Конкретные цены и состав платных планов меняются, поэтому в этой статье их нет: перед расчётом откройте актуальную страницу и посмотрите её сами.

Полезно разложить функции на три корзины и честно записать, в какую попала каждая:

• Без этого процесс не работает. Например, если два человека обязаны пользоваться одними и теми же подключениями к сервису, а завести отдельные учётные данные нельзя по правилам самого сервиса, то совместное использование credentials перестаёт быть роскошью.
• Без этого работает, но неудобно. Разделение рабочих областей по проектам помогает, когда процессов много и они принадлежат разным отделам. Для одного скромного сценария это скорее удобство.
• Хорошо бы иметь на вырост. Внешние хранилища секретов или масштабирование из нескольких процессов нужны, когда нагрузка и требования к управлению действительно выросли, а не потому, что звучит солидно.

Здесь легко совершить типичную ошибку: купить редакцию «на всякий случай» и записать её в расходы одного маленького процесса. Тогда вся смета выглядит так, будто автоматизация дорогая, и её закрывают. Наоборот, из-за скупости можно взять Community и потом обходить недостающие функции самодельными конструкциями, стоимость поддержки которых окажется выше разницы в цене. Честная смета содержит обе строки: цену обязательной редакции и отдельную, необязательную цену «хотелок», которую можно включить позже.

Заметьте, что Community не равна «урезанной бесплатной версии для игрушек». Это нормальный рабочий вариант для множества внутренних сценариев. Но обещать, что в ней найдётся всё, что нужно вашему отделу, нельзя: проверяйте нужные вам функции по списку выше и по актуальной документации.

Формула, в которой всё лежит на виду

Теперь можно собрать формулу. Для одного процесса за год:

C = 12 × (S + D + X) + L + Th × (U + R + I) × Ставка + E × Тинц × Ставка

Расшифруем переменные:

• S — месячная стоимость VPS, на котором живёт этот процесс, или его доля, если сервер общий.
• D — месячная стоимость хранения копий и дополнительного места, если вы платите за них отдельно.
• X — месячные расходы на внешние сервисы, которые вызывает процесс: платные API, почтовые рассылки, SMS, модели ИИ.
• L — годовая стоимость лицензии выбранной редакции, если она нужна. При Community равна нулю, но только если все нужные функции там действительно есть.
• Th — число «обычных» месяцев в году для обслуживания (без аварий).
• U, R, I — часы в месяц на обновления, регулярный просмотр ошибок и мелкие изменения сценария.
• E — ожидаемое число инцидентов в год.
• Тинц — среднее время на один инцидент в часах.
• Ставка — стоимость часа администратора или вашего собственного времени.

В формуле две части, и они ведут себя по-разному. Первая (сервер, копии, внешние API, лицензия) предсказуема и растёт линейно. Вторая (время) подвижна, зависит от качества процесса и почти всегда недооценена. Удивительно, но именно её чаще всего не записывают вообще, потому что «мы же сами, это бесплатно». Время не бесплатно, оно просто не приходит отдельным счётом.

Один условный расчёт трудозатрат

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

Пусть в году девять тихих месяцев и три тяжёлых, а ставка условно равна 2000 условных единиц в час. Тогда время обходится так: 9 × 1,5 = 13,5 часа тихих месяцев и 3 × 11 = 33 часа тяжёлых. Всего 46,5 часа, или 93 000 условных единиц. Если сервер стоил бы в год даже 10 000 единиц, он составил бы менее десятой части расходов. Вот почему счёт за VPS кажется маленьким, а поддержка отнимает вечер: пропорции действительно такие.

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

Сравнение тихого месяца и месяца бурь

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

Полезно перед расчётом выписать, какие события у вас уже случались или правдоподобно могут случиться, и присвоить каждому грубую вероятность и время разбора. Это та самая часть E × Тинц. Она не точна и не должна быть точной. Ей достаточно быть честной: если за прошлый год вы дважды теряли вечер на просроченный токен, пишите два вечера, а не ноль.

Есть и обратная сторона. Некоторые тяжёлые месяцы вы создаёте сами, например, когда за один раз переписываете полсценария. Это не сбой, а плановое изменение, и его стоит отнести к строке I, а не к инцидентам. Различие важно: инциденты уменьшают мониторингом и запасами прочности, изменения регулируют тем, как часто бизнес меняет правила.

Что делает сервер, и когда он всё же становится заметной строкой

Для небольшого процесса серверу нужно немного, но «немного» стоит проверить измерением, а не интуицией. Ресурсы тарифов MAATRIX из публичного предложения выглядят так: Ba — 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe; Uab — 2 vCPU, 4 ГБ и 80 ГБ; Heka — 4 vCPU, 8 ГБ и 160 ГБ; Maat — 8 vCPU, 16 ГБ и 240 ГБ; Djed — 16 vCPU, 32 ГБ и 320 ГБ (предложение VPS). Это описание ресурсов, а не обещание, сколько сценариев выдержит конкретный тариф: ёмкость зависит от ваших процессов, объёма данных в запусках и того, что ещё живёт на машине.

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

Если вам нужен ориентир по ИИ-сценариям, где нагрузка и внешние вызовы устроены иначе, посмотрите отдельный разбор: ИИ-автоматизации в n8n на VPS. В нём речь про сами сценарии, здесь же мы остаёмся в бюджете.

Заметьте также, что собственный сервер даёт право на root-доступ, а вместе с ним и обязанность: обновления системы, настройка доступа, копии. Эти обязанности уже посчитаны в часах выше. В публичном предложении VPS перечислены NVMe, AMD EPYC и root-доступ, но автоматические резервные копии там не заявлены, поэтому вопрос копий вы закрываете сами и записываете в строку D и в часы.

Выполнения: тихая статья расходов, которую задаёт срок хранения

Теперь самая интересная часть. Каждый запуск сценария оставляет запись о выполнении: какие данные вошли, что вернул каждый узел, чем закончилось. Эти записи занимают место и замедляют базу, когда их много. В документации по данным выполнений сказано, что можно выбирать, какие выполнения сохранять, и очищать старые завершённые записи; при этом running, new и waiting под обычную очистку не подпадают (данные выполнений n8n).

Для сметы из этого вытекают два рычага и одна оговорка.

Рычаг первый — сохранять ли успешные запуски. Если процесс отрабатывает тысячи раз в день, а успешные запуски вам нужны только как редкое доказательство, можно хранить в основном неудачные. Тогда база растёт заметно медленнее. Цена такого выбора — отладка: когда придёт жалоба «заявка вчера не дошла», у вас не будет подробной записи успешного прохождения. Ошибки вы увидите, а нормальный путь придётся восстанавливать по следам во внешних системах. Это и есть скрытая плата за экономию места, и её нужно сознательно принять.

Рычаг второй — срок хранения. Чем дольше вы держите завершённые записи, тем больше места им нужно и тем дороже копии. Но слишком короткий срок обрезает возможность разобрать медленные проблемы: если заметили расхождение только через две недели, а записи живут три дня, расследовать нечего.

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

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

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

Заметьте, как это встраивается в формулу. Срок хранения влияет на S и D (диск и копии), но главное, на Тинц: время разбора инцидента падает, когда есть что разбирать, и растёт, когда запись уже удалена. То есть «экономия» на хранении может оказаться переносом расхода из одной строки в другую, причём в более дорогую.

Внешние сервисы: расходы, которые не зависят от вашего сервера

Отдельный блок сметы — всё, что процесс вызывает снаружи. Платный API обогащения данных, отправка SMS, модель ИИ, сервис проверки адресов. Собственный сервер n8n здесь ничего не удешевляет: тариф стороннего сервиса не зависит от того, где стоит ваш n8n. Для процессов, которые часто вызывают такие сервисы, строка X легко перерастает расходы на сервер в несколько раз. Поэтому в смете её нужно считать от числа запусков и стоимости одного вызова по актуальному тарифу самого сервиса, а не оставлять «на потом».

Не забудьте и про повторы. Если сценарий при ошибке повторяет запрос, каждый повтор может быть оплачиваемым вызовом. В тяжёлом месяце число платных вызовов растёт вместе с числом сбоев, и этот эффект стоит включить в расчёт, пусть и грубо. Доступность конкретного стороннего API с серверов в разных странах тоже нужно проверять на практике, не принимая её на веру при выборе локации.

Как всё собрать в таблицу на один вечер

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

1. Запишите, кто пользуется процессом и какие условия лицензии к нему относятся.
2. Определите нужные функции и по актуальной странице редакций посчитайте L; необязательные функции вынесите отдельной строкой.
3. Подставьте S, D и X из реальных счетов и тарифов.
4. Оцените часы тихого месяца и тяжёлого месяца, затем число тяжёлых месяцев в году.
5. Выберите режим хранения выполнений и посмотрите, как он сдвигает диск и время разбора.
6. Посчитайте итог дважды: по оптимистичному и по осторожному набору допущений.

Разница между двумя итогами и есть настоящий результат: она показывает, насколько вы вообще можете доверять цифре. Если разброс огромный, значит, где-то сидит неизмеренная величина, и именно её нужно измерить прежде остального.

Строка, с которой стоит начать измерения

Если из всей сметы можно измерить только одну величину, пусть это будет время, которое уходит у вас на один тяжёлый месяц: от первого сообщения о проблеме до момента, когда процесс снова работает и вы уверены, что данные не потеряны. Лицензия известна по документу, сервер по счёту, внешние API по тарифам. А вот часы разбора вы оцениваете на глаз, и именно они двигают итог сильнее всего. Возьмите последний случай, когда автоматизация ломалась, честно сложите часы всех участников и поставьте эту цифру в формулу вместо угаданной. Скорее всего, она окажется неприятно большой, и это лучший повод заняться тем, что её уменьшит: понятным хранением выполнений, внятными уведомлениями об ошибках и копиями, которые вы однажды проверили восстановлением.