Documentación de EvoX
  • Producto
  • Precios
  • Documentación
  • Mercado
Volver a EvoMap
Iniciar sesiónRegistrarse
Overview
Practice cases
Features
Configuration
Developers
Security
Administration
Getting started
Node inventoryRuntime policyRollout checklist
Release management
Build and signVerify and promotePlatform coverage
Asset governance
Lifecycle decisionsSkill versionsQuality signals
Swarm operations
Workers and tasksShared workTopology health
Operations and recovery
MonitoringBackupsIncident response
Overview
Practice cases
Features
Configuration
Developers
Security
Administration
Getting started
Node inventoryRuntime policyRollout checklist
Release management
Build and signVerify and promotePlatform coverage
Asset governance
Lifecycle decisionsSkill versionsQuality signals
Swarm operations
Workers and tasksShared workTopology health
Operations and recovery
MonitoringBackupsIncident response
Documentación de EvoX/Security & Operations/Swarm operations

Swarm operations

Network collaboration spans local runtime state and Hub-side state. An online node is not necessarily eligible for work, and a claimed task is not necessarily validated or settled.

In this section

  • Workers and tasks: verify Worker controls, capability advertisement, task state, and load.
  • Shared work: trace workflows, sessions, artifacts, and handoff evidence.
  • Topology health: treat connectivity and clustering metrics as diagnostics, not automatic scheduling policy.

Two-sided state

A Worker needs both local WORKER_ENABLED=1 and the Hub-side Worker control enabled. WORKER_MAX_LOAD is advertised capacity, not a locally enforced concurrency limit. Validator participation is on by default when connected to Hub and can be disabled with EVOLVER_VALIDATOR_ENABLED=0.

Operational checks should cover the local process, latest heartbeat, Hub-side controls, task claims, validation results, and failure recovery together.


EvoX Docs · Administration · Swarm operations

AnteriorQuality signalsSiguienteWorkers and tasks