Windmill или Temporal: что выгоднее и когда

MAATRIX

Оба инструмента называют «оркестрацией workflow», оба open-source, оба разворачиваются на своём VPS без подписки в валюте — и на этом сходство обрывается. Windmill превращает скрипт на Python или TypeScript в задачу с формой ввода, расписанием и API за десять минут. Temporal — это движок durable execution: платформа, которая гарантирует, что бизнес-процесс из десятков шагов доживёт до конца даже если сервер упал посреди выполнения, и переживёт это без единой потерянной транзакции. Путать их — значит выбрать не тот инструмент и потом героически бороться с его архитектурой. Разбираемся, где проходит граница.

Что за инструменты и в чём разница философий

Windmill — платформа для превращения кода в инструменты: Scripts (код на десятке языков, который платформа сама оборачивает в задачу с параметрами), Flows (визуальный конструктор пайплайнов с условиями, циклами и retry) и Apps (низкокодовый билдер внутреннего UI поверх скриптов). Подробный разбор установки есть в статье про Windmill на VPS. Идея простая: вы пишете код, Windmill даёт ему расписание, вебхук, форму и лог запусков.

Temporal — не инструмент автоматизации в привычном смысле, а инфраструктурный слой durable execution, изначально форк внутренней системы Cadence из Uber. Temporal Server ничего не знает о вашей бизнес-логике: он хранит историю событий workflow и координирует выполнение, а саму логику пишете вы — на Go, Java, TypeScript, Python, .NET или PHP через официальный SDK — и запускаете как отдельный процесс-воркер, подключённый к серверу по gRPC. Ключевая гарантия: если воркер упал посреди workflow, рассчитанного на три дня и десять внешних вызовов, Temporal восстановит состояние по истории событий и продолжит с того же шага — без ручного вмешательства и без дублирования уже выполненных побочных эффектов.

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

Модель выполнения: скрипты-задачи против event sourcing

В Windmill каждый запуск скрипта — независимая job в очереди, которая хранится прямо в PostgreSQL (Windmill использует SKIP LOCKED, отдельный брокер сообщений не нужен). Job выполнилась — результат записан, воркер взял следующую. Retry настраивается на уровне шага flow, но модель по сути линейная: выполнил — записал — следующий.

В Temporal модель принципиально другая — event sourcing. Каждый workflow — это не «запуск функции», а последовательность событий (WorkflowExecutionStarted, ActivityTaskScheduled, ActivityTaskCompleted и так далее), которая пишется в персистентное хранилище. Когда воркер обрабатывает workflow, он replay'ит историю событий с начала, чтобы восстановить состояние в памяти, и только затем выполняет следующий шаг. Отсюда жёсткое требование: код workflow должен быть детерминированным — нельзя напрямую вызывать random(), читать системное время или ходить в сеть прямо из функции workflow. Всё, что имеет побочные эффекты (HTTP-запрос, запись в базу, письмо), выносится в Activity — отдельную функцию, для которой Temporal автоматически настраивает retry, таймауты и heartbeat.

Это не бюрократия ради бюрократии: детерминизм и replay — тот самый механизм, который даёт «продолжить с прерванного места» без ручного сохранения состояния в собственной базе. Плата за гарантию — необходимость думать в терминах workflow/activity вместо «просто написать скрипт», и это реальный порог входа, который недооценивают на старте.

Инфраструктура и ресурсы сервера

Стек Windmill компактнее. Обязательные компоненты — server, один или несколько worker и единственная зависимость — PostgreSQL, которая одновременно хранит состояние и работает очередью задач. Отдельного Redis или поискового движка не требуется.

Temporal для продакшена — уже полноценная распределённая система. Официальный docker-compose от temporalio/docker-compose разворачивает Temporal Server (в dev-конфигурации — одним контейнером auto-setup, в бою — раздельные сервисы frontend/history/matching/worker), базу данных (PostgreSQL, MySQL или Cassandra — последняя исторически предпочтительнее для очень больших объёмов истории событий) и опционально Elasticsearch для расширенного visibility-поиска workflow по кастомным атрибутам.

Разница объясняется целью: Temporal проектировали для нагрузки уровня «тысячи workflow в секунду в проде большой компании», и даже сильно урезанная self-hosted инсталляция тащит за собой часть этой архитектуры. Windmill с самого начала целился в «один сервис, одна база, минимум подвижных частей».

