inngest-cli

Inngest CLI — официальный skill для TypeScript-проектов, которым нужно установить или запустить CLI, локальный Dev Server, проверить serve endpoint, протестировать функции, настроить Docker или MCP, а также проверить self-hosted и deployment workflow. Dev Server описан как полностью функциональная open-source локальная версия Inngest Platform. Для Python и Go источник предлагает обращаться к документации Inngest; приведённые команды и примеры ориентированы на TypeScript. Для самой CLI рекомендуемым вариантом установки назван npx с тегом latest, также показаны yarn dlx, pnpm dlx, глобальная установка и Docker image. Команда inngest dev запускает локальный сервер с UI по адресу http://localhost:8288. По умолчанию CLI пытается обнаруживать приложения на распространённых портах и путях, включая /api/inngest, /x/inngest, /.netlify/functions/inngest и /.redwood/functions/inngest. При необходимости можно явно передать один или несколько SDK URL через -u, изменить порт через -p, выключить discovery флагом --no-discovery, включить сохранение данных --persist или задать путь к конфигурации. В источнике отдельно указан connect gateway на порту 8289; это не тот же порт, что основной сервер и веб-интерфейс. Настройки можно вынести в inngest.json, YAML или TOML в корне проекта: CLI поднимается по каталогам и ищет такой файл. Среди переменных окружения важны INNGEST_DEV, INNGEST_BASE_URL, INNGEST_EVENT_KEY, INNGEST_SIGNING_KEY, INNGEST_SIGNING_KEY_FALLBACK, INNGEST_SERVE_ORIGIN, INNGEST_SERVE_PATH, INNGEST_STREAMING и INNGEST_ENV. В локальном Dev Mode INNGEST_DEV=1 отключает проверку подписи, а в production signing key обязателен. Если переменная INNGEST_DEV не задана, TypeScript SDK по умолчанию работает в Cloud mode, поэтому приложение может не подключиться к локальному Dev Server. Секреты нужно передавать через защищённую конфигурацию окружения, а не в исходники. Для диагностики serve endpoint можно запросить его через curl и проверить JSON с message, hasEventKey, hasSigningKey и functionsFound. Нулевое functionsFound означает, что функции не переданы в serve и требует проверки конфигурации приложения. Локальное тестирование включает отправку события через SDK или POST на Dev Server с тестовым event key. Для unit-тестов source описывает пакет @inngest/test и InngestTestEngine, который выполняет функцию и возвращает результат. Это позволяет проверить регистрацию и поведение функций без ручного клика по UI. Docker-вариант публикует 8288 и 8289, а приложение из контейнера Dev Server должно обращаться к нужному SDK URL; на Docker Desktop для приложения хоста используется host.docker.internal, а на Linux нужен эквивалентный host gateway. При Compose важно выставить INNGEST_DEV=1, поскольку SDK иначе пропустит локальный сервер. Команда inngest start предназначена уже для self-hosted production: ей передаются event key и signing key, а для устойчивого хранения рекомендуется внешний Redis и PostgreSQL. Без внешних хранилищ источник указывает локальное in-memory Redis и SQLite в ./.inngest/main.db, что нельзя считать production-персистентностью. После деплоя приложение синхронизируют с Inngest через curl PUT, интеграцию Vercel или Netlify либо Cloud dashboard, а production-ключи задают в окружении. Среди платформенных ограничений отмечены явные serve origin и path для AWS Lambda, специальный путь для Firebase, tunnel для Cloudflare Workers и внешних webhooks, а также необходимость согласовать идентификатор Inngest между деплоями. Skill не обещает одинаковое поведение на всех платформах: при проблемах сначала проверяются порт, URL, discovery, режим SDK, signing key и фактическое число найденных функций.