Architecture

Orvanta is designed to help teams move from idea to reliable automation without exposing internal implementation complexity. At a high level it can be understood as three connected layers.

The three layers

1. Design layer

   • Where teams model workflows visually and define automation intent.
   • Focus: speed of composition and shared understanding.

2. Control layer

   • Where governance, access control, and release policies are applied.
   • Focus: safe promotion from development to production.

3. Execution layer

   • Where workflows run across the polyglot runtime.
   • Focus: reliability, scalability, and operational visibility.

Runtime components

A running Orvanta instance is composed of a small number of cooperating services:

Component	Responsibility
API server	Serves the REST API, receives webhooks, and coordinates runs.
Worker pool	Executes workflow nodes in the polyglot runtime; scales horizontally.
Editor	The web-based node editor, served as a static single-page app.
Database	PostgreSQL — stores workflows, scripts, audit logs, and the job queue that workers poll.
Object storage	S3-compatible storage (optional) for large job results and artefacts.

How a run flows through the system

1. A trigger (manual, schedule, webhook, or API call) reaches the API server.
2. The API server creates a run and enqueues its jobs in PostgreSQL.
3. Workers poll the queue, execute jobs in the appropriate runtime, and write results back to the shared run context.
4. The API server tracks status transitions, streams logs, and persists the full audit trail.

Why this model works

• Teams can collaborate visually without losing engineering rigour.
• Platform owners can enforce standards without blocking delivery.
• Workflows remain portable, versioned, and production-ready.

Related

• Workflows as code — The artifact the execution layer runs.
• Jobs and runs — What a run is and how to inspect it.
• Self-hosting Overview — Deploy these components yourself.