Установка: сравнение на практике

Минимальный старт Temporal через официальный репозиторий (dev-режим с auto-setup, не для прода):

git clone https://github.com/temporalio/docker-compose.git
cd docker-compose
docker compose up -d

Поднимутся temporal (сервер), temporal-ui (веб-интерфейс на порту 8080), temporal-admin-tools и связка Postgres + Elasticsearch. Дальше нужен минимум один воркер — процесс на выбранном SDK, который подключается к серверу и регистрирует свои workflow/activity:

# пример на TypeScript, официальный SDK
npm install @temporalio/worker @temporalio/client @temporalio/workflow

Воркер — это не контейнер из compose-файла Temporal, а ваш собственный код, который вы пишете и деплоите отдельно (можно на том же VPS, можно на другом). В этом принципиальное отличие от Windmill, где среду выполнения скриптов даёт сама платформа.

Установка Windmill компактнее — один docker-compose.yml с сервером, воркерами и Postgres, никакого отдельного кода писать не нужно, чтобы получить рабочую систему. Полный разбор с .env, обратным прокси и HTTPS — в статье как установить и настроить Windmill на VPS.

Для боевого Temporal-кластера обязательно закрепляйте порт UI и gRPC-порт сервера (7233) на 127.0.0.1 или во внутренней docker-сети и выводите наружу только через обратный прокси с HTTPS и авторизацией — как и с любым админ-интерфейсом, логика та же, что для Traefik как reverse proxy для Docker. Если вместо Postgres выбираете Cassandra под большие объёмы истории событий, отдельный разбор её установки на VPS — тоже в блоге, см. Cassandra: установка на VPS.

Порог входа для разработчиков

Здесь разница ощутимее всего. В Windmill вы пишете обычную функцию на Python/TypeScript/Go/Bash — платформа сама вызывает её с параметрами из UI или API, никакого специального SDK учить не нужно. Порог входа — это порог входа в язык программирования, не более.

В Temporal придётся освоить набор правил, специфичных именно для durable execution:

• Детерминизм workflow-кода — никаких прямых вызовов time.Now(), random, сетевых запросов из тела workflow; для этого есть специальные API SDK (workflow.Now(), workflow.SideEffect()).
• Activities отдельно от Workflows — работа с внешним миром (API, БД, файлы) выносится в activity-функции с настраиваемыми retry policy и таймаутами.
• Signals и Queries — способ достучаться до уже запущенного, возможно недели идущего, workflow: отправить событие извне или спросить состояние без изменения хода выполнения.
• Версионирование — если код workflow меняется, а старые экземпляры ещё выполняются, нужно аккуратно работать с GetVersion/patching, иначе replay сломается на несовпадении истории с новым кодом.

Ничего из этого не сложно по отдельности, но вместе это полноценная ментальная модель, на освоение которой у команды без опыта в durable execution уходит заметно больше времени, чем на Windmill. Окупается это, когда цена ошибки в бизнес-процессе высока — потерянный платёж, задвоенный заказ, зависший saga-процесс без возможности понять, на каком шаге он застрял.

Лицензии, экономика и кому что выбрать

Temporal Server и официальные SDK распространяются под MIT — permissive-лицензией без разделения на community/enterprise; всё, что нужно для self-hosting в проде, открыто. Коммерческий Temporal Cloud — управляемый сервис с оплатой по использованию, но это отдельный выбор, а не условие для self-hosted версии.

Windmill распространяется под AGPLv3 — тоже бесплатен для self-hosting без ограничения числа пользователей на community-функциях, но AGPL накладывает копилефт-обязательства, если вы модифицируете код и предоставляете его как сервис третьим лицам; для внутреннего использования командой это роли не играет.

И то, и другое в self-hosted варианте решает главный вопрос для читателя из России одинаково: платите только за сервер, никакой обязательной оплаты SaaS-подписки в долларах или евро зарубежной картой не требуется. Разбор вариантов оплаты инфраструктуры — в статье как оплатить сервер в России из России картой и криптой.

Если задача — «нам нужна автоматизация с визуальными нодами и готовыми интеграциями, а не код с нуля», это, строго говоря, ни Windmill, ни Temporal, а инструменты другого класса вроде n8n — логика выбора между low-code и code-first платформой подробно разобрана в статье n8n против Make: что выгоднее и когда, и часть тех же аргументов применима и здесь.

Частые вопросы