Самый правильный способ - использовать один сервис для инференса (например, Ollama), который выступает единой точкой доступа к моделям. Все контейнеры и LM Studio обращаются к нему по API. В этой сборке Ollama уже есть - достаточно настроить другие сервисы на его эндпоинт.
2. Общий volume для Docker
Если нужно именно шарить файлы моделей между контейнерами:
LM Studio хранит модели в ~/.cache/lm-studio/models. Можно:
Пробросить эту директорию в Docker-контейнеры через bind mount
Или запустить LM Studio в режиме сервера и обращаться к нему из контейнеров по API (по умолчанию http://host.docker.internal:1234)
Но честно говоря, для продакшн-сценариев проще использовать один Ollama/vLLM/LocalAI как централизованный inference-сервер, чем шарить файлы моделей между разными приложениями.
Спасибо! Все так, проблема в том, что эта переменная не прокидывалась в n8n до этого. Я добавил необходимые изменения, сейчас все будет работать, достаточно обновиться через команду:
sudo bash ./scripts/update.sh
После переменная NODES_EXCLUDE автоматически появится в .env файле и будет использоваться n8n.
Интегрировал Postgresus в свой Docker Compose стек буквально за 5 минут - 7 строк конфига и всё работает. Именно потому что автор упаковал всё в Docker-образ. Использую в проде для бэкапа баз, работает стабильно. Docker сейчас стандарт для self-hosted, и это было правильное архитектурное решение.
Здравствуйте! Не совсем понял вопрос - уточните, пожалуйста.
Если речь про обновление до n8n v2, то с вашей стороны нужно будет только проверить свои воркфлоу через Settings -> Migration Report и исправить те, которые будут подсвечены как требующие внимания.
Обновление сборки станет доступно после выхода стабильной версии 2.0.x.
По первому вопросу - зависит от серьёзности проекта.
Если это пет-проекты или прототипирование - да, весь стек отлично живёт на одном VPS. Собственно, для этого сборка и создавалась: быстро поднял окружение, проверил гипотезу, показал заказчику MVP. Для этих целей в ней есть всё что нужно.
Если говорить про серьёзный продакшн - там я n8n не использую. Обычно это экосистема langchain и облачные провайдеры моделей.
По железу. Тут, к сожалению, нельзя дать универсальный ответ - слишком много переменных.
Минимальный сетап (n8n + бэкапы + мониторинг) - 2 CPU / 4 GB RAM. Дальше нужно смотреть конкретно:
Какие сервисы планируете запускать
Будете ли использовать локальные модели или облачные API
Если локальные - какие именно модели, какого размера, и на чём запускаете (CPU или GPU)
По сути, нужно составить список того, что хотите поднять, и добавлять ресурсы к минимальному сетапу. Базовые требования сильно зависят от того, используются ли LLM вообще - это самая ресурсоёмкая часть. Запуск модели на CPU и на GPU - это совершенно разные истории по потреблению RAM и скорости инференса.
Wildcard-сертификаты в проекте не используются. Настраивается wildcard DNS-запись (*.domain.com), но сертификаты получаются отдельно для каждого поддомена через стандартный HTTP-01 challenge. Caddy делает это полностью автоматически - нужен только открытый порт 80/443 и указанный email в LETSENCRYPT_EMAIL. API-ключи DNS-провайдера не требуются.
Отвечу на вопрос про различия: Основное отличие Flowise то, что это специализированная платформа для AI-агентов на базе LangChain, тогда как n8n скорее мультитул, в котором есть все и сразу.
Flowise добавили в проект ещё весной 2025, и тогда разница с n8n была ощутимой - он сильно выигрывал в построении мультиагентных систем, например у него первого появились rag, evals, tracing, shared state между агентами и тд. Но n8n последние полгода активно догонял flowise, и сейчас различия не так существенны.
Лично я использую Flowise скорее из привычки, так как начинал с него во времена когда в n8n агентные ноды еще не были так развиты.
Помню, когда знакомился с n8n тоже проходил через большинство из описанных болей (настройка прокси, SSL, VPN, переменные окружения, очередь задач и прочие нюансы установки n8n на VPS). Чтобы упростить этот процесс, я сделал полностью автоматизированный установщик n8n на VPS, который за 10 минут поднимает готовую инфраструктуру n8n c очередью задач, бэкапами, мониторингом, все через Docker Compose, сразу с рабочими связями и SSL. Так же в wizard доступны и другие сервисы для развертывания, например Flowise, Supabase, возможно, кому-то пригодится. Инструкция по установке со списком доступных сервисов в readme проекта — https://github.com/kossakovsky/n8n-installer
Вы правы, спасибо, поправил!
Есть несколько подходов:
1. Централизованный сервер моделей
Самый правильный способ - использовать один сервис для инференса (например, Ollama), который выступает единой точкой доступа к моделям. Все контейнеры и LM Studio обращаются к нему по API. В этой сборке Ollama уже есть - достаточно настроить другие сервисы на его эндпоинт.
2. Общий volume для Docker
Если нужно именно шарить файлы моделей между контейнерами:
Затем монтируете этот volume в нужные сервисы.
3. LM Studio + Docker
LM Studio хранит модели в
~/.cache/lm-studio/models. Можно:Пробросить эту директорию в Docker-контейнеры через bind mount
Или запустить LM Studio в режиме сервера и обращаться к нему из контейнеров по API (по умолчанию
http://host.docker.internal:1234)Но честно говоря, для продакшн-сценариев проще использовать один Ollama/vLLM/LocalAI как централизованный inference-сервер, чем шарить файлы моделей между разными приложениями.
Не совсем понимаю вопрос. Зачем создавать дубли моделей? Одна модель может без проблем обслуживать несколько источников запросов.
Спасибо!
Все так, проблема в том, что эта переменная не прокидывалась в n8n до этого. Я добавил необходимые изменения, сейчас все будет работать, достаточно обновиться через команду:
После переменная NODES_EXCLUDE автоматически появится в .env файле и будет использоваться n8n.
@A-Gorbach @itenthusiast-ru Спасибо!
Есть две опции как изменить timezone:
1) Глобально сразу для всех workflow
2) Точечно для каждого workflow по отдельности
Глобально:
Нужно добавить переменную GENERIC_TIMEZONE в .env файл в корне проекта, например:
И затем перезапустить сервисы через
Точечно:
Нужно в workflow в котором хотите изменить timezone зайти в Settings:
А затем выбрать искомую из селектора Timezone:
Интегрировал Postgresus в свой Docker Compose стек буквально за 5 минут - 7 строк конфига и всё работает. Именно потому что автор упаковал всё в Docker-образ. Использую в проде для бэкапа баз, работает стабильно. Docker сейчас стандарт для self-hosted, и это было правильное архитектурное решение.
Здравствуйте! Не совсем понял вопрос - уточните, пожалуйста.
Если речь про обновление до n8n v2, то с вашей стороны нужно будет только проверить свои воркфлоу через Settings -> Migration Report и исправить те, которые будут подсвечены как требующие внимания.
Обновление сборки станет доступно после выхода стабильной версии 2.0.x.
По первому вопросу - зависит от серьёзности проекта.
Если это пет-проекты или прототипирование - да, весь стек отлично живёт на одном VPS. Собственно, для этого сборка и создавалась: быстро поднял окружение, проверил гипотезу, показал заказчику MVP. Для этих целей в ней есть всё что нужно.
Если говорить про серьёзный продакшн - там я n8n не использую. Обычно это экосистема langchain и облачные провайдеры моделей.
По железу. Тут, к сожалению, нельзя дать универсальный ответ - слишком много переменных.
Минимальный сетап (n8n + бэкапы + мониторинг) - 2 CPU / 4 GB RAM. Дальше нужно смотреть конкретно:
Какие сервисы планируете запускать
Будете ли использовать локальные модели или облачные API
Если локальные - какие именно модели, какого размера, и на чём запускаете (CPU или GPU)
По сути, нужно составить список того, что хотите поднять, и добавлять ресурсы к минимальному сетапу. Базовые требования сильно зависят от того, используются ли LLM вообще - это самая ресурсоёмкая часть. Запуск модели на CPU и на GPU - это совершенно разные истории по потреблению RAM и скорости инференса.
Wildcard-сертификаты в проекте не используются. Настраивается wildcard DNS-запись (*.domain.com), но сертификаты получаются отдельно для каждого поддомена через стандартный HTTP-01 challenge. Caddy делает это полностью автоматически - нужен только открытый порт 80/443 и указанный email в LETSENCRYPT_EMAIL. API-ключи DNS-провайдера не требуются.
@Mortello @kiru @vassilevev
Отвечу на вопрос про различия:
Основное отличие Flowise то, что это специализированная платформа для AI-агентов на базе LangChain, тогда как n8n скорее мультитул, в котором есть все и сразу.
Flowise добавили в проект ещё весной 2025, и тогда разница с n8n была ощутимой - он сильно выигрывал в построении мультиагентных систем, например у него первого появились rag, evals, tracing, shared state между агентами и тд. Но n8n последние полгода активно догонял flowise, и сейчас различия не так существенны.
Лично я использую Flowise скорее из привычки, так как начинал с него во времена когда в n8n агентные ноды еще не были так развиты.
Помню, когда знакомился с n8n тоже проходил через большинство из описанных болей (настройка прокси, SSL, VPN, переменные окружения, очередь задач и прочие нюансы установки n8n на VPS). Чтобы упростить этот процесс, я сделал полностью автоматизированный установщик n8n на VPS, который за 10 минут поднимает готовую инфраструктуру n8n c очередью задач, бэкапами, мониторингом, все через Docker Compose, сразу с рабочими связями и SSL. Так же в wizard доступны и другие сервисы для развертывания, например Flowise, Supabase, возможно, кому-то пригодится. Инструкция по установке со списком доступных сервисов в readme проекта — https://github.com/kossakovsky/n8n-installer