Understanding these core concepts and architecture patterns will help you leverage dxflow's full potential for distributed computing and workflow orchestration.
dxflow is designed as a powerful and flexible workflow engine built with a modular architecture that enables seamless orchestration of data and compute workflows across heterogeneous computing environments.
dxflow follows a layered, modular architecture designed for flexibility and scalability:
Infrastructure Layer
Physical or virtual machines, cloud instances, edge devices
Engine Layer
The dxflow daemon providing core services and APIs
Runtime Layer
Docker, Kubernetes, Slurm, or other orchestration platforms
Application Layer
Your actual workloads, models, and data processing pipelines
This layered approach allows dxflow to integrate seamlessly with existing infrastructure while providing a consistent interface across diverse environments.
Workflow Management
Create and manage complex Docker Compose workflows with real-time monitoring
Shell Operations
Interactive shell management with platform-specific implementations
Object Storage
File system operations including upload, download, zip/unzip capabilities
Network Bridge
Bridge system for container connectivity with WebSocket tunneling
| Feature | Description | Use Case |
|---|---|---|
| Proxy Management | Enhanced TCP proxy with subdomain allocation and TLS support | Multi-tenant platforms |
| JWT Authentication | Token-based authentication with RSA key management | Secure API access |
| Self-Update | Built-in update capability from GitHub releases | Zero-downtime updates |
| Embedded Assets | Web UI and docs embedded using afero filesystem | Single binary deployment |
| Flexible Licensing | Build-time configuration support for different license types | Enterprise deployments |
dxflow supports two primary deployment patterns, each optimized for different use cases and organizational needs:
Node-Embedded
Direct Integration
Every compute node runs its own dxflow engine with no additional control layer between infrastructure and schedulers.
Best For:
Federated Master
Centralized Orchestration
A master dxflow instance coordinates a fleet of engine agents across multiple nodes and environments.
Best For:
The Node-Embedded pattern places a dxflow engine directly on every compute target—whether it's an EC2 spot instance, an on-premises Slurm node, or a Docker container on a lab workstation.
Ultra-Fast Bootstrap
Uniform Endpoints
Because the runtime is embedded at the node level, dxflow cohabits peacefully with any resource scheduler already present:
This design mirrors the side-car model popularised by Dapr: place a lightweight process next to every workload to provide cross-cutting capabilities.
In the federated master deployment, a single dxflow instance acts as a control plane for the entire fleet of compute nodes. This master instance orchestrates the dxflow agents running on each node or container, providing a centralized interface for managing and monitoring computational tasks.
The dxflow engine is the heart of each compute node, providing:
dxflow boot up/down for engine managementRegardless of deployment pattern, every dxflow engine provides a consistent set of interfaces:
Each engine immediately exposes multiple access methods:
http://localhost:<port>/api — REST
dxflow <cmd> — local CLI passthrough
http://localhost:<port>/console — web console
Workflows are containerized applications managed through industry-standard Docker Compose:
Secure, interactive terminal access for debugging and administration:
Session Features:
Common Use Cases:
# System debugging
dxflow shell create debug-session
dxflow shell connect debug-session
# Interactive development
dxflow shell create dev-environment
# Install dependencies, test code, debug issues
Integrated file management with enterprise-grade features:
File Operations
Archive Management
Sharing & Collaboration
Advanced network proxy capabilities for secure service exposure:
Connect and orchestrate multiple dxflow instances for distributed computing:
Bridge Capabilities:
dxflow implements a comprehensive security model:
dxflow implements a flexible permission model where permissions can be combined to create custom access levels:
Base Permissions
Functional Permissions (can be combined):
Modifier Permissions
READ_ONLY: Restricts write operations
MASTER: Administrative override
Permissions: SHELL + OBJECT + WORKFLOW
Can:
- Create and connect to shell sessions
- Upload/download files and manage directories
- Create, start, stop workflows
- Execute commands in containers
Cannot:
- Manage proxy services or bridges
- Access Docker platform operations
- Perform administrative tasks
Permissions: WORKFLOW + SHELL + READ_ONLY
Can:
- View workflow status and logs
- List shell sessions
- Monitor system health
- Access read-only endpoints
Cannot:
- Create or modify workflows
- Create shell sessions or execute commands
- Upload/download files
Permissions: OBJECT + BRIDGE
Can:
- Full file system access
- Connect to remote engines
- Transfer files between engines
- Generate sharing links
Cannot:
- Create workflows or containers
- Access shell sessions
- Manage proxy services
Permissions: MASTER
Can:
- All system operations
- User and key management
- Engine configuration
- Complete administrative control
Note: MASTER includes all other permissions
PROXY + BRIDGE + SHELL + OBJECT + PLATFORM + WORKFLOW permissions, providing comprehensive functionality without administrative privileges or read-only restrictions.This comprehensive understanding of dxflow concepts and architecture will enable you to design and implement robust, scalable distributed computing solutions.