v1.14.0

✨ New Features

Async Deploy & Undeploy

Runtime deploy and undeploy operations — via both REST API and MCP — now run asynchronously off the event loop using asyncio.to_thread. This means deploying or undeploying a pipeline no longer blocks other incoming requests.

A new HAYHOOKS_DEPLOY_CONCURRENCY setting controls how these operations are synchronized:

• serialized (default): One deploy/undeploy at a time — safe and predictable.
• parallel: Allow concurrent deploy/undeploy for higher admin throughput.

# Default: one deploy at a time (safe)
export HAYHOOKS_DEPLOY_CONCURRENCY=serialized

# Advanced: concurrent deploys (use with caution)
export HAYHOOKS_DEPLOY_CONCURRENCY=parallel

Parallel Startup Deployment

When many pipelines are loaded from HAYHOOKS_PIPELINES_DIR at startup, deployment time can now be dramatically reduced. Hayhooks introduces a two-phase approach: pipelines are prepared in parallel (file I/O, module loading, wrapper setup()) using a bounded thread pool, then committed serially to the registry with a single OpenAPI schema rebuild at the end.

Two new environment variables control this behavior:

Variable	Default	Description
HAYHOOKS_STARTUP_DEPLOY_STRATEGY	parallel	parallel or sequential
HAYHOOKS_STARTUP_DEPLOY_WORKERS	4	Max worker threads (1–32)

# Parallel startup with 8 workers (recommended for many pipelines)
export HAYHOOKS_STARTUP_DEPLOY_STRATEGY=parallel
export HAYHOOKS_STARTUP_DEPLOY_WORKERS=8

# Fall back to sequential if needed
export HAYHOOKS_STARTUP_DEPLOY_STRATEGY=sequential

🏗️ Internal Improvements

Prepare / Commit Architecture

The deploy logic has been refactored into a clean two-phase pattern:

1. Prepare — the expensive, thread-safe work (file I/O, YAML parsing, module loading, wrapper setup()) is isolated into prepare_pipeline_yaml and prepare_pipeline_files, which return a PreparedPipeline dataclass.
2. Commit — the cheap, shared-state mutations (registry update, route addition) happen in commit_prepared_pipeline, which must run serially.

This separation is what enables both parallel startup and the async deploy/undeploy features.

Deferred OpenAPI Rebuild

During batch startup deployments, the OpenAPI schema is now rebuilt exactly once at the end instead of after every individual pipeline. This avoids redundant app.setup() calls and further reduces startup latency.

YAML Parse-Once Optimization

YAML source code is now parsed once via parse_yaml_pipeline() and shared with downstream helpers (get_inputs_outputs_from_yaml, get_streaming_components_from_yaml), eliminating redundant yaml.safe_load calls per pipeline.

log_elapsed Decorator

A new log_elapsed logging utility automatically measures and logs wall-clock time for decorated functions — used throughout the deploy pipeline for observability.

📚 Documentation

• Added Startup Deploy Performance section to Deployment Guidelines
• Added Runtime Deploy Concurrency section to Deployment Guidelines
• Documented new environment variables: HAYHOOKS_DEPLOY_CONCURRENCY, HAYHOOKS_STARTUP_DEPLOY_STRATEGY, HAYHOOKS_STARTUP_DEPLOY_WORKERS in the Environment Variables reference

🧪 Tests

• Added comprehensive test suite for async deploy/undeploy, parallel vs. sequential startup, deferred OpenAPI rebuild, prepare/commit pipeline workflow, and deploy concurrency policies

🔧 CI

• Switched to the official Hatch install GitHub Action (pypa/hatch@install) for faster and more reliable CI across all workflows

---

What's Changed

• Async / parallel deployment with prepare-commit architecture, refactoring and tests by @mpangrazzi
• ci: use Hatch install action by @anakin87 in #226

Full Changelog: v1.13.0...v1.14.0