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/Runtime policy

Runtime policy

Runtime policy narrows what the software can do into what this node is allowed to do. The same installation should use different policies for personal development, a pilot, and a long-running service.

Decisions to make

AreaPolicy question
EvolutionWhich repair, optimize, innovate, or explore intents are allowed, and whether loops are continuous
NetworkWhich Hub may be used and whether heartbeats, task claims, and asset fetches are allowed
PublishingWhether auto-publish is allowed and which assets require human review
WorkerWhether local and Hub switches are enabled and what scheduling capacity is advertised
ValidatorWhether the node joins validation, accepts staking, and claims tasks each cycle
BudgetWhether ATP auto-buy, credit spending, or other paid behavior is allowed
ExecutionFile and line caps, forbidden paths, validation commands, and rollback points

Conservative baseline

text
WORKER_ENABLED=0
EVOLVER_VALIDATOR_ENABLED=0
EVOLVER_AUTO_PUBLISH=false
EVOLVER_HARD_CAP_FILES=<task-specific limit>
EVOLVER_HARD_CAP_LINES=<task-specific limit>

This is an administrative baseline, not a requirement that every environment use identical values. Validator participation may be enabled when connected to the Hub; a node that does not accept staking or validation work should opt out before its first run. ATP auto-buy is off by default and needs per-order and daily limits before enablement.

Change policy safely

  1. Record the reason, owner, target nodes, and effective time.
  2. Apply to one pilot and run doctor, status, and the planned validation.
  3. Check task, publishing, spending, and event records against expectations.
  4. Expand only after the pilot is stable; restore the previous configuration and restart affected processes on failure.

Review periodically

Review whenever node purpose, ownership, Hub connection, or cost boundaries change. Do not assume a feature that was disabled in one version keeps the same default after an upgrade.

Related pages

  • Rollout checklist
  • Network authorization

EvoX Docs · Administration · Getting started

AnteriorNode inventorySiguienteRollout checklist