Krill External Server

External Servers: Remote Krill Connectivity

External Servers enable you to connect to Krill servers outside your local network, extending your automation reach across the internet. This allows you to manage and monitor Krill instances remotely, providing flexibility for users who need access from different locations or across multiple sites.

Overview

While Krill servers on your local network are automatically discovered through beacon broadcasting, External Servers allow you to manually configure connections to remote Krill instances. This is essential for multi-site deployments, cloud-hosted servers, or accessing your automation from anywhere in the world.

Key Features

• Remote Connectivity: Connect to Krill servers anywhere on the internet
• API Key Authentication: Secure connections using server API keys
• Server Handshake: Automatic trust establishment process
• Cross-Site Automation: Share data and triggers across locations
• Remote Monitoring: Monitor remote systems from your client
• Mesh Extension: Extend your mesh network beyond local boundaries
• Platform Information: View remote server platform, version, and OS

External Server Connection Flow

graph TD
    A[Create External Server Node] --> B[Configure Server Address & Port]
    B --> C[Enter Server API Key]
    C --> D[Initiate Connection]
    D --> E{Handshake Process}
    E -->|Success| F[Establish Trust]
    E -->|Failed| G[Connection Error]
    F --> H[Server Added to Mesh]
    H --> I[Remote Access Available]

How It Works

External Server connections follow a trust-based authentication model:

1. Configuration: Enter the external server’s address, port, and API key
2. Connection Initiation: Client initiates secure connection to remote server
3. Handshake: ServerHandshakeProcess.trustServer() establishes trust
4. Authentication: API key validates the connection request
5. Mesh Integration: Remote server becomes part of your accessible mesh
6. Data Access: View and interact with remote server’s nodes

Configuration

Field	Description	Required
name	Remote server hostname or IP	Yes
port	Server port (default: 8080)	Yes
apiKey	Server’s API key for authentication	Yes
platform	Server platform (auto-detected)	No
version	Server version (auto-detected)	No
os	Server operating system (auto-detected)	No

Use Cases

• Multi-Site Monitoring: Monitor production facilities from headquarters
• Remote Field Devices: Connect to sensors in remote locations
• Cloud Integration: Access cloud-hosted Krill instances
• Branch Offices: Connect automation systems across offices
• Home & Office: Access home automation from work
• Disaster Recovery: Maintain connections to backup sites
• Partner Integration: Connect to trusted partner systems

Example Workflows

Multi-Site Temperature Monitoring:

1. External Server: Production facility Krill server
2. View: Remote temperature Data Points
3. Trigger: High Threshold on remote data
4. Executor: OutgoingWebHook (local alert)
5. Result: Local notifications for remote events

Remote Sensor Data Collection:

1. External Server: Remote weather station
2. Data Points: Temperature, humidity, wind speed
3. Compute: Local aggregation of remote data
4. Storage: Local archive of remote readings

Cross-Site Automation:

1. External Server: Remote location
2. Trigger: Remote Data Point threshold
3. Executor: Local Pin Control
4. Result: Remote events trigger local actions

Security Best Practices

• API Key Management: Keep API keys secure and rotate periodically
• HTTPS/TLS: Always use encrypted connections
• Firewall Rules: Only allow necessary ports
• VPN Option: Consider VPN for highly sensitive connections
• Access Logging: Monitor connection attempts
• Key Rotation: Regularly update API keys

Network Requirements

Requirement	Description
Port Access	Server port (default 8080) must be accessible
Static IP/DNS	Use static IP or DNS name for reliable connection
Firewall Rules	Configure firewalls to allow Krill traffic
TLS Certificates	Configure valid TLS for production
Bandwidth	Minimal—Krill uses efficient data transfer

Comparison: External vs Peer

Feature	External Server	Peer
Discovery	Manual configuration	Automatic (local network)
Network	Any internet-connected	Same local network
Configuration	Requires address, port, API key	Auto-discovered
Use Case	Remote/cloud servers	Local mesh network
Trust	API key based	Beacon handshake

Connection States

State	Description
CREATED	External server node created, not connected
EXECUTED	Connection attempt in progress
PAIRING	Handshake/trust process active
INFO	Successfully connected
ERROR	Connection or authentication failed

Troubleshooting

Issue	Possible Cause	Solution
Connection timeout	Network/firewall blocking	Check firewall rules
Authentication failed	Invalid API key	Verify API key is correct
Server not found	Wrong address/port	Verify server address and port
Intermittent connection	Network instability	Check network reliability
TLS errors	Certificate issues	Verify TLS configuration

Integration Points

• Peer Mesh: External servers integrate with local peers
• Data Points: Access and monitor remote data
• Triggers: React to remote data conditions
• Executors: Include remote servers in automation chains
• Calculations: Aggregate data across multiple sites

Architecture Considerations

When deploying External Servers:

• Latency: Remote connections have higher latency than local
• Reliability: Plan for connection interruptions
• Data Volume: Consider bandwidth for high-frequency data
• Security Zones: Implement appropriate network segmentation
• Monitoring: Monitor connection health and uptime

External Servers extend the Krill Platform’s reach beyond local networks, enabling truly distributed automation and monitoring across any distance.