Почему на Modal кастомные ноды могут “слетать” после рестарта?

На Modal это выглядит почти как мистика: вчера ты поставил кастомную ноду, всё работало, а после рестарта или обновления страницы её как будто никогда и не было.

На самом деле это не магия и не “сломанный ComfyUI”. Обычно причина в другом: нода была установлена временно, но не была закреплена в нормальной сборке окружения.

💡 Для Modal это особенно важно, потому что в облаке мало просто что-то “доустановить по месту”. Нужно ещё понимать, переживёт ли эта установка рестарт.

Внутренняя ссылка: Куда вообще ставить custom nodes и почему без них половина workflow мёртвая?

Что именно происходит на практике

Очень типичный живой сценарий выглядит так:

1. Ты запускаешь ComfyUI на Modal.
2. Ставишь кастомную ноду через Manager.
3. Она действительно появляется и начинает работать.
4. Потом Comfy перезапускается, страница обновляется или среда пересобирается.
5. И нода исчезает.

Для новичка это выглядит так, будто платформа “сама ломает” окружение. Но реальная проблема обычно гораздо проще: установка не была встроена в постоянную сборку.

Почему это особенно заметно на Modal

Modal удобно использовать как облачную среду под ComfyUI, но у него другая логика, чем у привычного локального запуска. Многие думают, что если что-то однажды установилось внутри сессии, то оно останется там навсегда. На практике это не всегда так.

В Modal важно различать:

• временные изменения внутри текущего контейнера;
• то, что зашито в image или template;
• то, что сохранено в persistent storage.

⚠️ Если кастомная нода появилась только как ручная доустановка внутри текущего запуска, это ещё не значит, что она станет частью будущих рестартов.

Почему ручная установка через Manager часто не спасает

Это как раз один из самых коварных моментов.

ComfyUI Manager удобен для быстрой установки нод. Но на Modal он может создавать ложное ощущение, что всё уже “зафиксировано”. На самом деле ты мог просто изменить текущее состояние контейнера, а не сделать эту ноду частью постоянной среды.

То есть Manager может быть полезен для теста, но не всегда годится как единственный способ закрепить окружение на Modal.

Именно поэтому опытные пользователи часто советуют другую логику: сначала собрать нормальный template или image, а уже потом деплоить рабочую среду.

Главная причина: нода не стала частью сборки

Вот самая важная мысль всей статьи:

Если кастомная нода не включена в template, image или другую постоянную часть окружения, она может не пережить рестарт.

Это и есть корень проблемы.

Новички часто думают так:

“Я же поставил ноду. Значит, она теперь есть.”

Но в облаке правильнее думать иначе:

“Я поставил ноду. Теперь надо понять, где именно она живёт и сохранится ли это состояние после следующего запуска.”

Почему после обновления страницы может казаться, что всё “слетело”

Потому что пользователь видит только интерфейс, а не жизненный цикл среды.

Снаружи всё выглядит очень просто:

• вкладка была открыта;
• Comfy работал;
• нода была установлена;
• потом страницу обновили — и всё исчезло.

Но внутри мог произойти один из сценариев:

• перезапустился контейнер;
• пересобралось приложение;
• среда поднялась заново из исходного image;
• временные изменения не были сохранены как часть постоянной конфигурации.

И тогда ты получаешь ощущение, что система “забыла” ноду. Хотя по факту она просто никогда не была закреплена правильно.

Почему template на Modal лучше собирать заранее

Это один из самых практичных советов по Modal вообще.

Если ты понимаешь, какой workflow хочешь запускать, гораздо надёжнее:

• сначала собрать свой template или image под эту схему;
• включить туда нужные custom nodes;
• добавить все зависимости;
• проверить, что всё действительно запускается;
• и только потом делать полноценный deploy.

✅ Такой путь кажется более долгим только в начале. На самом деле он обычно экономит кучу времени, потому что потом тебе не приходится каждый раз лечить “исчезающие” ноды.

Почему советуют сначала использовать serve, а потом deploy

Это очень здравый подход для Modal.

Если ты ещё не уверен, что среда собрана без ошибок, удобнее сначала использовать режим проверки и отладки. И только когда всё уже стабильно, переходить к deploy.

