Trigix is a new open-source workflow automation engine that just hit v1.3.0 with 600-plus tests behind it—and the engineering decisions underneath are worth your attention if you've ever wrestled with bloated SDK dependencies in self-hosted tooling.

The Node Model: One Trait, ~180 Implementations

At its core, Trigix treats every node as one variant of a NodeType enum paired with an async executor function. Adding a new integration touches five fixed locations: the enum variant itself, the executor implementation, a dispatch arm, a type-to-string map, and the frontend palette. This isn't glamorous architecture, but it's intentional—the cost of adding integrations stays bounded and reviewable, and the compiler catches you if you forget something. That's exactly what you want when you're sitting on 180 different node types.

HTTP-First Integrations Cut the Bloat

Most SaaS, database, vector store, and cloud nodes in Trigix are thin HTTP clients returning status and body. The value isn't raw capability—you could use a generic HTTP node for that—but curated config UIs and auth handling. That framing kept roughly 150 nodes small and uniform. For cloud services, the project leans on caller-supplied bearer tokens (GCS, Vertex AI, BigQuery, Snowflake) instead of baking in each provider's OAuth dance. It's an honest trade-off: less magic, but also no credential-exchange code to maintain and no per-provider SDK tax.

Where HTTP Falls Short—and How It Stays Clean

The trickier integrations required custom implementations to keep cargo build self-contained with zero system dependencies. For AWS services (SQS/SNS/Bedrock), the author implemented Signature V4 from scratch using sha2, hmac, and hex crates already in the tree. The implementation is unit-tested against AWS's published canonical test vectors, which pins signature derivation to a known-good answer without any round-trip mocking. SSH and SFTP access uses russh plus russh-sftp instead of ssh2 (which binds libssh2). SQL Server support comes via tiberius, a pure-Rust TDS driver. OCR is the one exception—rather than linking libtesseract at build time, that node shells out to the tesseract CLI at runtime. The key insight: system dependencies at build time tax every contributor and CI run; dependencies at runtime are opt-in and only paid by users who actually need that feature.

Local-First AI Without Cloud Lock-In

The LLM, agent, and RAG nodes speak the OpenAI-compatible wire format, so you can point them at local Ollama or vLLM instances and run everything offline. RAG retrieval runs on your own Postgres with pgvector using hybrid vector-plus-full-text search, optional reranking, and HNSW indexing. Cloud providers are explicitly optional, which matters when self-hosting is the whole point.

Key Takeaways

  • Pure-Rust dependencies eliminate system library requirements at build time—runtime deps stay opt-in
  • Custom Signature V4 implementation replaces AWS SDK with a single unit-tested signer
  • HTTP-first design keeps most integrations to config and auth handling rather than heavy logic
  • OpenAI-compatible AI nodes enable full local deployment without vendor lock-in

The Bottom Line

Trigix isn't trying to be flashy—it's trying to be buildable. The disciplined approach of keeping integration costs low through mechanical patterns, pure-Rust dependencies where possible, and explicit runtime boundaries is exactly the kind of engineering discipline that makes self-hosted tools actually stay maintained. Worth watching.