What if your LLM workflow engine caught the cycle in your pipeline before it ran, instead of three layers deep into a Python stack trace at 2am?
Today we released OxiFY 0.1.0 — a Pure Rust platform that composes complex AI applications as type-safe directed acyclic graphs (DAGs), compiled to native binaries.
OxiFY sits in the same problem space as Dify, LangChain/LangGraph, and Flowise: orchestrating multi-step LLM applications — retrieval, prompting, branching, tool calls — as composable workflows. But where those incumbents are built on Python and TypeScript runtimes held together with glue scripts, OxiFY is a type-safe DAG engine written entirely in Rust. No Python. No Node. No glue-script sprawl. Workflows are real Rust values, validated at construction time, and the whole platform compiles down to native binaries — 100% Pure Rust, per COOLJAPAN policy.
Why OxiFY matters
Anyone who has shipped an LLM application on a Python orchestration stack knows the failure modes. A node’s output shape doesn’t match what the next node expects, and you find out at runtime — deep in an async call chain, after the model call already cost you tokens. Workflows live in fragile YAML that the type system never sees. Adding a custom step means dropping into another language and another deployment artifact. The “platform” is a pile of services glued together with scripts.
OxiFY is a humble first release, but it attacks those problems head-on:
- Type-safe DAGs. A
Workflowis a Rust value built fromNodes andEdges. You callworkflow.validate()and the engine catches cycles and structural problems before execution — not in production. - 15+ node types. Start, End, LLM, Retriever, Vision, Code, IfElse, Tool, plus Loop, Try-Catch, and Sub-workflow — enough vocabulary to express real applications without leaving the graph model.
- In-process vector search. RAG retrieval runs inside the same binary via
oxify-vector; no external vector database required just to get started. - CeleRS-backed distribution. The same workflow that runs in a single-process CLI invocation can have its nodes queued as CeleRS tasks for distributed, scalable execution.
- 2520+ comprehensive tests, including property-based testing with proptest, backing the engine and the platform crates.
Technical Deep Dive: A Workspace of Specialized Crates
OxiFY is not a monolith. It ships as a Cargo workspace of 13 specialized crates, each with a clear responsibility:
- oxify-model — the domain models:
Workflow,Node,Edge,NodeKind,LlmConfig. This is the type-safe vocabulary you build workflows from. - oxify-engine — the DAG execution engine: topological-sort ordering, conditional and parallel execution, retry, and checkpointing. Code nodes execute in a sandbox built on Rhai and WebAssembly (via wasmer), and the engine supports cron scheduling.
- oxify-api — the REST + GraphQL surface, built on Axum and async-graphql, exposing 30+ REST endpoints.
- oxify-server — the Axum HTTP server and middleware layer.
- oxify-authn — authentication: JWT, OAuth2, and API-key support.
- oxify-authz — authorization: RBAC and policy enforcement.
- oxify-vector — an in-memory vector search engine: Euclidean / Cosine / Dot / Manhattan metrics, HNSW indexing, IVF with Product Quantization, FP16 quantization, SIMD (AVX2 / AVX-512 / NEON), mmap persistence, and sparse CSR support.
- oxify-connect-llm — provider clients for OpenAI, Anthropic, Cohere, and Ollama.
- oxify-connect-vector — a Qdrant client for external vector-DB integration.
- oxify-connect-vision — image preprocessing and OCR providers.
- oxify-mcp — a Model Context Protocol server, so your workflows can be exposed as tools to other agents.
- oxify-cli — the command-line interface (
oxify-cli, also invoked asoxifyin examples). - oxify-ui — an Axum-based web UI.
- oxify-storage — SQLite-backed storage for workflows and executions, with versioning. (Storage was migrated from PostgreSQL to SQLite for a lighter, self-contained footprint.)
The node types map directly onto real work: Start / End bracket the graph, LLM calls a model provider, Retriever pulls context for RAG, Vision handles image input, Code runs custom logic (Rhai script or WebAssembly via wasmer) without leaving Rust, IfElse branches, and Tool invokes MCP tools — with Loop, Try-Catch, and Sub-workflow rounding out the 15+ available kinds.
Getting Started
OxiFY 0.1.0 ships as a workspace, so you build it from source:
git clone https://github.com/cool-japan/oxify.git
cd oxify
cargo build --release
To use OxiFY as a library, depend on the crates you need directly from Git:
[dependencies]
oxify-model = { git = "https://github.com/cool-japan/oxify.git" }
oxify-engine = { git = "https://github.com/cool-japan/oxify.git" }
Here’s a minimal chat workflow defined with the real oxify-model API — a Start node, an LLM node, and an End node, wired together as a DAG:
use oxify_model::{Workflow, Node, NodeKind, Edge, LlmConfig};
let mut workflow = Workflow::new("Simple Chat".to_string());
let start = Node::new("Start".to_string(), NodeKind::Start);
let llm = Node::new("LLM".to_string(), NodeKind::LLM(LlmConfig {
provider: "openai".to_string(),
model: "gpt-4".to_string(),
system_prompt: Some("You are a helpful assistant.".to_string()),
prompt_template: "{{user_input}}".to_string(),
temperature: Some(0.7),
max_tokens: Some(1000),
extra_params: serde_json::Value::Null,
}));
let end = Node::new("End".to_string(), NodeKind::End);
let (start_id, llm_id, end_id) = (start.id, llm.id, end.id);
workflow.add_node(start);
workflow.add_node(llm);
workflow.add_node(end);
workflow.add_edge(Edge::new(start_id, llm_id));
workflow.add_edge(Edge::new(llm_id, end_id));
workflow.validate()?;
And from the CLI, validate and run a workflow defined in JSON:
cargo run --bin oxify -- validate --workflow ./workflows/chat.json
cargo run --bin oxify -- run --workflow ./workflows/chat.json --input '{"user_input": "Hello!"}'
What’s inside
Everything that lands in OxiFY 0.1.0:
- A Cargo workspace of 13 specialized crates, cleanly separated by concern.
- SQLite storage (migrated from PostgreSQL) for workflows and executions, with versioning.
- A GraphQL + REST API built on async-graphql and Axum, exposing 30+ REST endpoints.
- oxify-vector — in-memory vector search with HNSW, IVF + Product Quantization, FP16 quantization, SIMD (AVX2 / AVX-512 / NEON), mmap persistence, sparse CSR, and GPU/CUDA acceleration on Linux.
- LLM connectors for OpenAI, Anthropic, Cohere, and Ollama.
- A Qdrant vector-DB connector for external retrieval.
- Vision / OCR preprocessing.
- Security: JWT authentication, RBAC authorization, and AES-256-GCM encryption.
- The DAG engine: conditional, parallel, and retried execution; a Rhai + WebAssembly sandbox for Code nodes; and cron scheduling.
- An MCP server for exposing workflows as agent tools.
- A web UI for building and inspecting workflows.
- OpenTelemetry observability throughout.
- 2520+ tests, including property-based testing with proptest.
Under the hood, the engine also supports pause-resume checkpointing, webhooks, LLM response caching (TTL) plus execution-plan caching (LRU), SSE streaming, and token-bucket rate limiting (default 500 req/min). The workspace targets Rust edition 2021 and builds on tokio 1.49, axum 0.8, async-graphql 7.2, reqwest, qdrant-client, sqlx (sqlite), rhai, wasmer 6.1, and OpenTelemetry.
Tips
A few ways to get the most out of OxiFY 0.1.0:
- Validate before you run. Model your application as a DAG and call
workflow.validate()— the engine topologically sorts execution order and will catch cycles and structural errors before a single token is spent. - Stay in Rust with the Code node. When a step needs custom logic, use a Code node (Rhai script or WebAssembly via wasmer) to drop it straight into the pipeline — no separate language, no separate deployment artifact.
- Scale by queueing onto CeleRS. Start with a single-process
oxifyCLI run; when you need to scale, queue workflow nodes as CeleRS tasks for distributed execution. The graph definition doesn’t change. - Checkpoint long or costly workflows. Turn on checkpointing / pause-resume for long-running pipelines, and enable the LLM response cache (TTL) so retries and reruns don’t repeat token spend.
- Expose workflows as tools over MCP. Run
oxify-mcpso other agents can call your workflows through the Model Context Protocol — your pipeline becomes a tool in someone else’s stack. - Skip the external vector DB for RAG. Use
oxify-vector’s HNSW / IVF index for in-process retrieval instead of standing up Qdrant or another external service just to get a prototype running.
This is the foundation
OxiFY ships into a young but fast-growing Pure Rust ecosystem, and it doesn’t stand alone. Its architectural backbone is CeleRS — the distributed task system that launched in the same 2026-01-19 cohort — which lets OxiFY graduate from a single process to a distributed cluster by queueing nodes as tasks. That sibling relationship is the whole point: OxiFY supplies the type-safe orchestration model, CeleRS supplies the distribution.
In the spirit of honesty about provenance: OxiFY’s security and server layer — the ReBAC-style authorization, JWT/OAuth2 authentication, the Axum server, and the vector search used for RAG — was ported from the OxiRS codebase, a semantic-web platform. That’s code lineage, not a runtime dependency; it’s simply where this hardened foundation came from.
OxiFY also rides on the broader COOLJAPAN Pure Rust stack — the numerical and data work of SciRS2, NumRS2, and PandRS; compression via OxiArc; FFT via OxiFFT; constraint solving via OxiZ; and speech via VoiRS — a sovereign, C/C++/Fortran-free foundation underneath the whole platform.
Repository: https://github.com/cool-japan/oxify
Star the repo if a type-safe, native-compiled alternative to the Python orchestration stacks is what you’ve been waiting for: https://github.com/cool-japan/oxify. Pure Rust LLM orchestration is here — type-safe, fast, and sovereign.
— KitaSan at COOLJAPAN OÜ January 19, 2026