Смысл здесь простой:

• serve — чтобы проверять, тестировать и ловить проблемы в сборке;
• deploy — когда у тебя уже есть рабочий template, который не надо чинить на лету.

💡 Это особенно важно в ComfyUI-стеке, где одна отсутствующая нода может сделать весь workflow полумёртвым.

Внутренняя ссылка: Почему чужой workflow у меня не запускается?

Почему модели иногда переживают рестарт, а ноды нет

Это тоже частая путаница.

Людям кажется: если модель осталась, то и custom node должна была остаться. Но это не обязательно одно и то же.

Потому что модель и кастомная нода живут в системе по-разному:

• модель может быть примонтирована, скачана в persistent storage или лежать в volume;
• кастомная нода может быть просто докинута внутрь текущего контейнера;
• после рестарта контейнер вернётся к исходному состоянию, а временная нода исчезнет.

То есть вопрос не в том, “почему одна вещь сохранилась, а другая нет”, а в том, куда именно была записана каждая из них и как устроено хранение в этом шаблоне.

Что говорит документация Modal

У Modal есть важный принцип: вычисления идут в контейнерах, а если тебе нужна долговечность, то её надо закладывать явно — через image, volumes или другую постоянную конфигурацию. Файлы внутри временного окружения не надо автоматически считать постоянными. Это прямо соответствует тому, что люди ловят на практике с кастомными нодами и ручными установками. Внешняя ссылка: Modal Volume и persistent storage

Проще говоря:

• если тебе нужно, чтобы что-то переживало рестарт — это надо проектировать заранее;
• если ты просто поставил что-то “по месту” — это может прожить только текущую сессию.

Когда проблема особенно коварна

Самый неприятный сценарий такой:

• ты уже один раз увидел, что нода работает;
• значит, психологически уверен, что всё собрано правильно;
• потом после рестарта workflow внезапно ломается;
• и ты начинаешь искать проблему в моделях, JSON, путях или самом Modal.

Хотя корень проблемы был не в том, что workflow “сломался”, а в том, что кастомная нода никогда не была частью стабильной сборки.

⚠️ Именно поэтому Modal часто обманывает ожидания новичка: один раз всё поехало — значит кажется, что теперь так будет всегда. Но в облаке это не работает само по себе.

Как правильно думать о кастомных нодах на Modal

Не так:

• “Сейчас быстро поставлю через Manager, и вопрос закрыт”.

А так:

• “Мне нужно, чтобы эта нода была частью моей нормальной среды и переживала рестарт”.

То есть мышление должно быть не “поставить”, а “закрепить”.

Что делать правильно

1. Сначала определить состав workflow

Нужно понять, какие custom nodes реально обязательны для твоей схемы.

2. Встроить их в template или image

Не оставлять критичные ноды только как ручную установку внутри сессии.

3. Проверить зависимости

Если у ноды есть свои пакеты или системные требования, их тоже надо включить в нормальную сборку.

4. Тестировать через serve

Пока среда не стала стабильной, удобнее отлаживать её до deploy.

5. Делать deploy только после того, как template уже рабочий

Иначе ты просто зафиксируешь нестабильную сборку.

Внутренняя ссылка: Что новичку лучше: сразу брать чужой workflow или сначала понять базу?

Частые ошибки

• считать, что установка через Manager автоматически становится постоянной;
• не различать временную установку и постоянную сборку;
• делать deploy слишком рано, пока окружение ещё нестабильно;
• искать причину в JSON или модели, когда слетела именно кастомная нода;
• не думать о том, переживёт ли зависимость следующий рестарт.

Вывод

На Modal кастомные ноды могут “слетать” после рестарта не потому, что платформа мистическая, а потому, что временная доустановка не была закреплена в нормальной сборке окружения.

Если ты поставил ноду “по месту”, она может поработать в текущей сессии. Но после рестарта, пересборки или нового запуска эта установка не обязана сохраниться.

✅ Поэтому главный вывод очень простой: в облаке важно не только поставить зависимость, но и понять, переживёт ли она рестарт.

Если тебе нужна стабильность, собирай template или image заранее, проверяй всё через serve и только потом делай deploy.