Advanced Topics

Boot

Learn how to boot and configure the dxflow engine with various deployment modes and network options

The dxflow engine provides flexible boot modes and configuration options for different deployment scenarios, from development to production environments.

Quick Start: Use dxflow boot up to start with default settings - HTTP enabled, foreground mode, perfect for development!

Boot Modes

dxflow supports three distinct boot modes:

Foreground Mode

Default mode - Engine runs in current terminal session

Interactive output and logs
Easy debugging and monitoring
Stops when terminal closes

Background Mode

Daemon service - Engine runs as system service

Persistent across reboots
System service integration
Use --daemon or -d flag

Instant Mode

Automatic - Internal boot for CLI commands

System managed (not user controllable)
Auto-starts for CLI operations
Shuts down after completion

Global Configuration

These flags must be placed before the boot command:

dxflow [GLOBAL_FLAGS] boot up [BOOT_FLAGS]

Flag	Short	Default	Description
`--config-profile`	`-C`	`default`	Configuration profile to use
`--log-level`	`-L`	`disabled`	Logging verbosity (disabled, debug, info, warn, error)
`--no-color`	`-N`	`false`	Disable colored terminal output

Boot Command Options

Flag	Default	Description
`--http`	`true`	Serve over HTTP
`--https`	`false`	Serve over HTTPS
`--no-http`	`false`	Disable all network protocols

Important: --no-http overrides all other network flags and enables Unix socket only mode.

Flag	Default	Description
`--proxy`	`false`	Enable subdomain allocation service
`--bridge`	`false`	Connect to hub dxflow instance

Mutual Exclusion: --proxy and --bridge cannot be used together on the same machine.

Flag	Short	Default	Description
`--daemon`	`-d`	`false`	Run as background service

Supported Platforms: Linux (SystemD/OpenRC), macOS (LaunchDaemon)

Network Architecture

Proxy Mode (Hub)

Makes your instance a hub that provides subdomains to other services:

Proxy Mode Features

Role: Acts as central hub/server
Provides: Random subdomains to connecting services
Requirements: Public IP address and DNS control
Performance: Direct routing, low latency
Scalability: Handles many direct connections

Subdomain Format: ab1234567890.dxflow.io (2 letters + 10 alphanumeric characters)

Use Cases:

Multi-tenant SaaS platforms
Development environments
CI/CD deployments
Microservice routing

Bridge Mode (Node)

Connects your instance to a hub to obtain a subdomain:

Bridge Mode Features

Role: Acts as node/client
Receives: Subdomain from hub
Requirements: Only internet access needed
Benefits: Works behind NAT/firewall, hub manages SSL
Limitations: WebSocket tunneling adds latency

Perfect For: Development, testing, and low-traffic scenarios where you need external access without port forwarding.

Avoid For: High-traffic production environments due to tunnel bandwidth limitations.

Bridge Management

When engine is running with --bridge, you can manage connections dynamically:

# Check bridge status and get identity
dxflow bridge list

# Disconnect from hub (stops tunnel, keeps engine running)
dxflow bridge disconnect <identity>

# Reconnect to hub (restores tunnel)
dxflow bridge connect <identity>

Note: You need the bridge identity to disconnect/connect. Use dxflow bridge list to find the identity first.

This allows dynamic bridge management without restarting the entire engine.

Quick Start Examples

Development Setup

Start with debug logging for development:

dxflow --log-level=debug boot up

Production Hub

Deploy as a hub server with HTTPS and daemon mode:

dxflow --config-profile=production boot up --https --proxy --daemon

Production Node

Connect to a hub as an edge instance:

dxflow --config-profile=edge boot up --bridge --daemon

Service Management

Starting & Stopping

# Start with defaults (foreground mode)
dxflow boot up

# Start as daemon service
dxflow boot up --daemon

# Stop daemon service
dxflow boot down

Health Monitoring

# Quick availability check
dxflow ping

# Detailed health status
dxflow healthcheck

Daemon Configuration

Log Files: /tmp/dxflow.{out,err}
Service File: /etc/systemd/system/dxflow-engine.service
PID Management: Handled by systemd

# Service management
systemctl status dxflow-engine
systemctl start dxflow-engine
systemctl stop dxflow-engine
systemctl restart dxflow-engine

# View logs
journalctl -u dxflow-engine -f

Log Files: /var/log/dxflow-engine.{out,err}
Service File: /etc/init.d/dxflow-engine
PID File: /run/dxflow-engine.pid

# Service management
rc-service dxflow-engine status
rc-service dxflow-engine start
rc-service dxflow-engine stop
rc-service dxflow-engine restart

Log Files: ~/Library/Logs/dxflow-engine.{out,err}
Service File: ~/Library/LaunchDaemons/com.diphyx.dxflow-engine.plist
PID Management: Handled by launchctl

# Service management
launchctl list | grep dxflow
launchctl load ~/Library/LaunchDaemons/com.diphyx.dxflow-engine.plist
launchctl unload ~/Library/LaunchDaemons/com.diphyx.dxflow-engine.plist

Architecture Patterns

Hub-Node Setup

Scenario: One hub machine manages multiple node machines

Internet Users → [Hub: dxflow.io] (--proxy --https --daemon)
                      ├── ab1234567890.dxflow.io → API server (--bridge)
                      ├── cd9876543210.dxflow.io → Dev server (--bridge)
                      ├── ef5a8b2c9d1e.dxflow.io → Local machine (--bridge)
                      └── gh7x4m8n2p5q.dxflow.io → CI/CD (--bridge)

Important: Each machine can only be a hub OR node, never both simultaneously.

Comparison Table

Aspect	Proxy Mode	Bridge Mode
Role	Hub/Server	Node/Client
Connection Direction	Receives connections	Makes connections
Subdomain Management	Provides to others	Receives from hub
Network Requirements	Public IP, DNS control	Internet access only
Performance	Direct routing, low latency	Tunneled, higher latency
Scalability	High - direct connections	Limited by tunnel bandwidth
Best For	Production platforms	Development/testing

Troubleshooting

Port already in use

Check processes using configured ports: netstat -tulpn | grep :PORT
Stop conflicting services or change port configuration

Permission denied (daemon)

Daemon installation requires elevated privileges
Use sudo for daemon operations on Linux

Cannot use proxy and bridge together

These modes are mutually exclusive on the same machine
Choose one architecture role per instance

Network disabled unexpectedly

--no-http flag overrides all network settings
Remove --no-http to enable network protocols

Bridge connection fails

Ensure hub instance has --proxy enabled
Check network connectivity to hub
Verify hub is accessible and running

Bridge disconnects frequently

Check network stability and firewall settings
Review hub server logs for connection issues
Consider network timeout configurations

For boot-related assistance:

Check engine status: dxflow ping
Review detailed health: dxflow healthcheck
Check logs in daemon mode (see platform-specific locations above)
Report issues at GitHub

Licensing

Learn about dxflow's licensing system, how to create and manage licenses, and understand the available permissions

Authentication

Secure authentication system using RSA key-pair authentication for accessing dxflow engine functionality