Orion

The declarative services runtime for the AI era.

Instead of writing, deploying, and operating a separate microservice for every piece of business logic, you declare what the service should do — as a JSON workflow — and Orion runs it. Architectural governance — observability, rate limiting, circuit breakers, versioning, input validation, and more — is built into every service, not bolted on. Hand-write the workflows or let an AI generate them; either way they run under the same guarantees.

Jump to: Quickstart · Is Orion right for you? · Three primitives · What's built in · Connectors · Functions · Performance · Install · Docs

Your First Service in 2 Minutes

No code. No Dockerfile. No CI pipeline. Just a running service.

1. Start Orion

brew install GoPlasmatic/tap/orion-server   # or: curl installer, cargo install (see Install)
orion-server

2. Tell AI what you need

Give your LLM this prompt, or write the JSON yourself:

"Flag orders over $10,000 for manual review with an alert message"

3. Deploy the workflow AI generated

# Create the workflow (paste the AI-generated JSON here)
curl -s -X POST http://localhost:8080/api/v1/admin/workflows \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "high-value-order",
    "name": "High-Value Order",
    "condition": true,
    "tasks": [
      { "id": "parse", "name": "Parse payload", "function": {
          "name": "parse_json",
          "input": { "source": "payload", "target": "order" }
      }},
      { "id": "flag", "name": "Flag order",
        "condition": { ">": [{ "var": "data.order.total" }, 10000] },
        "function": {
          "name": "map",
          "input": { "mappings": [
            { "path": "data.order.flagged", "logic": true },
            { "path": "data.order.alert", "logic": { "cat": ["High-value order: $", { "var": "data.order.total" }] } }
          ]}
      }}
    ]
  }'

# Activate it
curl -s -X PATCH http://localhost:8080/api/v1/admin/workflows/high-value-order/status \
  -H "Content-Type: application/json" -d '{"status": "active"}'

4. Create a channel (the service endpoint)

curl -s -X POST http://localhost:8080/api/v1/admin/channels \
  -H "Content-Type: application/json" \
  -d '{ "channel_id": "orders", "name": "orders", "channel_type": "sync",
        "protocol": "rest", "route_pattern": "/orders",
        "methods": ["POST"], "workflow_id": "high-value-order" }'

# Activate
curl -s -X PATCH http://localhost:8080/api/v1/admin/channels/orders/status \
  -H "Content-Type: application/json" -d '{"status": "active"}'

5. Send a request — your service is live

curl -s -X POST http://localhost:8080/api/v1/data/orders \
  -H "Content-Type: application/json" \
  -d '{ "data": { "order_id": "ORD-9182", "total": 25000 } }'

{
  "status": "ok",
  "data": {
    "order": {
      "order_id": "ORD-9182",
      "total": 25000,
      "flagged": true,
      "alert": "High-value order: $25000"
    }
  }
}

That's it. You described what you needed. AI wrote the logic. Orion ran it, with rate limiting, metrics, health checks, and request tracing already active. Change the threshold? One API call. No rebuild, no redeploy, no restart.

Is Orion Right for You?

Three Primitives

You build services in Orion with three things:

┌─────────────┐       ┌──────────────┐       ┌─────────────┐
│   Channel   │──────▶│  Workflow    │──────▶│  Connector  │
│  (endpoint) │       │  (logic)     │       │  (external) │
└─────────────┘       └──────────────┘       └─────────────┘

Design-time: define channels, build workflows, configure connectors, test with dry-run, manage versions, all through the admin API.

Runtime: Orion routes traffic to channels, executes workflows, calls connectors, and handles observability automatically.

AI Writes Services, Not Code

When 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.

Use the Orion CLI's MCP server to give your AI assistant full Orion context. No manual prompt engineering needed. The MCP server provides your LLM with workflow syntax, available functions, connector types, and API operations automatically.

You: "Classify orders into VIP (>=500, 15% discount), Premium (100-500, 5%), and Standard tiers"

AI:  → generates valid workflow JSON
     → creates it via the API
     → tests with dry-run
     → activates when you approve

Safe path from AI output to production — every time:

1. Generate    → AI produces the workflow JSON (with full context from MCP)
2. Validate    → POST /api/v1/admin/workflows/validate         ← catches structural errors
3. Create      → POST /api/v1/admin/workflows                  ← saved as draft (not live)
4. Dry-run     → POST /api/v1/admin/workflows/{id}/test        ← test with sample data
5. Activate    → PATCH /api/v1/admin/workflows/{id}/status     ← goes live
6. Rollout     → PATCH /api/v1/admin/workflows/{id}/rollout    ← gradual traffic (10% → 50% → 100%)

