Architecture Overview
System Diagram
Info
The diagram below shows a standard Exekra deployment. The Hub orchestrates work, PostgreSQL and Redis provide persistence and queueing, and Runners execute workflows on machines inside your network.
PostgreSQL
Database
Exekra Hub
Windows Service
Frontend
HTTPS
Backend
Internal
API proxy /api/
Redis
Queue
Runner
#1
Runner
#2
Runner
#3
Runner
#4
Key Architecture Principles
Key Principles
- Customer-controlled infrastructure
- Data remains on customer systems
- Centralized orchestration
- Distributed execution
- Horizontal Runner scaling
- Offline-capable operation
Component Responsibilities
Hub
Central management server. Provides the web interface (dashboard, workflow management, runner monitoring), REST API, workflow storage, execution scheduling via cron and webhooks, runner management (registration, authentication, health monitoring, work assignment), license enforcement, and audit logging.
Runner
Electron-based desktop agent that executes workflows on Windows machines. Authenticates with the Hub, receives assigned work, executes the workflow graph, and reports execution results including logs and performance metrics.
Database (PostgreSQL)
Stores all persistent state: users, workflows, versions, executions, runners, triggers, license data (encrypted), and audit logs.
Redis
Provides the execution queue via BullMQ. Decouples execution creation from runner assignment with concurrent workers, exponential backoff retry, and automatic fallback to direct assignment if Redis is unavailable.
Execution Modes
| Aspect | Interactive | Scheduled |
|---|---|---|
| Trigger | User clicks "Run" in Studio | Schedule, webhook, or API call |
| User presence | User is at the machine | No user needed |
| Queue | Executes immediately on connected runner | Priority queue with duplicate detection |
| Use case | Testing, ad-hoc tasks | Scheduled batch jobs, event-driven automation |
Execution Flow
Execution request
A user, schedule, or webhook creates an execution request.
License validation
The Hub validates the license and retrieves the published workflow version.
Queue assignment
The execution is placed in the BullMQ queue with status QUEUED.
Runner selection
A queue worker finds an available Runner and assigns the execution.
Workflow execution
The Runner picks up the assignment and executes the workflow graph node-by-node, buffering logs.
Result reporting
On completion, the Runner sends the final status, logs, and metrics back to the Hub.
Was this page helpful?
A quick signal helps us prioritise improvements.