Runtime Configuration

Overview

Configuration should be specific to a site, robot or host identity, operating mode, and approved Capability set. Keep non-secret settings in reviewed configuration files and manage credentials with an approved secret-management mechanism.

Concepts

Term	Meaning
Base configuration	Reviewed settings shared by a deployment class.
Overlay	A site- or environment-specific configuration file applied with a base configuration.
Identity registration	The public description of the robot or compute deployment.
Environment variable	A host- or service-provided public setting, commonly used for secrets.
Operating mode	The selected Runtime behavior for normal, development, or safe operation.

Configuration philosophy

Keep configuration declarative, reviewed, and separate from credentials. A production deployment should have a known base configuration, a controlled site-specific overlay when required, and a dedicated identity registration.

Configuration changes are operational changes: review, test, record, and roll back them with the same discipline used for a Runtime release.

Base configuration

Site overlay

→

Effective configuration

→

Vega Runtime

Identity registration

→

Vega Runtime

→

Approved secret source

Configuration files and structure

Vega Runtime accepts YAML configuration files through repeatable --config options and an identity registration through --identity. A shared base file can be followed by a site-specific file. Later configuration is used to provide site-specific values over shared defaults.

The public configuration groups are:

vega.runtime: Operating environment and safe-operation settings.
vega.observability: Public logging and metrics settings.
vega.task_runtime: Public workload limits for the deployment.
vega.capability_platform: Capability discovery configuration.

The exact supported keys are release-specific. Use the approved configuration reference distributed with your Vega release; do not rely on undocumented keys.

Example base configuration:

yaml

vega:
  runtime:
    environment: production
    safe_mode: false
  observability:
    log_level: INFO
    metrics_enabled: true
  task_runtime:
    checkpoint_interval_seconds: 5
    max_parallel_nodes: 4
    max_parallel_steps_per_task: 8
  capability_platform: {}

Note. Use values appropriate for your approved release and operating policy. Do not treat this example as a universal production profile.

Runtime options

Start Vega Runtime with public options such as:

bash

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

--mode selects the operating mode; --config can be repeated; --identity selects the approved registration; and --log-level controls early startup logging. Use --live-voice only in a deployment approved for the documented live-voice behavior. Select Runtime data storage through the approved deployment configuration for your release.

Environment variables

The current public live-voice configuration recognizes these credential names, in this order:GEMINI_API_KEY,GOOGLE_API_KEY, andGOOGLE_GENAI_API_KEY. The optional VEGA_LIVE_VOICE andVEGA_SPEECH_BACKENDvariables select public live-voice deployment behavior.

bash

export GEMINI_API_KEY='retrieve-from-your-secret-manager'
python -m vega run --mode normal --live-voice

Never commit these values to source control, place them in a YAML file, or copy them into logs and support tickets. Make sure variables are available to the Runtime service, not only to an administrator's interactive shell.

AI model configuration

Vega Runtime supports Gemini-backed live voice in releases that expose the--live-voiceoption. Configure it with one documented Google/Gemini credential variable and an approved audio device where needed. Model providers such as OpenAI, Anthropic, or local models must not be assumed to be supported unless the installed Vega release documents them as public configuration options.

The Runtime manages the user-facing behavior of approved model-backed features; model internals are not a Runtime configuration contract.

Logging configuration

Use vega.observability.log_level for deployment logging policy and --log-level for early startup output. Use INFO for routine operation; increase detail temporarily for approved diagnosis, then return to the normal production policy. Collect logs through an access-controlled operational system.

Storage configuration

Select a durable, access-controlled Runtime data location through the approved deployment configuration for your release. Keep runtime data, configuration, logs, and backups under appropriate ownership, retention, and protection policies. Do not treat temporary storage as a production data location.