Every 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.

Need 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.

See Use Cases & Patterns for CI/CD integration and GitHub Actions examples.

Before & After

Before — every piece of business logic is its own service to build, deploy, and operate:

                         ┌──────────────┐
                    ┌───▶│ Pricing Svc  │───▶ DB
                    │    └──────────────┘
┌──────────┐        │    ┌──────────────┐
│  API     │────────┼───▶│ Fraud Svc    │───▶ Redis
│  Gateway │        │    └──────────────┘
└──────────┘        │    ┌──────────────┐
                    ├───▶│ Routing Svc  │───▶ Kafka
                    │    └──────────────┘
                    │    ┌──────────────┐
                    └───▶│ Notif. Svc   │───▶ SMTP
                         └──────────────┘

4 services × (code + Dockerfile + CI + health checks + metrics + deployment)

After — one Orion instance replaces all four:

                         ┌──────────────────────────────────┐
                         │           Orion                  │
                         │                                  │
┌──────────┐             │  Channel /pricing  → workflow ───┼──▶ DB
│ Clients  │────────────▶│  Channel /fraud    → workflow ───┼──▶ Redis
└──────────┘             │  Channel /routing  → workflow ───┼──▶ Kafka
                         │  Channel /notify   → workflow ───┼──▶ SMTP
                         │                                  │
                         │  Rate limiting, metrics, health  │
                         │  checks, circuit breakers, logs  │
                         └──────────────────────────────────┘

No API gateway needed. Governance is built in. One binary to deploy.

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.

What's Built In

Every channel gets production-grade features without writing a line of code. Configure per channel or use platform defaults:

A minimal channel needs only a name and a workflow. Everything else has sensible defaults.

Observability deep dive: health endpoints, full Prometheus metrics list, Kubernetes probes, and OpenTelemetry tracing config. See Observability Guide.

Sync and Async

Sync     POST /api/v1/data/{channel}         → immediate response
Async    POST /api/v1/data/{channel}/async   → returns trace_id, poll later

REST     GET /api/v1/data/orders/{id}        → matched by route pattern
Kafka    topic: order.placed                 → consumed automatically

Sync 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.

Bridging is a pattern, not a feature. A sync workflow can publish_kafka and return 202. An async channel picks it up from there.

REST channels support parameterized route patterns (/orders/{order_id}) with path, query, and header injection into the workflow context. See Data API.

Service Composition

Most 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:

POST /orders (order-processing workflow)
  ├── parse_json         → extract order data
  ├── channel_call       → "inventory-check" channel (in-process)
  ├── channel_call       → "customer-lookup" channel (in-process)
  ├── map                → compute pricing with enriched data
  └── publish_json       → return combined result

Each composed channel has its own workflow, versioning, and governance, but calls between them are function calls, not network hops. Cycle detection prevents infinite recursion.

Connect to Anything

Connectors are named, reusable connections to external systems. Configure once, reference by name in any workflow. Credentials stay out of your logic:

Every connector gets circuit breaker protection automatically: failures trip the breaker, subsequent calls fast-fail, and the breaker auto-recovers. 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 for configuration examples and auth options.

Built-in Task Functions

All 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, db_read, db_write, cache_read, cache_write, mongo_read, publish_kafka) and the in-process channel_call. cache_read/cache_write use the in-memory backend by default; reference a Redis connector for distributed caching. See the Function Reference for every function's exact input schema, or browse them at runtime via GET /api/v1/admin/functions.

When Things Go Wrong

Production services fail. Orion handles it so you don't write retry loops and fallback logic:

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.

Deploy Anywhere

┌────────────────┐   ┌────────────────────┐   ┌────────────────┐
│   Standalone   │   │      Sidecar       │   │     Docker     │
│                │   │                    │   │                │
│ ./orion-server │   │  ┌─────┐ ┌──────┐  │   │  docker run \  │
│                │   │  │ App │─│Orion │  │   │   orion:latest │
│   That's it.   │   │  └─────┘ └──────┘  │   │                │
└────────────────┘   └────────────────────┘   └────────────────┘

Single 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.

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.

Performance

