Search documentation

Browse Awaken Agents docs
Docs/Awaken Agentsv1.0.0-dev/Reference/ReferenceDeployment configuration
Note·You're reading pre-release documentation (v1.0.0-dev). Interfaces and behavior may change before a stable release.

Reference · Reference

Deployment configuration

What this page covers

The canonical TOML, command-line precedence, process roles, store ownership, secret-file boundaries, and validation rules for the awaken command.

Choose the process you need before writing TOML. Use one file for that process, validate the effective result, and start the same command with the same file.

TaskCommandConfiguration boundary
Evaluate the complete local productawaken all-in-oneCombined Control, Coordinator, Resources, local Worker, Console, and protocol APIs
Run authoring and publication separatelyawaken controlControl stores and its authenticated Coordinator boundary
Run Session and Worker coordination separatelyawaken coordinatorCoordinator stores, dispatch, commit, and its authenticated Control boundary
Add execution capacityawaken-worker --config <path> --server <url>Strict, database-free Worker schema
Prepare shared server schemasawaken database migrate --config <path>Explicit migration step before application processes

Do not copy fields between these boundaries. The strict schema rejects unknown or role-incompatible values instead of ignoring them.

Value resolution

The awaken product command resolves exactly three sources, in order:

  1. presentation overrides such as --port, --data-dir, and --no-browser;
  2. an explicit --config <path> or the standard ~/.awaken/config.toml;
  3. typed defaults.

Process environment is not a deployment, model, business, or credential configuration source. Use awaken config or awaken config --json to inspect the effective, redacted result and value origins.

flowchart LR
  C[Command and presentation overrides] --> R[Typed resolver]
  F[Explicit or standard TOML] --> R
  D[Typed defaults] --> R
  R --> V{Role and cross-field validation}
  V -->|valid| E[Redacted effective configuration]
  V -->|invalid| X[Exit before service startup]
  E --> S[Start the selected process]

Common fields

TOML keyPurposeDefault / constraint
roleall-in-one, control, coordinator, or workerall-in-one; retired serve/server names are rejected
modelocal or server schema-lifecycle policylocal
data_dirembedded data, generated local seal key, and local artifacts~/.awaken
bindservice listener as IP:PORT127.0.0.1:8080
run_local_poollet AllInOne consume its own dispatchtrue; AllInOne-only
no_browsersuppress browser openingfalse
suite_hub_urloptional browser-console suite navigationunset
identity_modeno-login, self-managed, or awaken-clouddeployment policy
cloud_modelsdisabled or enableddisabled; enabled requires Awaken Cloud identity
org_id, iam_workspaceslocal organization and allowed Workspace scopevalidated typed values

Unknown TOML fields fail parsing. Command-line role subcommands (control, coordinator, worker) override role so the invoked process cannot silently acquire a broader role from the file.

Stores and schema lifecycle

TOML keyOwnerRule
runtime_database_urlCoordinator dispatch/commitPostgreSQL URL; required by split Coordinator
resource_database_urlResources componentPostgreSQL URL for shared Resource content
catalog_db, credential_db, config_db, admin_db, data_subject_dbControlembedded path or PostgreSQL URL
environment_db, sessions_db, captured_content_dbCoordinatorembedded path or PostgreSQL URL
management_database_url_fileAllInOne deployment shortcutfile containing one shared PostgreSQL URL; cannot be combined with per-store URLs
postgres_max_connectionsshared PostgreSQL poolspositive integer

Local mode migrates embedded stores during startup. Shared server deployments must run this before application Pods:

awaken database migrate --config /etc/awaken/config.toml

Application startup in server mode verifies the existing schema without writing DDL. A Worker rejects all authority database fields. Control rejects Coordinator execution databases; Coordinator rejects Control databases and the Control seal key.

Private service boundaries and secrets

TOML keyUsed byRule
coordinator_internal_urlsplit Controldestination for exact executable-Agent registration
executable_agent_registration_token_fileControl and Coordinatorboth read the same operator-projected least-scope bearer file
control_internal_urlsplit Coordinatorauthenticated Control application boundary
control_service_token_fileControl and Coordinatortoken file for that reverse boundary
control_seal_key / control_seal_key_fileAllInOne or Controlchoose one; Worker and split Coordinator reject both
mcp_bearer_tokenMCP exportthe route is absent until non-empty
cloud_iam_service_token_fileCloud identity integrationprefer file projection to inline token material

