Self-Hosted в Cloud: когда переход на n8n оправдан

Переход с самостоятельно размещенного (self-hosted) экземпляра n8n на n8n Cloud оправдан прежде всего тогда, когда затраты на серверы, обновления и резервное копирование превышают пользу от полностью контролируемой среды. Однако не все переносится автоматически: согласно документации n8n, непроверенные community-узлы и самостоятельно созданные узлы работают только в self-hosted, количество выполнений ограничено в зависимости от тарифа Cloud, а учетные данные после переезда необходимо создавать заново вручную, поскольку экспортированные файлы workflow содержат только имена и ID credentials, а не их значения. Тот, кто заранее знает эти моменты, избегает неприятных сюрпризов после миграции. Актуально на июль 2026 года.

Когда переход в Cloud оправдан

При self-hosted n8n, по данным самого n8n, вы несете полную ответственность: вы предоставляете инфраструктуру, управляете ею и отвечаете за обновления, патчи безопасности и резервное копирование. n8n Cloud меняет это соотношение местами. Согласно официальному обзору вариантов использования она полностью управляется, настройка не требуется, а n8n берет на себя обслуживание и эксплуатацию. Для команд без собственных ИТ-ресурсов или с малым количеством времени на обслуживание серверов это реальное преимущество. Цена за это: вы отдаете часть контроля, который сознательно наработали при self-hosting, и платите текущую подписку вместо чисто инфраструктурных расходов.

Что не переносится автоматически при переезде

Самое большое различие касается узлов. В n8n Cloud, согласно документации по установке community-узлов, через панель узлов можно устанавливать только проверенные community-узлы. Непроверенные узлы и установка через npm возможны только в self-hosted. Тот, кто использует собственные или редкие узлы, должен перед переездом проверить, проверены ли эти узлы, иначе они просто исчезнут в Cloud.

• Узлы: В Cloud работают только проверенные community-узлы, установки через npm и самостоятельно созданные узлы остаются в self-hosted.
• Учетные данные: Согласно документации по экспорту и импорту, экспортированные JSON-файлы workflow содержат только имена и ID credentials, но не их значения. После импорта необходимо вручную заново указать все учетные данные.
• Конфигурация: Тонкая настройка через переменные окружения, которая в self-hosted составляет основу конфигурации, в Cloud возможна лишь в ограниченном виде, поскольку экземпляр управляется провайдером.

Лимиты выполнений и ресурсы в сравнении

В self-hosted количество выполнений практически ограничено только собственным серверным оборудованием. В Cloud действуют фиксированные квоты в зависимости от тарифа. Согласно прайс-листу n8n, тариф Starter включает 2500 выполнений в месяц при 5 одновременных запусках, тариф Pro 10 000 выполнений при 20 одновременных запусках, тариф Business 40 000 выполнений, а также SSO, SAML, LDAP и среды на основе Git. Хранение журналов выполнения также ограничено: согласно сведениям в разделе управление данными Cloud, тариф Starter хранит максимум 2500 выполнений с хранением 7 дней, Pro до 25 000 с хранением 30 дней, Enterprise до 50 000 с неограниченным хранением. При заполнении хранилища от 85 процентов n8n может автоматически очищать старые данные о выполнениях. Оперативная память также распределена по уровням, от 320 МиБ в тарифе Starter и пробном тарифе до 4096 МиБ в Enterprise, тогда как в self-hosted вы сами выбираете размер сервера.

Что конкретно нужно сделать для миграции

Workflow можно экспортировать в формате JSON и импортировать в экземпляр Cloud. Прежде чем это делать, стоит провести краткую инвентаризацию: какие узлы используются и все ли они числятся проверенными в Cloud. После этого credentials создаются вручную в новой среде, поскольку, как описано, экспортированные файлы не содержат секретов. Тот, кто до этого работал с переменными окружения или собственными настройками базы данных, должен задокументировать эту конфигурацию перед переездом, поскольку в управляемой среде Cloud она не существует в том же виде. Для команд, которые хотят технически грамотно спланировать переезд с четкой приоритизацией, предлагается консультация по n8n, которая заранее проверяет, какие workflow работают без изменений и где нужны корректировки.

Частые вопросы о миграции с self-hosted на Cloud в n8n

Работают ли все self-hosted workflow в Cloud без изменений?

Только если все используемые узлы относятся к проверенным community-узлам или являются стандартными узлами n8n. Workflow с непроверенными или самостоятельно созданными узлами необходимо адаптировать или заменить перед переездом, поскольку, согласно документации n8n, их нельзя установить в Cloud.

Что происходит с моими учетными данными при переезде?

Их необходимо создать заново. Экспорт workflow содержит только имена и ID credentials, без паролей, токенов или ключей. С точки зрения безопасности это разумно, но означает ручную работу после импорта.

Могу ли я позже снова вернуться на self-hosted?

В принципе workflow можно снова экспортировать и импортировать в self-hosted экземпляр. Специфичные для Cloud ограничения при этом снимаются, но взамен вы снова берете на себя полную ответственность за эксплуатацию, обновления и резервное копирование.

Сколько выполнений включено в самый дешевый тариф Cloud?

Согласно текущему прайс-листу, тариф Starter предлагает 2500 выполнений в месяц при максимум 5 одновременных запусках. Тому, кому нужно больше, необходимо перейти на Pro или Business, либо остаться на self-hosted, где лимит зависит от собственного серверного оборудования.