6K–7K workflow requests/sec on a single instance (Apple M-series, release build, 50 concurrent connections, v0.2.0 release):

v0.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. The benchmark folders under tests/benchmark/results/ mix two version schemes: v2.1.5 and v3.0.0 are dataflow-rs engine versions (the v0.1.x baseline and the 3.0 upgrade snapshot), while v0.2.0 is Orion's own release version — the v0.2.0 and v3.0.0 datasets are the same run. Run ./tests/benchmark/bench.sh to reproduce.

Pre-compiled JSONLogic, zero-downtime hot-reload, lock-free reads, SQLite WAL mode, async-first on Tokio.

Use Cases

• Replace microservices: define REST endpoints as channels, logic as workflows, external calls as connectors
• Webhook gateway: normalize Stripe, GitHub, Shopify payloads into a consistent internal schema
• Event processing: Kafka-to-workflow pipelines with transforms, enrichment, and routing
• API composition: use channel_call to compose services from other services
• AI-managed business logic: LLMs create and update workflows via the REST API
• Multi-agent orchestration: route agent outputs to channels with coordinating workflows
• Protocol bridging: REST-to-Kafka, Kafka-to-HTTP with transformation

See Use Cases & Patterns for complete, tested examples, or grab ready-to-deploy JSON from examples/ and run ./deploy.sh <example> against a local instance.

Install

# Docker (quickest way to try)
docker run -p 8080:8080 ghcr.io/goplasmatic/orion:latest

# Docker Compose (with persistent storage)
docker compose up  # uses docker-compose.yml from this repo

# macOS (Homebrew)
brew install GoPlasmatic/tap/orion-server

# macOS / Linux (shell installer)
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/GoPlasmatic/Orion/releases/latest/download/orion-server-installer.sh | sh

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://github.com/GoPlasmatic/Orion/releases/latest/download/orion-server-installer.ps1 | iex"

# From crates.io
cargo install orion-server

# From source
cargo install --git https://github.com/GoPlasmatic/Orion.git

Verify with orion-server --version. Swagger UI available at http://localhost:8080/docs. See Configuration for deployment options.

The server binary also ships diagnostic subcommands you can run without booting the HTTP listener:

orion-server validate-config -c config.toml         # Parse + validate the config file
orion-server migrate                                # Run pending DB migrations
orion-server migrate --dry-run                      # Preview pending migrations
orion-server lint path/to/workflow.json             # Strict-validate a workflow JSON file
orion-server dry-run -w workflow.json -i input.json # Execute a workflow against a sample payload
orion-server test-connectivity                      # Probe DB (and Kafka if enabled)
orion-server dump-openapi > docs/openapi.json       # Write the OpenAPI 3.1 spec (checked in for offline use / client gen)

${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.

CLI Tool

Manage workflows, channels, and connectors without writing curl commands:

# Install
brew install GoPlasmatic/tap/orion-cli                # Homebrew
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/GoPlasmatic/Orion-cli/releases/latest/download/orion-cli-installer.sh | sh  # Shell installer
cargo install --git https://github.com/GoPlasmatic/Orion-cli.git  # From source

# Deploy a workflow from a JSON file
orion-cli workflows create -f order-processing.json
orion-cli --yes workflows activate high-value-order
orion-cli channels create -f orders-channel.json
orion-cli --yes channels activate orders

See CLI Reference for the full command list.

Documentation

Built With

Axum (HTTP), Tokio (async runtime), SQLx (database), sea-query (portable SQL builder), SQLite/PostgreSQL/MySQL (storage), datalogic-rs (JSONLogic), dataflow-rs (workflow orchestration).

Roadmap

• Web UI: visual workflow builder and channel dashboard
• SDK clients: Python, Go, and Node.js libraries for the admin API
• Workflow marketplace: community-contributed workflow templates
• Scheduler: cron-based workflow execution
• WASM task functions: extend the engine with custom logic in any language

Have an idea? Open an issue.

Contributing

Contributions welcome! Whether it's a bug fix, new connector, documentation improvement, or feature request, we'd love to hear from you.

cargo build                              # Build (all features included)
cargo build --release                    # Release build
cargo test                               # Run tests
cargo clippy                             # Lint
cargo fmt                                # Format

• Report bugs: Open an issue
• Ask questions: Open an issue
• Submit code: Fork, branch, PR. All tests must pass (cargo test && cargo clippy)

License

Apache-2.0. See LICENSE for details.