Architecture
Architecture
Section titled “Architecture”Brane uses a federated architecture where a central orchestrator coordinates work across distributed worker nodes. Each node runs independently and enforces its own policies.
High-Level Overview
Section titled “High-Level Overview”Central Node Services
Section titled “Central Node Services”| Service | Purpose |
|---|---|
| brane-api | REST API for package management and workflow submission |
| brane-drv | Workflow driver — compiles and executes BraneScript |
| brane-plr | Planner — decides where to run each task |
| brane-prx | Proxy for cross-domain communication |
| ScyllaDB | Stores package metadata, workflow state, execution history |
Worker Node Services
Section titled “Worker Node Services”| Service | Purpose |
|---|---|
| brane-job | Executes package containers locally |
| brane-reg | Local package registry and cache |
| brane-chk | Policy checker — enforces eFLINT policies |
| brane-prx | Handles communication with central and other workers |
Task Execution Flow
Section titled “Task Execution Flow”Policy Enforcement
Section titled “Policy Enforcement”Policy checks happen at multiple levels:
- Pre-execution: The planner checks if a task is likely to be allowed
- At the worker:
brane-chkperforms the definitive policy check using eFLINT - Data transfer: Both source and destination policies are checked when data moves
Network and Proxy Setup
Section titled “Network and Proxy Setup”For environments behind firewalls, optional proxy nodes relay traffic between domains:
All cross-node communication uses gRPC with mutual TLS (mTLS) authentication.
Deployment Models
Section titled “Deployment Models”| Model | Description | Best For |
|---|---|---|
| Single-machine | All nodes on one machine via Docker Compose | Development, testing |
| Multi-machine | Each node on a separate machine | Production |
| Hybrid | Central + some workers co-located, others remote | Mixed environments |