Runtime Deployment

Concepts

System requirements and supported platforms

Use the system requirements and platform matrix distributed with your approved Vega release. Validate Python version, CPU architecture, operating system, storage capacity, network policy, and each required Capability before installation. Current development material targets Python 3.12+ and Linux robot-compute environments; your production release is the authority for supported platform combinations.

Do not deploy on an unapproved host merely because installation appears to work. Hardware compatibility, audio or device availability, and Capability support are deployment requirements, not assumptions.

Local deployment

For a local deployment, install the approved Vega release on the intended host, place reviewed configuration and identity files in access-controlled locations, select durable Runtime data storage, and start the Runtime through the public CLI.

python -m vega run --mode normal \
  --config /etc/vega/base.yaml \
  --identity /etc/vega/registration.yaml

Use a dedicated service account with only the permissions required for the approved workload. Keep development and production hosts, credentials, configuration, data, and Capabilities separate.

Docker deployment

Use Docker only with an organization-approved Vega Runtime image. Keep the image version pinned, mount configuration read-only, and retain Runtime data outside the container lifecycle. This generic Compose pattern deliberately does not name an internal image; replace variables with release-approved values.

services:
  vega:
    image: ${VEGA_RUNTIME_IMAGE:?use an approved image reference}
    restart: unless-stopped
    command: ["python", "-m", "vega", "run", "--mode", "normal"]
    volumes:
      - ./config:/etc/vega:ro
      - vega-data:/var/lib/vega
volumes:
  vega-data:

Use your orchestrator's secret facility rather than placing credentials in the Compose file or a committed environment file.

Edge deployment

Edge hosts, including approved NVIDIA Jetson systems and industrial PCs, require site-specific attention to stable power, durable storage, local connectivity, thermal conditions, clock correctness, controlled shutdown, and recovery. Test the actual network and power conditions expected in the field. Limited connectivity does not make an unavailable service or Capability available.

Production deployment

Production operation requires named ownership for Runtime operations, safety, security, and release approval. Maintain monitoring, backup, change control, incident response, and tested recovery procedures. Separate staging and production deployments so changes can be validated before they affect real work.

Verification, updating, and backups

After installation, update, restart, or configuration change:

1. Confirm the expected Runtime version and deployment identity.
2. Confirm Runtime readiness and the health of the Capability required for the first test.
3. Run one low-risk, observable request.
4. Record the verification result in the deployment record.

Before an update, verify a recoverable backup and a tested rollback plan. Run the public migration command only when required by the release procedure and only against the intended Runtime data location. Restore testing should be part of routine production readiness, not an emergency-only activity.

Scaling and high availability

Scaling and high availability are deployment goals, not guarantees of a single Runtime installation. Define them from the workload, sites, response-time needs, data protection policy, Capability behavior, and physical operating procedure.

Use an approved design to avoid conflicting work against the same robot or resource. Test failure handling, operator takeover, data recovery, and service restoration in the actual deployment environment before making availability claims.