Introduction

Orchestration you can reason about.

Most companies run on a tangle of separate systems — a database here, an SFTP server there, a CRM somewhere else, a web shop on top, a mail server, message queues, increasingly an AI model in the mix. Getting those systems to talk to each other on a schedule, without somebody watching, is what an automation platform is for.

Zenvara is one. You describe the work in a small YAML file — “every morning at six, pull yesterday’s orders from the warehouse database, transform them into a CSV, drop it on the partner SFTP, and email accounting if anything failed” — and Zenvara compiles that file, runs it on schedule, logs every step, and rolls it back if something breaks partway through.

The kinds of work it covers come down to three:

• Moving data between systems. Read from one place, shape it, write to another. ETL by another name.
• Calling services. HTTP APIs, SOAP endpoints, SFTP servers, mail, message queues, SQL and NoSQL databases.
• Running AI as part of a pipeline. Send a prompt to Claude, ChatGPT, or Gemini, treat the answer as data, feed it into the next step.

What Zenvara is

Zenvara is an automation platform. You write pipelines in YAML; Zenvara compiles them, runs them, and tells you what happened. Every step — a database query, an HTTP call, a SOAP request, an LLM completion, a file transfer — is the same kind of object. The same authentication. The same error handling. The same audit trail.

It ships as a single binary. No JVM. No Python runtime. No cluster required. You can run it on a laptop for a demo or on a hardened on-premise host for production; the binary is the same.

The platform serves three jobs that organisations usually buy three platforms for:

• Data integration — ETL, joins, change detection.
• Service integration — HTTP, SOAP/WSDL, GraphQL, SFTP, S3, Kafka, SQL and NoSQL databases.
• AI workflows — Claude, ChatGPT, and Gemini as native pipeline steps.

One binary, one configuration, one operating model.

What problems it solves

If your team runs cron + bash + Python scripts, you know the failure mode: a script breaks at 3 a.m., you find out at 9, the fix is in someone’s shell history. Zenvara replaces the glue with typed pipelines. References between steps are checked at compile time. Every run lands in a queryable log. Every write operator carries a compensating action, so failed runs roll themselves back instead of leaving half-finished state.

If you’re integrating heterogeneous services — an ERP to a webshop, a CRM to a data warehouse, an SFTP to an SQL database — Zenvara solves the same problem as MuleSoft, SnapLogic, or Informatica at a different price point and with a different deployment story: one binary on your hardware, no per-connector licence, no JVM. It ships a focused operator catalog plus a generic HTTP operator that auto-discovers OpenAPI specs and a SOAP operator that consumes WSDL. For organisations that need ten to thirty integrations rather than five hundred, that trade is usually the right one.

If you’re adding AI to existing workflows, you have discovered that LangChain orchestrates AI agents, n8n adds AI as a node, Airflow lets you call OpenAI from a Python operator — and none of them treat an LLM call the same way they treat a database query. Zenvara does. A Claude completion is a step. It has typed inputs and typed outputs, validated before invocation. It logs the prompt and the response. It composes with retries, rollback, secrets, and audit the same way a SQL query does.

The unifying point: one platform for three jobs companies usually buy three platforms for.

A complete flow, end to end

The example from the opening, written out — pull yesterday’s orders from Postgres, ask Claude to summarise them, email the result to accounting:

status: active
environment: prod

input:
  date: !str

steps:
  - $orders:
      invoke: postgresql.query
      on: warehouse
      with:
        Query: "SELECT id, customer, total FROM orders WHERE order_date = '${date}'"

  - $summary:
      invoke: claude.call
      with:
        Prompt: "Summarise these orders in two paragraphs:\n${orders.rows}"

  - $email:
      invoke: email.send
      on: smtp
      with:
        From: noreply@example.com
        To: [accounting@example.com]
        Subject: "Daily order summary for ${date}"
        Body: "${summary.content}"

Three operators, three steps. Each step is the same kind of object: a typed verb with declared inputs and outputs. References between them — ${orders.rows}, ${summary.content} — are checked at compile time, before the flow ever runs. The same file runs against dev, staging, or production by changing the environment at invocation; nothing in the flow itself names a host or a credential.

No Python interpreter to maintain. No separate scheduler. No glue code between the database client, the AI SDK, and the SMTP library. One YAML file, one binary, one log stream that captures every step, every prompt, every response, every error.

This is the shape every flow takes — twelve operators or two, the structure is identical.

Reading paths

Pick the one that matches your role:

• The decision maker — a CTO, VP of Engineering, or architect evaluating Zenvara. Read this page, Vocabulary, and the Security Review checklist. You’ll know what the platform does and what your security review will ask before you commit to a deeper evaluation.
• The flow author — the engineer or analyst writing pipelines. Read Vocabulary, Getting Started, the Authoring Flows section, and Connections & Environments. You’ll know how to write a flow, where its inputs come from, and how it talks to your services.
• The operator / sysadmin — read Configuration and Deployment.

Conventions used in these docs

• YAML samples are runnable as-is unless explicitly truncated; truncations are marked with # ….
• File paths shown without a leading / (e.g. flows/{name}/definition.yaml) are relative to the configured Storage.Directory.
• REST examples assume a Git-disabled installation and use the live branch alias on the URL path. Git-enabled installations replace live with their own branch name.
• Secrets in samples always appear as ${secret:path}. Plain credentials never appear in source — that is a rule of the platform, not just a convention of the docs.