awaken config never prints token values, database URLs, or seal-key material.

Worker fields

The standalone process is awaken-worker --config <path> --server <coordinator-url>; worker_server may supply the URL in TOML. Its config uses a strict schema. The accepted fields are:

TOML keyPurpose
role, mode, worker_server, worker_server_ca_certificate_fileoptional role/mode assertions and the Coordinator connection
worker_id, worker_zone, worker_build_digest, worker_capabilities, worker_max_concurrentWorker identity, placement facts, and capacity
worker_request_credential_fileWorker request authentication material
worker_credential_material_root, worker_credential_trust_domainexact credential projection inside the Worker trust domain
worker_admin_listen, worker_drain_grace_secshealth/admin listener and graceful drain
worker_credential_probe_interval_secs, worker_credential_observation_ttl_secsliveness observation; TTL must exceed the non-zero probe interval
sandbox_tier, sandbox_dir, sandbox_allow_local_fallback, k8s_namespace, container_image, acp_clisthe Sandbox subset accepted by the standalone Worker

A Worker is database-free. It receives claim-fenced File, Memory, Skill, Repository-verification, credential, and commit clients during registration.

Product launcher execution, Sandbox, and wake fields

The following fields belong to the awaken product-launcher configuration. Do not copy its warm-pool, proxy, package-builder, or wake fields into a standalone awaken-worker file; the strict Worker schema rejects unknown keys.

TOML keyValues / role
sandbox_tierlocal, namespace, docker, podman, or k8s; default namespace
sandbox_dir, container_image, container_forward_proxy, k8s_namespaceSandbox placement and container inputs
sandbox_allow_local_fallbackexplicit opt-in; default false
sandbox_warm_pool_sizenon-negative warm capacity; default 0
package_image_registry, package_registry_auth_file, package_registry_insecurederived-image repository, Worker-side registry credentials, and explicit insecure-registry opt-in
package_image_builderdocker, podman, or k8s; requires package_image_registry
package_local_cache_ttl_secsnon-zero local derived-image retention
acp_clis, acp_default_cli, acp_session_blob_rootaccepted local ACP Brains and portable Session storage
dispatch_wakenone, pg-notify, or nats
dispatch_wake_channel, nats_url, dispatch_ownerwake channel/broker and unique claim owner

See Configure Sandbox tiers and Use a NATS wake signal for task guidance.

Observability and content capture

The product command reads log_filter, log_format, trace_file, the otlp_* / otel_* fields, content_capture, and content_redaction from the same TOML document. log_format is text or json; content capture is off, structured, or full. Configure retention and privacy before enabling full content capture.

Minimal profiles

AllInOne local:

role = "all-in-one"
mode = "local"
data_dir = "/srv/awaken"
bind = "127.0.0.1:8080"
run_local_pool = true
no_browser = false

Database-free Worker:

role = "worker"
mode = "server"
worker_server = "http://awaken-coordinator:8080"
worker_credential_material_root = "/run/awaken/credentials"
worker_credential_trust_domain = "awaken.worker"

Validate before startup

sequenceDiagram
  participant U as You
  participant C as awaken config
  participant S as Strict file schema
  participant V as Deployment validator
  participant P as Selected process

  U->>C: Supply command, overrides, and config path
  C->>S: Parse known fields
  S->>V: Resolve defaults and role constraints
  alt configuration is valid
    V-->>U: Print redacted values and origins
    U->>P: Start with the same config path
  else parsing or validation fails
    V-->>U: Exit with the offending field or constraint
  end
ResultSystem behaviorRequired action
awaken config --config <path> prints the redacted configurationThe file, defaults, and command overrides form one valid profileReview the effective role and paths, then start the same process
An unknown field, retired role, or incompatible field is reportedValidation stops before a service is startedCorrect the named field or move it to the configuration owner shown above
A local profile needs embedded schema migrationLocal startup applies itNone
A shared server schema is missing or staleApplication startup checks but does not write DDLRun awaken database migrate with the same config, then start the application process
Startup reports that a listener address is already in useBinding fails and the process exits; no alternate port is selectedChange --port, bind, or internal_bind, then start again

Hand placement is deliberately absent from deployment TOML. A claimed Worker realizes the Session’s frozen Environment, and that Environment owns the one Hand used by Native or ACP execution. The standalone awaken-sandbox hand relay is a low-level execution primitive, not a second product placement path.