{"id":52004223,"url":"https://github.com/GoPlasmatic/Orion","last_synced_at":"2026-08-01T04:00:40.619Z","repository":{"id":350241060,"uuid":"1163732401","full_name":"GoPlasmatic/Orion","owner":"GoPlasmatic","description":"An API-first declarative services runtime in Rust. Build and scale governed REST \u0026 Kafka endpoints with JSON workflows, built-in observability, and AI safety rails.","archived":false,"fork":false,"pushed_at":"2026-07-18T05:44:09.000Z","size":2100,"stargazers_count":7,"open_issues_count":1,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2026-07-18T06:08:57.487Z","etag":null,"topics":["business-logic","business-rules","data-pipeline","event-processing","jsonlogic","rules-engine","rust","workflow-engine"],"latest_commit_sha":null,"homepage":"https://goplasmatic.io/orion","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/GoPlasmatic.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-02-22T03:51:51.000Z","updated_at":"2026-07-18T05:44:13.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/GoPlasmatic/Orion","commit_stats":null,"previous_names":["goplasmatic/orion"],"tags_count":4,"template":false,"template_full_name":null,"purl":"pkg:github/GoPlasmatic/Orion","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GoPlasmatic%2FOrion","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GoPlasmatic%2FOrion/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GoPlasmatic%2FOrion/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GoPlasmatic%2FOrion/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/GoPlasmatic","download_url":"https://codeload.github.com/GoPlasmatic/Orion/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/GoPlasmatic%2FOrion/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":36141856,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-07-20T02:08:10.276Z","status":"online","status_checked_at":"2026-08-01T02:00:05.789Z","response_time":100,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["business-logic","business-rules","data-pipeline","event-processing","jsonlogic","rules-engine","rust","workflow-engine"],"created_at":"2026-07-31T14:00:21.777Z","updated_at":"2026-08-01T04:00:40.596Z","avatar_url":"https://github.com/GoPlasmatic.png","language":"Rust","funding_links":[],"categories":["Automation"],"sub_categories":[],"readme":"\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"https://avatars.githubusercontent.com/u/207296579?s=200\u0026v=4\" alt=\"Orion Logo\" width=\"120\" height=\"120\"\u003e\n\n  # Orion\n\n  **Deploy high-performance, governed microservices as JSON workflows—without writing boilerplate.**\n\n  [![CI](https://github.com/GoPlasmatic/Orion/actions/workflows/ci.yml/badge.svg)](https://github.com/GoPlasmatic/Orion/actions/workflows/ci.yml)\n  [![Crates.io](https://img.shields.io/crates/v/orion-server.svg)](https://crates.io/crates/orion-server)\n  [![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)\n  [![Rust](https://img.shields.io/badge/rust-1.88+-orange.svg)](https://www.rust-lang.org)\n  [![Docs](https://img.shields.io/badge/docs-mdBook-blue.svg)](https://goplasmatic.github.io/Orion/)\n  [![JSONLogic](https://img.shields.io/badge/JSONLogic-standard-green.svg)](https://jsonlogic.com)\n  [![GitHub Release](https://img.shields.io/github/v/release/GoPlasmatic/Orion)](https://github.com/GoPlasmatic/Orion/releases)\n  [![GitHub Stars](https://img.shields.io/github/stars/GoPlasmatic/Orion?style=social)](https://github.com/GoPlasmatic/Orion)\n\u003c/div\u003e\n\nOrion is an API-first declarative services runtime written in Rust. Instead of writing, containerizing, and operating a new microservice for every piece of business logic, you simply **declare** what the service should do as a JSON workflow, and Orion runs it. \n\nEvery workflow is executed with enterprise-grade architectural governance—including observability, rate limiting, circuit breakers, caching, input validation, and versioning—built directly into the runtime, not bolted on. Build workflows yourself or let an AI generate them; either way, they run under the same production-grade guarantees.\n\n**Jump to:** [Quickstart](#your-first-service-in-2-minutes) · [Why Orion?](#why-orion) · [Is Orion right for you?](#is-orion-right-for-you) · [Three primitives](#three-primitives) · [The console](#the-console) · [What's built in](#whats-built-in) · [Connectors](#connect-to-anything) · [Functions](#built-in-task-functions) · [Performance](#performance) · [Install](#install) · [Docs](#documentation)\n\n---\n\n## Why Orion?\n\nDevelopers spend too much time building the same boilerplate for microservices—setting up HTTP servers, configuring database connection pools, writing Prometheus exporters, integrating OpenTelemetry, and coding retry loops or circuit breakers. Orion eliminates this overhead entirely.\n\n* **⚡ Zero Boilerplate:** Go from idea to a live REST/Kafka service in seconds. No Dockerfiles, no CI pipelines, and no server boilerplates.\n* **🛡️ Built-in Governance:** Out-of-the-box support for rate limiting, circuit breakers, timeouts, caching, and payload validation.\n* **🤖 AI-Native \u0026 Safe:** Structured JSON workflows are exceptionally easy for LLMs to generate. Safe rollout pipelines (validation, draft/dry-run, rollout percentage, rollbacks) ensure AI-generated code never breaks production.\n* **🦀 Rust Performance:** Built on Tokio and Axum. Achieves **6,000+ requests/sec** per instance with single-digit millisecond latency and a tiny memory footprint.\n* **🧩 In-Process Composition:** Call other workflows in-process like functions with zero network round-trip overhead.\n\n---\n\n## Your First Service in 2 Minutes\n\nNo code. No Dockerfile. No CI pipeline. Just a running service.\n\n\u003cdiv align=\"center\"\u003e\n  \u003cpicture\u003e\n    \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"media/ui-quickstart-dark.gif\"\u003e\n    \u003cimg src=\"media/ui-quickstart-light.gif\" alt=\"Import a workflow, validate and dry-run it, create a channel in a form, send a request, and see the live service map — all in the Orion console, no code\" width=\"100%\"\u003e\n  \u003c/picture\u003e\n  \u003cbr\u003e\n  \u003cem\u003eZero to a live service in under a minute: declare the logic, validate and dry-run it, give it an endpoint, send a request — tracing and metrics already on. Prefer a terminal? The same flow is four curl calls, below.\u003c/em\u003e\n\u003c/div\u003e\n\n**1. Start Orion**\n\n```bash\nbrew install GoPlasmatic/tap/orion-server   # or: curl installer, cargo install (see Install)\norion-server\n```\n\n**2. Deploy your first service — one command**\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/GoPlasmatic/Orion/main/examples/quickstart.sh | bash\n```\n\nThe script talks to the same admin API you'd use in production: it creates a **workflow** (the logic — flag any order over $10,000 for review) and a **channel** (the endpoint — `POST /orders`), activates both, and sends a first test order. Re-running it is safe. Cloned the repo? Run `./examples/quickstart.sh` instead.\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cb\u003eWhat the script does — the four API calls, spelled out\u003c/b\u003e\u003c/summary\u003e\n\n\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"media/quickstart.gif\" alt=\"Define a workflow and channel over HTTP, then send a request and get a governed response — all in under a minute\" width=\"100%\"\u003e\n\u003c/div\u003e\n\nCreate the workflow (business logic as JSON — a parse task, then a conditional flag task):\n\n```bash\ncurl -s -X POST http://localhost:8080/api/v1/admin/workflows \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"workflow_id\": \"high-value-order\",\n    \"name\": \"High-Value Order\",\n    \"condition\": true,\n    \"tasks\": [\n      { \"id\": \"parse\", \"name\": \"Parse payload\", \"function\": {\n          \"name\": \"parse_json\",\n          \"input\": { \"source\": \"payload\", \"target\": \"order\" }\n      }},\n      { \"id\": \"flag\", \"name\": \"Flag order\",\n        \"condition\": { \"\u003e\": [{ \"var\": \"data.order.total\" }, 10000] },\n        \"function\": {\n          \"name\": \"map\",\n          \"input\": { \"mappings\": [\n            { \"path\": \"data.order.flagged\", \"logic\": true },\n            { \"path\": \"data.order.alert\", \"logic\": { \"cat\": [\"High-value order: $\", { \"var\": \"data.order.total\" }] } }\n          ]}\n      }}\n    ]\n  }'\n\n# Activate it (draft → active; the engine hot-reloads)\ncurl -s -X PATCH http://localhost:8080/api/v1/admin/workflows/high-value-order/status \\\n  -H \"Content-Type: application/json\" -d '{\"status\": \"active\"}'\n```\n\nCreate the channel — the endpoint that routes to the workflow — and activate it:\n\n```bash\ncurl -s -X POST http://localhost:8080/api/v1/admin/channels \\\n  -H \"Content-Type: application/json\" \\\n  -d '{ \"channel_id\": \"orders\", \"name\": \"orders\", \"channel_type\": \"sync\",\n        \"protocol\": \"rest\", \"route_pattern\": \"/orders\",\n        \"methods\": [\"POST\"], \"workflow_id\": \"high-value-order\" }'\n\ncurl -s -X PATCH http://localhost:8080/api/v1/admin/channels/orders/status \\\n  -H \"Content-Type: application/json\" -d '{\"status\": \"active\"}'\n```\n\n\u003c/details\u003e\n\n**3. Call it — your service is live**\n\n```bash\ncurl -s -X POST http://localhost:8080/api/v1/data/orders \\\n  -H \"Content-Type: application/json\" \\\n  -d '{ \"data\": { \"order_id\": \"ORD-9182\", \"total\": 25000 } }'\n```\n\n```json\n{\n  \"status\": \"ok\",\n  \"data\": {\n    \"order\": {\n      \"order_id\": \"ORD-9182\",\n      \"total\": 25000,\n      \"flagged\": true,\n      \"alert\": \"High-value order: $25000\"\n    }\n  }\n}\n```\n\nThat's it. The business logic is a JSON document, deploying it was an API call, and rate limiting, metrics, health checks, and request tracing were already active when it went live. Change the threshold? One API call. No rebuild, no redeploy, no restart.\n\n\u003e **Prefer to describe the service instead of writing it?** Workflow JSON is exceptionally easy for LLMs to generate — tell your AI assistant *\"flag orders over $10,000 for manual review with an alert message\"* and deploy what it returns. [AI Writes Services, Not Code](#ai-writes-services-not-code) shows the safe path from prompt to production.\n\n---\n\n## Is Orion Right for You?\n\n| If you need to... | Orion? | Why |\n|---|:-:|---|\n| Turn business rules into live REST/Kafka services | **Yes** | Define logic as JSON workflows, deploy with one API call |\n| Let AI generate and manage business logic | **Yes** | Built-in validation, dry-run testing, and draft-before-activate safety |\n| Replace a handful of single-purpose microservices | **Yes** | One instance handles many channels, governance included |\n| Use a rule engine like Drools | **Not quite** | Orion uses [JSONLogic](https://jsonlogic.com) via [datalogic-rs](https://github.com/GoPlasmatic/datalogic-rs) for conditions and transforms. Lightweight and AI-friendly, but not a full RETE-based rule engine with complex fact networks |\n| Embed a workflow engine library in your app | **No** | Orion is a standalone runtime, not a library. For an embeddable workflow engine, see [dataflow-rs](https://github.com/GoPlasmatic/dataflow-rs) which Orion is built on |\n| Manage services from a browser dashboard | **Yes** | [Orion UI](https://github.com/GoPlasmatic/Orion-ui) — manage workflows/channels/connectors, visualize pipelines, monitor health (Orion itself stays API-first) |\n| Orchestrate long-running jobs (hours/days) | No | Use Temporal or Airflow. Orion is optimized for request-response and event processing |\n| Run a full API gateway with plugin ecosystem | No | Use Kong or Envoy. Orion focuses on service logic, not proxy features |\n| General-purpose compute (image processing, ML) | No | Orion's task functions operate on JSON data. Use custom services or serverless for arbitrary compute |\n| Stateful workflows with human-in-the-loop approvals | No | Use [Temporal](https://temporal.io) or BPMN engines. Orion workflows are stateless request pipelines |\n\nLonger, tool-by-tool discussion (Temporal, Kong, Drools, n8n, dataflow-rs): [Is Orion Right for You?](https://goplasmatic.github.io/Orion/comparison.html)\n\n---\n\n## Three Primitives\n\nYou build services in Orion with three things:\n\n```mermaid\ngraph LR\n    C[\"Channel\u003cbr\u003e(endpoint)\"] --\u003e W[\"Workflow\u003cbr\u003e(logic)\"]\n    W --\u003e Co[\"Connector\u003cbr\u003e(external)\"]\n\n    style C fill:#21252b,stroke:#61afef,stroke-width:2px,color:#abb2bf\n    style W fill:#21252b,stroke:#61afef,stroke-width:2px,color:#abb2bf\n    style Co fill:#21252b,stroke:#61afef,stroke-width:2px,color:#abb2bf\n```\n\n| Primitive | What it is | Example |\n|-----------|-----------|---------|\n| **Channel** | A service endpoint: sync (REST, HTTP) or async (Kafka) | `POST /orders`, `GET /users/{id}`, Kafka topic `order.placed` |\n| **Workflow** | A pipeline of tasks that defines what the service does | Parse → validate → enrich → transform → respond |\n| **Connector** | A named connection to an external system, with auth and retries | Stripe API, PostgreSQL, Redis, Kafka cluster |\n\n**Design-time:** define channels, build workflows, configure connectors, test with dry-run, manage versions, all through the admin API.\n\n**Runtime:** Orion routes traffic to channels, executes workflows, calls connectors, and handles observability automatically.\n\n---\n\n## The Console\n\nOrion itself is API-first, and everything it does is also point-and-click: [Orion UI](https://github.com/GoPlasmatic/Orion-ui) is the operations console for a running instance — live dashboards, a system map of every channel → workflow → connector, workflow logic visualization, trace drill-downs, and a data console for firing test requests (`docker compose up` next to the server, or `npm run dev`).\n\n\u003cpicture\u003e\n  \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"media/ui-operations-dark.png\"\u003e\n  \u003cimg src=\"media/ui-operations-light.png\" alt=\"Operations dashboard — request rate, error rate, latency percentiles, outcomes by channel, top channels, and recent traces for a live Orion instance\" width=\"100%\"\u003e\n\u003c/picture\u003e\n\u003cem\u003eOperations: live request rate, error rate, latency, and traces for every channel.\u003c/em\u003e\n\n\u003cpicture\u003e\n  \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"media/ui-system-map-dark.png\"\u003e\n  \u003cimg src=\"media/ui-system-map-light.png\" alt=\"System Map — the orders channel traced through the workflow it runs, rendered as a live topology graph\" width=\"100%\"\u003e\n\u003c/picture\u003e\n\u003cem\u003eSystem Map: any channel traced through the workflow it runs and the connectors it touches.\u003c/em\u003e\n\n---\n\n## AI Writes Services, Not Code\n\nWhen AI generates a microservice, you still need to add health checks, metrics, retries, and error handling. When AI generates an Orion workflow, **all of that is already there**. The platform guarantees it.\n\n**Use the [Orion CLI's MCP server](https://github.com/GoPlasmatic/Orion-cli)** to give your AI assistant full Orion context. No manual prompt engineering needed. The MCP server exposes 46 tools covering the full Orion API — workflow syntax, available functions, connector types, and API operations. One config block and you're done (Claude Code `.mcp.json`, Claude Desktop, or any MCP client):\n\n```json\n{\n  \"mcpServers\": {\n    \"orion\": {\n      \"command\": \"orion-cli\",\n      \"args\": [\"mcp\", \"serve\"],\n      \"env\": { \"ORION_SERVER_URL\": \"http://localhost:8080\" }\n    }\n  }\n}\n```\n\nNo MCP client? Paste the [**prompt pack**](https://goplasmatic.github.io/Orion/getting-started/prompt-pack.html) — a self-contained context block with Orion's schemas, conventions, and API calls — into any LLM and it can write and deploy workflows through the plain REST API.\n\n```\nYou: \"Classify orders into VIP (\u003e=500, 15% discount), Premium (100-500, 5%), and Standard tiers\"\n\nAI:  → generates valid workflow JSON\n     → creates it via the API\n     → tests with dry-run\n     → activates when you approve\n```\n\n**Safe path from AI output to production — every time:**\n\n```mermaid\ngraph TD\n    A[\"1. Generate\u003cbr\u003e(AI Workflow JSON via MCP)\"] --\u003e B[\"2. Validate\u003cbr\u003e(Verify JSON Syntax \u0026 Schema)\"]\n    B --\u003e C[\"3. Create Draft\u003cbr\u003e(Saved in DB, Offline)\"]\n    C --\u003e D[\"4. Dry-Run Test\u003cbr\u003e(Verify with Sample Data)\"]\n    D --\u003e E[\"5. Activate\u003cbr\u003e(Engine hot-reloads)\"]\n    E --\u003e F[\"6. Canary Rollout\u003cbr\u003e(10% → 50% → 100% traffic)\"]\n\n    style A fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style B fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style C fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style D fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style E fill:#2e3f2f,stroke:#98c379,stroke-width:2px,color:#98c379\n    style F fill:#293c4e,stroke:#61afef,stroke-width:2px,color:#61afef\n```\n\nEvery AI-generated workflow gets version history, draft-before-activate, dry-run testing, rollout control, structured `FieldError` validation feedback, and audit trails — the same governance as hand-written ones. Roll back to any previous version instantly.\n\nNeed to ship a bundle of workflows, channels, or connectors at once (e.g. promoting from staging)? Use the bulk import endpoints — `POST /api/v1/admin/{workflows,channels,connectors}/import?dry_run=true` validates the whole batch first; drop `dry_run` to commit.\n\nSee [Use Cases \u0026 Patterns](https://goplasmatic.github.io/Orion/tutorials/use-cases.html#ai-workflow--cicd) for CI/CD integration and GitHub Actions examples.\n\n---\n\n## Before \u0026 After\n\n**Before** — every piece of business logic is its own service to build, deploy, and operate:\n\n```mermaid\ngraph TD\n    Client[\"API Clients\"] --\u003e GW[\"API Gateway\"]\n    GW --\u003e PS[\"Pricing Service\"] --\u003e DB[(\"Database\")]\n    GW --\u003e FS[\"Fraud Service\"] --\u003e RD[(\"Redis Cache\")]\n    GW --\u003e RS[\"Routing Service\"] --\u003e KF[(\"Kafka Cluster\")]\n    GW --\u003e NS[\"Notification Service\"] --\u003e SM[\"SMTP Server\"]\n\n    style Client fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style GW fill:#e06c75,stroke:#e06c75,color:#1e222b\n    style PS fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style FS fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style RS fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style NS fill:#21252b,stroke:#5c6370,color:#abb2bf\n```\n\n**After** — one Orion instance replaces all four (with API gateway and logic engine consolidated, routing traffic, executing workflows, and automatically handling governance):\n\n```mermaid\ngraph TD\n    Client[\"API Clients\"] --\u003e Orion[\"Orion Server Runtime\"]\n    \n    subgraph Orion [\"Orion Runtime (Single Binary)\"]\n        direction TB\n        C1[\"/pricing (Workflow)\"]\n        C2[\"/fraud (Workflow)\"]\n        C3[\"/routing (Workflow)\"]\n        C4[\"/notify (Workflow)\"]\n        Gov[\"Built-in: Rate Limiting, Metrics, Tracing, Circuit Breakers\"]\n    end\n    \n    C1 --\u003e DB[(\"Database\")]\n    C2 --\u003e RD[(\"Redis Cache\")]\n    C3 --\u003e KF[(\"Kafka Cluster\")]\n    C4 --\u003e SM[\"SMTP Server\"]\n\n    style Client fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style Orion fill:#282c34,stroke:#abb2bf,stroke-width:2px,color:#abb2bf\n    style C1 fill:#61afef,stroke:#61afef,color:#1e222b\n    style C2 fill:#61afef,stroke:#61afef,color:#1e222b\n    style C3 fill:#61afef,stroke:#61afef,color:#1e222b\n    style C4 fill:#61afef,stroke:#61afef,color:#1e222b\n    style Gov fill:#e5c07b,stroke:#e5c07b,color:#1e222b\n```\n\n**The best of both worlds:** each channel and workflow is independently versioned, testable, and deployable. The modularity of microservices with the operational simplicity of a monolith. Change one workflow without touching the others. Roll back a single channel without redeploying everything.\n\n---\n\n## What's Built In\n\nEvery channel gets production-grade features without writing a line of code. Configure per channel or use platform defaults:\n\n| Feature | What it does | Configuration |\n|---------|-------------|---------------|\n| **Rate limiting** | Throttle requests per client or globally | `requests_per_second`, `burst`, JSONLogic key computation |\n| **Timeouts** | Cancel slow workflows, return 504 | `timeout_ms` per channel |\n| **Input validation** | Reject bad requests at the boundary | JSONLogic with access to headers, query params, path params |\n| **Backpressure** | Shed load when overwhelmed, return 503 | `max_concurrent` (semaphore-based) |\n| **CORS** | Control browser cross-origin access | `allowed_origins` per channel |\n| **Circuit breakers** | Stop cascading failures to external services | Automatic per connector, admin API to inspect/reset |\n| **Versioning** | Draft → active → archived lifecycle | Automatic version history, rollout percentages, instant rollback |\n| **Observability** | Prometheus metrics, structured logs, distributed tracing | Always on, zero configuration |\n| **Health checks** | Component-level status with degradation detection | `GET /health`, automatic |\n| **Request IDs** | UUID propagated through the entire pipeline | `x-request-id` header, automatic |\n| **Deduplication** | Prevent duplicate processing via idempotency keys | `Idempotency-Key` header, configurable retention window |\n| **Response caching** | Cache responses for identical requests | TTL-based, configurable cache key fields |\n| **Per-request profiling** | Break a single request down by phase (engine lock, workflow run, tasks) | Opt in with `X-Orion-Profile: 1` or `?profile=1`; surfaces under `_orion.profile` |\n| **Per-task tracing** | Capture each task's input/output for replay and debugging | Channel-level `config.tracing.per_task = true`; stored on the trace row |\n\nA minimal channel needs only a name and a workflow. Everything else has sensible defaults.\n\n\u003e **Observability deep dive:** health endpoints, full Prometheus metrics list, Kubernetes probes, and OpenTelemetry tracing config. See [Observability Guide](https://goplasmatic.github.io/Orion/features/observability.html).\n\n---\n\n## Sync and Async\n\n```\nSync     POST /api/v1/data/{channel}         → immediate response\nAsync    POST /api/v1/data/{channel}/async   → returns trace_id, poll later\n\nREST     GET /api/v1/data/orders/{id}        → matched by route pattern\nKafka    topic: order.placed                 → consumed automatically\n```\n\nSync channels respond immediately. Async channels return a trace ID; poll `GET /api/v1/data/traces/{id}` for results. Kafka channels consume from topics configured in the DB or config file, no restart needed when you add new ones.\n\n**Bridging is a pattern, not a feature.** A sync workflow can `publish_kafka` and return 202. An async channel picks it up from there.\n\nREST channels support parameterized route patterns (`/orders/{order_id}`) with path, query, and header injection into the workflow context. See [Data API](https://goplasmatic.github.io/Orion/api/data.html#route-resolution).\n\n## Service Composition\n\nMost platforms require HTTP calls between services, adding latency, failure modes, and serialization overhead. Orion's `channel_call` invokes another channel's workflow **in-process** with zero network round-trip:\n\n```mermaid\ngraph TD\n    Req[\"POST /orders (Workflow)\"] --\u003e P[\"parse_json\u003cbr\u003e(Extract order data)\"]\n    P --\u003e C1[\"channel_call\u003cbr\u003e(inventory-check)\"]\n    C1 --\u003e C2[\"channel_call\u003cbr\u003e(customer-lookup)\"]\n    C2 --\u003e M[\"map\u003cbr\u003e(Compute pricing)\"]\n    M --\u003e Res[\"publish_json\u003cbr\u003e(Combined response)\"]\n\n    classDef task fill:#21252b,stroke:#5c6370,color:#abb2bf;\n    classDef inprocess fill:#61afef,stroke:#61afef,color:#1e222b;\n    class P,M,Res task;\n    class C1,C2 inprocess;\n```\n\nEach composed channel has its own workflow, versioning, and governance, but calls between them are function calls, not network hops. Cycle detection prevents infinite recursion.\n\n---\n\n## Connect to Anything\n\nConnectors are named, reusable connections to external systems. Configure once, reference by name in any workflow. Credentials stay out of your logic:\n\n| Connector type | Systems | Features |\n|---------------|---------|----------|\n| **HTTP** | Any REST API, webhook, or service | Bearer / Basic / API key auth, retry with backoff, SSRF protection |\n| **Database** | PostgreSQL, MySQL, SQLite | Parameterized queries, connection pooling, read + write operations |\n| **Cache** | In-memory (built-in) or Redis | TTL-based expiry, also powers deduplication and response caching |\n| **MongoDB** | Any MongoDB instance | Document queries, BSON-to-JSON conversion, connection pooling |\n| **Elasticsearch** | Any Elasticsearch cluster | Portable `data_query`/`data_write` rendered to Query DSL and `_bulk`, via the shared HTTP client |\n| **Kafka** | Any Kafka cluster | Publish with key/value logic, consume with DLQ routing |\n\nEvery connector gets **circuit breaker protection** automatically: failures trip the breaker, subsequent calls fast-fail, and the breaker auto-recovers. Database and Elasticsearch connectors also carry **per-operation gates** (`operations: { read, insert, update, delete, upsert, raw_write }`) — set `\"delete\": false` and no workflow can delete through that connector, no matter what its tasks say. Secrets are stored in the database and masked in API responses, and any string field can use an `env://VAR_NAME` reference to pull the value from the process environment at startup so production credentials never sit in the saved config. See [Connectors Guide](https://goplasmatic.github.io/Orion/features/extensibility.html#connectors) for configuration examples and auth options.\n\n---\n\n## Built-in Task Functions\n\n| Function | Description |\n|----------|-------------|\n| `parse_json` | Parse payload into the data context for downstream tasks |\n| `parse_xml` | Parse XML payloads into structured JSON |\n| `filter` | Allow or halt processing based on JSONLogic conditions |\n| `map` | Transform and reshape JSON using JSONLogic expressions |\n| `validation` | Enforce required fields, constraints, and schema-like checks |\n| `http_call` | Invoke downstream APIs, webhooks, or services via [connectors](https://goplasmatic.github.io/Orion/features/extensibility.html#connectors) |\n| `channel_call` | Invoke another channel's workflow in-process |\n| `data_query` | Portable, backend-neutral read — filter, project, sort, paginate, include related records — runs unchanged on SQL, MongoDB, or Elasticsearch |\n| `data_write` | Portable insert/update/delete/upsert using the same envelope across SQL, MongoDB, and Elasticsearch |\n| `db_read` | Execute raw SQL SELECT queries, return rows as JSON (escape hatch for CTEs, aggregations, hand-tuned SQL) |\n| `db_write` | Execute raw SQL INSERT/UPDATE/DELETE, return affected count |\n| `cache_read` | Read from in-memory or Redis cache |\n| `cache_write` | Write to cache with optional TTL |\n| `mongo_read` | Query MongoDB collections, BSON-to-JSON conversion |\n| `publish_json` | Serialize data to JSON output format |\n| `publish_xml` | Serialize data to XML output format |\n| `publish_kafka` | Publish messages to [Kafka topics](https://goplasmatic.github.io/Orion/features/extensibility.html#kafka-connector) |\n| `log` | Emit structured log entries for auditing and debugging |\n\nAll functions are built into every binary. The dataflow-rs runtime contributes `parse_json`/`parse_xml`/`filter`/`map`/`validation`/`publish_json`/`publish_xml`/`log`; Orion adds the connector-backed handlers (`http_call`, `data_query`, `data_write`, `db_read`, `db_write`, `cache_read`, `cache_write`, `mongo_read`, `publish_kafka`) and the in-process `channel_call`. `data_query`/`data_write` speak the [portable data dialect](https://goplasmatic.github.io/Orion/reference/data-dialect.html) — write the query once, switch backends by switching connectors. `cache_read`/`cache_write` use the in-memory backend by default; reference a Redis connector for distributed caching. See the [Function Reference](https://goplasmatic.github.io/Orion/reference/functions.html) for every function's exact `input` schema, or browse them at runtime via `GET /api/v1/admin/functions`.\n\n---\n\n## When Things Go Wrong\n\nProduction services fail. Orion handles it so you don't write retry loops and fallback logic:\n\n| Failure | What Orion does | You configure |\n|---------|----------------|---------------|\n| **External API down** | Circuit breaker trips, fast-fails subsequent calls, auto-recovers | `failure_threshold`, `recovery_timeout_secs` per connector |\n| **Slow workflow** | Timeout fires, returns 504 to caller | `timeout_ms` per channel |\n| **Traffic spike** | Rate limiter rejects excess requests (429), backpressure sheds load (503) | `requests_per_second`, `max_concurrent` per channel |\n| **Async task fails** | Moved to Dead Letter Queue, retried automatically with backoff | `dlq_max_retries`, `dlq_poll_interval_secs` |\n| **Task in pipeline fails** | Pipeline halts with error, or continues collecting errors if `continue_on_error: true` | Per-workflow setting |\n| **Duplicate request** | Detected via idempotency key, returns 409 | `Idempotency-Key` header + retention window |\n\n**Debugging is built in.** Every request gets a `x-request-id` propagated through the entire pipeline. Structured JSON logs show what data each task received and produced. Enable OpenTelemetry for distributed tracing across `http_call` and `channel_call` chains. Inspect circuit breakers, DLQ traces, and debug endpoints via the [API Reference](https://goplasmatic.github.io/Orion/api/admin.html).\n\n---\n\n## Deploy Anywhere\n\n```mermaid\nflowchart LR\n    subgraph Standalone [\"Standalone\"]\n        direction TB\n        S[\"./orion-server\"]\n    end\n\n    subgraph Sidecar [\"Sidecar Pattern\"]\n        direction LR\n        App[\"App\"] \u003c--\u003e O[\"Orion\"]\n    end\n\n    subgraph Container [\"Docker / Kubernetes\"]\n        direction TB\n        D[\"docker run ghcr.io/goplasmatic/orion:latest\"]\n    end\n\n    style Standalone fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style Sidecar fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style Container fill:#21252b,stroke:#5c6370,color:#abb2bf\n    style S fill:#61afef,stroke:#61afef,color:#1e222b\n    style App fill:#4b5263,stroke:#5c6370,color:#abb2bf\n    style O fill:#61afef,stroke:#61afef,color:#1e222b\n    style D fill:#61afef,stroke:#61afef,color:#1e222b\n```\n\nSingle binary. SQLite by default, no database to provision, no runtime dependencies. Need more scale? Swap to **PostgreSQL** or **MySQL** by changing the `storage.url`. No rebuild needed.\n\n**Same channel definitions work in any topology:** run everything in one instance, split channels across instances with include/exclude filters, or deploy as sidecars. The definition doesn't change; only the deployment config does.\n\n## Performance\n\n**6K–7K workflow requests/sec** on a single instance (Apple M-series, release build, 50 concurrent connections, v0.2.0 release):\n\n\u003cpicture\u003e\n  \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"media/benchmark-dark.svg\"\u003e\n  \u003cimg src=\"media/benchmark-light.svg\" alt=\"Throughput by scenario — simple workflow: 7,446 req/s; 12 workflows on one channel: 6,912 req/s; complex workflow (4 tasks): 6,053 req/s\" width=\"100%\"\u003e\n\u003c/picture\u003e\n\n| Scenario | Req/sec | Avg Latency | P99 Latency |\n|----------|--------:|------------:|------------:|\n| Simple workflow (1 task) | 7,446 | 6.7 ms | 16.7 ms |\n| Complex workflow (4 tasks) | 6,053 | 8.2 ms | 25.5 ms |\n| 12 workflows on one channel | 6,912 | 7.2 ms | 16.6 ms |\n\nv0.2.0 upgrades dataflow-rs to 3.0 and datalogic-rs to 5, which moved JSONLogic compilation to engine-construction time. Compared to the v0.1.x baseline (dataflow-rs 2.1.5), complex and multi-workflow scenarios pick up large gains (+48% and +120% req/s respectively) and P99 latency drops materially on every scenario. Run `./tests/benchmark/bench.sh` to reproduce.\n\nPre-compiled JSONLogic, zero-downtime hot-reload, lock-free reads, SQLite WAL mode, async-first on Tokio.\n\n---\n\n## Use Cases\n\n- **Replace microservices:** define REST endpoints as channels, logic as workflows, external calls as connectors\n- **Webhook gateway:** normalize Stripe, GitHub, Shopify payloads into a consistent internal schema\n- **Event processing:** Kafka-to-workflow pipelines with transforms, enrichment, and routing\n- **API composition:** use `channel_call` to compose services from other services\n- **AI-managed business logic:** LLMs create and update workflows via the REST API\n- **Multi-agent orchestration:** route agent outputs to channels with coordinating workflows\n- **Protocol bridging:** REST-to-Kafka, Kafka-to-HTTP with transformation\n\nSee [Use Cases \u0026 Patterns](https://goplasmatic.github.io/Orion/tutorials/use-cases.html) for complete, tested examples, or grab ready-to-deploy JSON from [`examples/`](examples/) and run `./deploy.sh \u003cexample\u003e` against a local instance.\n\n## Install\n\n```bash\n# Docker (quickest way to try)\ndocker run -p 8080:8080 ghcr.io/goplasmatic/orion:latest\n\n# Docker Compose (with persistent storage)\ndocker compose up  # uses docker-compose.yml from this repo\n\n# macOS (Homebrew)\nbrew install GoPlasmatic/tap/orion-server\n\n# macOS / Linux (shell installer)\ncurl --proto '=https' --tlsv1.2 -LsSf https://github.com/GoPlasmatic/Orion/releases/latest/download/orion-server-installer.sh | sh\n\n# Windows (PowerShell)\npowershell -ExecutionPolicy ByPass -c \"irm https://github.com/GoPlasmatic/Orion/releases/latest/download/orion-server-installer.ps1 | iex\"\n\n# From crates.io\ncargo install orion-server\n\n# From source\ncargo install --git https://github.com/GoPlasmatic/Orion.git\n```\n\nVerify with `orion-server --version`. Swagger UI available at `http://localhost:8080/docs`. See [Configuration](https://goplasmatic.github.io/Orion/configuration/reference.html) for deployment options.\n\nThe server binary also ships diagnostic subcommands you can run without booting the HTTP listener:\n\n```bash\norion-server validate-config -c config.toml         # Parse + validate the config file\norion-server migrate                                # Run pending DB migrations\norion-server migrate --dry-run                      # Preview pending migrations\norion-server lint path/to/workflow.json             # Strict-validate a workflow JSON file\norion-server dry-run -w workflow.json -i input.json # Execute a workflow against a sample payload\norion-server test-connectivity                      # Probe DB (and Kafka if enabled)\norion-server dump-openapi \u003e docs/openapi.json       # Write the OpenAPI 3.1 spec (checked in for offline use / client gen)\n```\n\n`${VAR}` / `${VAR:-default}` placeholders inside `config.toml` are substituted from the environment when any of these subcommands load the config, so the same file works across dev, staging, and prod without templating.\n\n### CLI Tool\n\nManage workflows, channels, and connectors without writing curl commands:\n\n```bash\n# Install\nbrew install GoPlasmatic/tap/orion-cli                # Homebrew\ncurl --proto '=https' --tlsv1.2 -LsSf https://github.com/GoPlasmatic/Orion-cli/releases/latest/download/orion-cli-installer.sh | sh  # Shell installer\ncargo install --git https://github.com/GoPlasmatic/Orion-cli.git  # From source\n\n# Deploy a workflow from a JSON file\norion-cli workflows create -f order-processing.json\norion-cli --yes workflows activate high-value-order\norion-cli channels create -f orders-channel.json\norion-cli --yes channels activate orders\n```\n\nSee [CLI Reference](https://github.com/GoPlasmatic/Orion-cli) for the full command list.\n\n## Documentation\n\n| Guide | Description |\n|-------|-------------|\n| [Workflow Reference](https://goplasmatic.github.io/Orion/reference/workflows.html) | Workflow \u0026 task JSON schema, conditions, error handling, lifecycle, and rollout |\n| [Function Reference](https://goplasmatic.github.io/Orion/reference/functions.html) | Every built-in task function and its exact `input` schema |\n| [Portable Data Dialect](https://goplasmatic.github.io/Orion/reference/data-dialect.html) | Backend-neutral query/write envelope for `data_query`/`data_write` — one filter dialect across SQL, MongoDB, Elasticsearch |\n| [Admin API](https://goplasmatic.github.io/Orion/api/admin.html) | Workflows, channels, connectors, engine, audit, and backup endpoints |\n| [Data API](https://goplasmatic.github.io/Orion/api/data.html) | Data routing, sync/async processing, traces, and operational endpoints |\n| [Configuration](https://goplasmatic.github.io/Orion/configuration/reference.html) | Config file, env vars, database backends, deployment |\n| [Connectors \u0026 Extensibility](https://goplasmatic.github.io/Orion/features/extensibility.html) | HTTP, DB, Cache, Storage, MongoDB, Elasticsearch, Kafka: auth, retry, circuit breakers |\n| [Observability](https://goplasmatic.github.io/Orion/features/observability.html) | Prometheus metrics, health checks, Kubernetes probes, tracing, logging |\n| [Resilience](https://goplasmatic.github.io/Orion/features/resilience.html) | Circuit breakers, timeouts, dead letter queues |\n| [Scalability](https://goplasmatic.github.io/Orion/features/scalability.html) | Rate limiting, backpressure, horizontal scaling |\n| [Security](https://goplasmatic.github.io/Orion/features/security.html) | Input validation, SSRF protection, CORS, auth |\n| [Deployability](https://goplasmatic.github.io/Orion/features/deployability.html) | Packaging, Docker, installers, distribution |\n| [Use Cases \u0026 Patterns](https://goplasmatic.github.io/Orion/tutorials/use-cases.html) | AI prompt templates, tested examples, validation workflows, CI/CD |\n| [CLI Tool](https://github.com/GoPlasmatic/Orion-cli) | Command-line tool for managing channels, workflows, and connectors |\n\n## Built With\n\n[Axum](https://github.com/tokio-rs/axum) (HTTP), [Tokio](https://tokio.rs) (async runtime), [SQLx](https://github.com/launchbadge/sqlx) (database), [sea-query](https://github.com/SeaQL/sea-query) (portable SQL builder), SQLite/PostgreSQL/MySQL (storage), [datalogic-rs](https://github.com/GoPlasmatic/datalogic-rs) (JSONLogic), [dataflow-rs](https://github.com/GoPlasmatic/dataflow-rs) (workflow orchestration).\n\n## Ecosystem \u0026 Roadmap\n\nOrion ships with two companion projects:\n\n- **[Orion UI](https://github.com/GoPlasmatic/Orion-ui):** the admin dashboard — manage workflows, channels, and connectors, visualize workflow pipelines, inspect audit trails, and monitor engine health from the browser\n- **[Orion CLI](https://github.com/GoPlasmatic/Orion-cli):** the command-line interface and MCP server — manage everything from your terminal or AI assistant\n\nUnder consideration: workflow marketplace (community templates), cron-based scheduling, WASM task functions, and language SDKs. Have an idea or want to push one of these forward? [Open an issue](https://github.com/GoPlasmatic/Orion/issues) or start a [discussion](https://github.com/GoPlasmatic/Orion/discussions).\n\n## Who's Using Orion?\n\nUsing Orion in a project, a company, or a side quest? Add yourself to [ADOPTERS.md](ADOPTERS.md) with a one-line PR, or share what you built in [Discussions](https://github.com/GoPlasmatic/Orion/discussions) — real-world usage reports directly shape the roadmap.\n\n## Contributing\n\nContributions welcome! Whether it's a bug fix, new connector, documentation improvement, or feature request, we'd love to hear from you.\n\n```bash\ncargo build                              # Build (all features included)\ncargo build --release                    # Release build\ncargo test                               # Run tests\ncargo clippy                             # Lint\ncargo fmt                                # Format\n```\n\n- **Report bugs:** [Open an issue](https://github.com/GoPlasmatic/Orion/issues)\n- **Ask questions:** [GitHub Discussions](https://github.com/GoPlasmatic/Orion/discussions)\n- **Report security issues privately:** see [SECURITY.md](SECURITY.md)\n- **Submit code:** Fork, branch, PR. All tests must pass (`cargo test \u0026\u0026 cargo clippy`)\n- **Docs recordings:** the README GIFs and mdBook asciinema casts are generated from real sessions — see [`docs/recordings/`](docs/recordings/) to regenerate them.\n\n## Support the Project\n\nIf Orion looks useful, a ⭐ on this repo is the easiest way to help other developers find it. Beyond that: share what you build in [Discussions](https://github.com/GoPlasmatic/Orion/discussions), add yourself to [ADOPTERS.md](ADOPTERS.md), or send this to a colleague who's tired of writing boilerplate services.\n\n## License\n\nApache-2.0. See [LICENSE](LICENSE) for details.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FGoPlasmatic%2FOrion","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FGoPlasmatic%2FOrion","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FGoPlasmatic%2FOrion/lists"}