Skip to Content
Application Manifest

Golem Application Manifest Reference

JSON schema

For the application manifest format we also publish JSON schemas. The current version (1.6.0-dev.9) is available here .

The JSON schema is intended to be used with editors and IDEs, to help with base validation and code completion.

Use the following YAML comments at the start of your golem.yaml documents to enable schema support:

# $schema: https://schema.golem.cloud/app/golem/1.6.0-dev.9/golem.schema.json

Note that on top of the above schema there are other checks performed by golem, see the field reference below for details.

Loading of Application Manifest documents

The Golem CLI commands that use Application Manifest start by searching for golem.yaml documents in the current and the parent directories. The outermost golem.yaml found this way is used as the root manifest document, then more manifests are searched based on its includes field.

After resolving relative paths in the documents they are merged, then component selection happens: this can be either explicit, by passing component names as positional arguments to the commands that accept them (e.g. golem build <COMPONENT_NAME>...), or implicit, in which case only components defined in the directory - including subdirectories - from where the Golem CLI was executed are used.

An Application Manifest can also be selected explicitly with --app-manifest-path (-A). This chooses the root manifest instead of searching parent directories; its includes are still resolved. Use --disable-app-manifest-discovery (-X) to run without manifest discovery.

Template variables and functions

The Application Manifest has some fields which are used as templates, these fields are marked as Templated in the field reference below. The templates are using minijinja , which is a minimal templating engine based on Jinja2 syntax.

Available template variables:

  • component_name: contains the current component name in which the template is used

Available naming related string transforming functions:

  • to_snake_case
  • to_kebab_case
  • to_lower_camel_case
  • to_pascal_case
  • to_shouty_kebab_case
  • to_shouty_snake_case
  • to_snake_case
  • to_title_case
  • to_train_case
  • to_upper_camel_case
Example usage:
build: tool-name build {{ component_name | to_snake_case }}.wasm

Component-implemented tools

Components that export golem:tool/guest declare each discovered tool by its root name in the top-level tools map. The declaration configures how the tool implementation is provisioned. Deployment fails if a discovered tool has no matching declaration, a declaration has no implementation, or more than one component implements the same tool.

Tools-only component

A component can implement tools without exporting an agent:

components:
  support:search-tools:
    componentWasm: build/search-tools.wasm
 
tools:
  search:
    config:
      index: documentation
    env:
      LOG_LEVEL: info

Component containing tools and agents

Declarations are matched to metadata discovered from the built components, so one component can provide both kinds of export:

components:
  support:assistant:
    componentWasm: build/assistant.wasm
 
agents:
  SupportAgent: {}
 
tools:
  search: {}

In this example, build/assistant.wasm must export both SupportAgent and the search tool.

Component and agent bindings

Tool bindings select which deployed tools an owner can invoke and provide invocation parameters. A component binding authorizes fresh owners such as tools-only MCP calls and is also inherited as a default by real agents exported by that component. Agent bindings alone do not authorize a fresh component owner. Use the automatically selected app-env:<environment> agent preset to vary real-agent bindings by environment. Map merge modes are upsert (the default), replace, or remove; parameter maps use the same modes.

environments:
  production:
    server: cloud
 
components:
  support:assistant:
    tools:
      search:
        version: "1.0.0"
        parameters:
          index: documentation
          limit: 20
 
agents:
  SupportAgent:
    presets:
      app-env:production:
        tools:
          search:
            parametersMergeMode: upsert
            parameters:
              limit: 5
 
  RestrictedAgent:
    toolsMergeMode: remove
    tools:
      search: {}

RestrictedAgent opts out of the inherited search binding. If no agent should inherit a tool, prefer a separate agentless owner component rather than adding the binding to a component that exports agents.

For a component-implemented tool, version can be omitted to use the version discovered from the component. When specified, it must match that version. The optional account must be the account that owns the locally deployed implementing component.

Tool middleware

Tool middleware has its own namespace under tools.middleware, so middleware is reserved and cannot be used as a tool name. A declaration selects one locally discovered implementation, optionally using component to disambiguate it, or one published release. Configuration in the declaration is consumer-owned and is not copied from a publisher:

tools:
  middleware:
    audit:
      component: acme:audit
      config:
        logLevel: info
    path-policy:
      release:
        account: middleware@example.com
        name: path-policy
        version: "1.2.0"
      config:
        allowedPrefix: /documents

As with tools, release: { releaseId: "..." } is the exact-ID alternative to the account, name, and version coordinates. A remote declaration causes deployment to reconcile an automatically managed grant for the selected environment. Administrators can manage grants independently with golem tool middleware grant create, list, get, delete, and restore. Release lifecycle commands are under golem tool middleware release. Consumers can read the granted middleware descriptor but not the publisher’s component identity, configuration, environment, files, or plugins.

Publish a local middleware from an environment deployment with toolMiddlewareReleases:

toolMiddlewareReleases:
  production:
    audit: {}

Publication and lifecycle follow tool releases: publication is committed atomically with deployment, the environment’s deployment.versionCheck controls immutability, and removing an entry does not de-publish it. Existing deployment snapshots remain pinned when a release or grant changes.

Universal means schema-agnostic, not environment-wide: universal middleware preserves the tool shape and can be installed either for the whole environment or on selected tool bindings. The environment-wide list accepts only universal middleware; per-tool lists accept both universal and monomorphic middleware. Per-tool middleware can be added at the environment, component, and agent binding layers. Lists preserve order and duplicate occurrences; each occurrence may have separate parameters and filesystem access:

environments:
  production:
    server: cloud
    tools:
      middleware:
        - name: audit
          parameters: { channel: security }
        - name: audit
          parameters: { channel: operations }
      search:
        middleware:
          - name: path-policy
            filesystemAccess: denied
 
agents:
  SupportAgent:
    tools:
      search:
        middleware: []
        middlewareMergeMode: replace

The effective chain is the environment-wide list U, followed by the merged per-tool list P, followed by the leaf tool: U ++ P ++ [leaf], outermost first. On agent tool bindings, middlewareMergeMode is prepend by default and can be append or replace; it changes only P. Environment tool bindings cannot set it. In the example, replacing P removes path-policy for SupportAgent, but both audit occurrences remain. To apply audit only to search, install it under that tool’s middleware instead of the environment-wide list. Compact entries such as path-policy@1.2.0 are also accepted. An installation’s account and version, when present, assert the selected declaration rather than selecting another release.

deployment.toolCompatibilityMode controls monomorphic middleware edge checks. structural-subtype (the default) accepts compatible projections and emits deployment warnings for input fields that a middleware discards. strict-equality requires equal runtime shapes while ignoring documentation and schema-version metadata. nominal requires the named command and its named input and error structures to match, then dynamically checks runtime values against those shapes. Universal middleware does not declare expected or presented schemas and leaves the next layer’s tool definition unchanged.

Like the other deployment options, toolCompatibilityMode is an environment property synchronized by golem environment sync-deployment-options or before deploying content changes. Updating it does not redeploy or recompile the active revision: the next deployment uses the new mode, while existing deployment snapshots retain their recorded mode and compiled plans for replay and rollback.

Secret policy

secretKeysReadable and secretKeysRevealable accept either "*" or a list of secret paths. Policies are narrowing-only across an agent’s binding layers, and revealable keys outside the effective readable scope are dropped with a deployment warning. The only supported secret merge mode is intersect, which is also the default.

environments:
  production:
    server: cloud
 
agents:
  SupportAgent:
    tools:
      search:
        secretKeysReadable: "*"
        secretKeysRevealable:
          - credentials.search.token
    presets:
      app-env:production:
        tools:
          search:
            secretKeysReadable:
              - credentials.search.token
              - credentials.search.endpoint
            secretKeysRevealable:
              - credentials.search.token

Publishing and consuming exact releases

A publisher opts a local tool into the registry for each environment. A successful deployment of this environment publishes a grantable release that records the component revision, tool version, metadata version, and metadata digest:

tools:
  search: {}
 
toolReleases:
  production:
    search: {}
 
environments:
  production:
    server: cloud

A release is not globally visible. A consumer selects an exact release once with tools.<name>.release and owns the provision configuration and bindings used by its deployment. Golem derives an automatically managed environment grant from this manifest declaration. The grant is an authorization checkpoint for adding tools to the environment, allows the deployment to read the selected release, and provides a revocation handle:

tools:
  search:
    release:
      account: publisher@example.com
      name: search
      version: "1.2.0"
    config:
      index: consumer-documents
    env:
      LOG_LEVEL: info
 
environments:
  production:
    server: cloud
 
agents:
  SupportAgent:
    tools:
      search:
        secretKeysReadable:
          - credentials.search.token

Registry subjects can use releaseId instead of the account, name, and version coordinate. A release ID remains pinned to that release. A coordinate-following grant moves to a replacement release published at the same coordinate when the publisher environment has versionCheck disabled; an ID-pinned grant stays on the previous release. Environments with versionCheck enabled accept only immutable releases and prevent mutable coordinate replacement while an active coordinate-following grant exists. Deployment planning shows the automatic grant changes implied by registry-backed tool declarations. Deployment creates missing grants before reading registry metadata or building bridge clients, and removes obsolete automatically managed grants. Protected system grants and grants created separately by an administrator are retained. The deploy actor must have permission to make the planned grant changes.

toolReleases is additive. Removing a name from the manifest does not de-publish its release, and rolling a deployment back does not undo publication. Manage lifecycle explicitly with golem tool release list, get, de-publish, and restore. De-publishing makes a release unavailable to new deployments but retains its grants; those grants become available again when the same release is restored. A deployment cannot restore or replace a de-published coordinate—you must restore it explicitly first. Superseded releases cannot be de-published or restored.

Tool publication changes are planned separately from staged deployment state. The CLI’s staged/current SAME or DIFFERENT comparison excludes tool publications; check the tool publication section of the deployment plan for those changes.

Publishing a new version does not move an existing consumer deployment. Selecting it creates a new deployment snapshot and reconciles its grant. Existing deployment snapshots and historical replay continue to use their pinned source. When loose publication replaces an existing coordinate, coordinate-following grants move to the replacement while ID-pinned grants continue to resolve the superseded release.

Runtime discovery and admission use the consumer deployment snapshot and the caller’s environment policy.

System-provided tools

Golem can ship two kinds of system-provided tool. A component-implemented built-in tool is a protected, immutable, grantable release. It behaves like any other registry release at consumption time: select its exact published coordinate with tools.<name>.release, then add a separate agents.<agent-type>.tools.<name> binding to make it available to that agent. Selecting a release does not itself bind the tool to an agent.

A native tool is compiled into the Golem host and provisioned as ambient. Do not declare it in the top-level tools map and do not specify a release coordinate. It is available to agents in the environment by default; an agent binding with the native tool’s name can narrow its parameters and policies.

Ambient tool names must not collide with application tools or selected account-owned tool releases. If a later Golem release adds an ambient tool with a name your application already uses, existing deployment snapshots remain unchanged, but preparing the next deployment fails until you resolve the name collision. Golem does not silently choose one implementation over another. This check applies to the entire ambient catalog, even when the manifest has no agent binding for that name.

Both kinds use the normal effective binding policy. In particular, configKeysReadable is narrowing-only: the effective scope is the intersection of the system or environment binding and the agent binding. Calls made by a native implementation through Golem’s config host helper are checked against that effective scope; running in the host does not grant unrestricted config access.

Golem currently ships these component-implemented built-ins:

  • read-file@0.3.0, write-file@0.3.0, and edit-file@0.3.0 provide filesystem operations. Their agent bindings must grant filesystemAccess: allowed.
  • web-fetch@0.1.0 performs read-only HTTP and HTTPS GET requests. It requires no filesystem grant and is marked open-world because it contacts external services.

For example, select and bind web-fetch as follows:

tools:
  web-fetch:
    release:
      account: builtin-tool-owner@golem.cloud
      name: web-fetch
      version: 0.1.0
 
agents:
  ResearchAgent:
    tools:
      web-fetch: {}

The tool requires a URL on each call. It also accepts --timeout-ms (default 10000, allowed range 1–30000), --max-response-bytes (default 2097152, allowed range 1–5242880), --max-redirects (default 5, allowed range 0–10), and --convert-html-to-text (default false) as optional invocation arguments. These are not manifest parameters or deployment configuration, and the safety limits’ hard ceilings cannot be overridden. A zero redirect limit disables redirect following.

web-fetch returns the final URL, HTTP status, original content type when present, textual content, and whether the result was truncated. Non-success HTTP statuses are returned normally with supported textual bodies. HTML is returned as decoded source unless --convert-html-to-text is enabled. Binary responses, invalid text encodings, unsafe redirects, redirect cycles, and elapsed deadlines return typed errors.

Completed results and typed errors are durable and replay without another HTTP request. If execution is interrupted before the result is recorded, recovery may retry the GET request; endpoints should therefore tolerate repeated GETs.

Bridge generation

Bridge generation accepts canonical ambient native-tool names without a top-level tools declaration, release grant, or local implementation component. It resolves ambient metadata from the selected environment, so the CLI must be authenticated to read that environment’s deployment plan:

bridge:
  rust:
    internal:
      tools: [native-search]

Name-only component dependencies use the same lookup. Declared local and registry-backed tools resolve from the application; otherwise the name is resolved from the selected environment’s ambient catalog and then from its MCP imports:

components:
  my-app:consumer:
    dependencies:
      tools: [native-search, catalog-search]

"*" under bridge.<language>.internal.tools includes all visible ambient and MCP-imported tools in addition to application tools. Explicit names avoid MCP discovery when ambient metadata already satisfies every request. Ambient and application tool names may not collide; ambient names take precedence over MCP projections, and earlier MCP imports take precedence over later imports.

Generated clients always invoke the canonical Golem tool name through tool-rpc. They contain no native host implementation ID, MCP endpoint, transport, or credentials. Native provision, binding, and middleware configuration is deployment-only and does not change the generated API or generation cache identity.

For registry-backed tools, the generator reads only the release’s safe tool definition and metadata digest. It does not require the publisher’s WASM or permission to inspect the publisher component. Release identity and metadata digest are included in generation cache markers, so changing the selected release invalidates generated output. A missing grant is planned and created before metadata access; planning fails clearly when the deploy actor lacks permission to reconcile the grant.

Field reference

manifestVersion
available since1.1.0

Optional manifest schema version string.

includes
available since1.1.0

Optional list of glob patterns that are used for adding search patterns for other Application Manifests when using auto discovery of them. The patterns are relative to the manifest document in which they are defined.

The default search pattern is **/golem.yaml, which searches for golem.yaml documents in every subdirectory recursively. Templates and examples provided by Golem usually use more specific search patterns to make the lookups more efficient.

The includes fields can be defined in one manifest only, usually in the project root directory. Defining it multiple times results in validation error.

Example usage:
includes:
- components-dir/*/golem.yaml
- custom-templates/golem-*.yaml
app
available since1.1.0

Required application name which will be used as the deployment name for the application.

localServer
available since1.1.0

Optional local server configuration that defines where the built-in local preset lives. golem server run uses it to bind the local server, other golem commands targeting the preset use it to connect, golem server clean uses it to locate stored state, and local deployment subdomain expansion uses the relevant ports. CLI flags passed to golem server run override these values. Path values are resolved relative to the manifest that declares localServer. Do not set manifest ports to 0; port 0 is only allowed when passed directly as a golem server run port flag.

localServer.routerAddr
available since1.1.0

Optional bind address for the built-in local preset’s main API. golem server run binds to this address, and other golem commands targeting the preset connect to it. When it is 0.0.0.0, commands connect through 127.0.0.1. Must be an IPv4 address literal; host names are not supported. Defaults to 0.0.0.0 for binding and localhost for connections. It only applies to the main API: the HTTP API and MCP listeners (customRequestPort, mcpPort) always bind all interfaces, and deployment subdomain values always expand to <subdomain>.localhost:<port>, which resolves only on the machine running the server. To reach local deployments from another machine, use domain with a host name that resolves there.

localServer.routerPort
available since1.1.0

Optional port for the built-in local preset’s main API. golem server run binds to this port, and other golem commands targeting the preset connect to it. Defaults to 9881. Do not set this to 0 in the manifest; use --router-port 0 directly with golem server run when you need an OS-assigned free port.

localServer.customRequestPort
available since1.1.0

Optional HTTP API port for local custom requests. Defaults to 9006; HTTP deployments using subdomain resolve to <subdomain>.localhost:<customRequestPort>. Requests are routed by matching their Host header against this expansion, so the server has to bind the same port: if golem server run is started with a different --custom-request-port (including 0), it warns that subdomain deployments are not reachable. Do not set this to 0 in the manifest; use --custom-request-port 0 directly with golem server run when you need an OS-assigned free port.

localServer.mcpPort
available since1.1.0

Optional MCP server port for local MCP requests. Defaults to 9007; MCP deployments using subdomain resolve to <subdomain>.localhost:<mcpPort>. Requests are routed by matching their Host header against this expansion, so the server has to bind the same port: if golem server run is started with a different --mcp-port (including 0), it warns that subdomain deployments are not reachable. Do not set this to 0 in the manifest; use --mcp-port 0 directly with golem server run when you need an OS-assigned free port.

localServer.portsFile
available since1.1.0

Optional path where the local server writes the actually-bound ports as JSON on startup. Useful together with direct golem server run port flags such as --custom-request-port 0.

localServer.dataDir
available since1.1.0

Optional directory used by golem server run and removed by golem server clean or golem server run --clean. Before deleting it, the CLI displays the resolved absolute path and asks for confirmation; pass -Y or --yes only after verifying the target. Filesystem roots are always rejected. Defaults to $XDG_STATE_HOME/golem. Pass -X to server clean to ignore the manifest and clean the platform default.

localServer.systemMemoryOverride
available since1.1.0

Optional positive byte-size string that overrides detected system memory for local agent admission and eviction, leaving room for other applications. For example, 2GiB sets a 2 GiB budget; the executor uses 80% for admission and reserves 20% for host overhead. Flag, environment variable, and manifest accept the same case-insensitive units: 1mb and 1MB mean 1,000,000 bytes; 1MiB means 1,048,576 bytes. Whole-number quantities and ASCII spaces are accepted; use 1536 MiB instead of 1.5 GiB. Quote unitless byte values in YAML. Precedence is --system-memory-override, then GOLEM_LOCAL_SERVER_SYSTEM_MEMORY_OVERRIDE, then this field, then automatic host/cgroup memory detection. The value maps to the executor’s memory.system_memory_override. This is not a hard process RSS limit: compilation and other host allocations can exceed the budget.

localServer.agentFilesystemRoot
available since1.1.0

Optional root directory for deterministic agent filesystem directories, laid out as <root>/<environment_id>/<component_id>/<agent_segment>/. The agent segment is the agent name with each character that is not an ASCII letter, a digit, - or _ replaced by _, cut to 32 characters, then - and the BLAKE3 hash of the agent id.

httpApi
available since1.1.0

Optional object for defining HTTP API deployments. Deployments can be defined in multiple manifests, and they are merged during deployment.

httpApi.deployments
available since1.1.0

Optional map of HTTP API deployments by environment name.

httpApi.deployments.<environment-name>
available since1.1.0

Optional list of HTTP API deployments for the environment.

httpApi.deployments.<environment-name>[*].domain
available since1.1.0

Full concrete domain for the deployment. Use domain for custom registered domains and custom server environments. Define exactly one of domain or subdomain.

httpApi.deployments.<environment-name>[*].subdomain
available since1.1.0

Built-in server subdomain for the deployment. Must be a single DNS label (lowercase letters, digits, and hyphens only). In a local environment it resolves to <subdomain>.localhost:9006 by default, or <subdomain>.localhost:<customRequestPort> when localServer.customRequestPort is set to a stable nonzero port. In a cloud environment it resolves to <subdomain>.apps.golem.cloud. Cannot be used with custom server environments — use domain instead. Define exactly one of domain or subdomain.

httpApi.deployments.<environment-name>[*].scheme
available since1.1.0

Public HTTP API scheme: http or https. When omitted, defaults to http for the built-in local server (including the implicit local target), and https for the built-in cloud server. Custom server environments require an explicit value. An explicit value always overrides the default; the management API URL does not determine the public scheme. This controls the origin advertised in generated OpenAPI documents, not TLS configuration.

httpApi.deployments.<environment-name>[*].webhookUrl
available since1.1.0

Optional webhook URL for the deployment.

httpApi.deployments.<environment-name>[*].agents
available since1.1.0

Optional map of HTTP API deployment options by agent type name.

httpApi.deployments.<environment-name>[*].agents.<agent-type-name>.securityScheme
available since1.1.0

Optional security scheme for the agent in this deployment.

httpApi.deployments.<environment-name>[*].agents.<agent-type-name>.testSessionHeaderName
available since1.1.0

Optional test session header name for the agent in this deployment.

mcp
available since1.1.0

Optional object for defining MCP deployments.

mcp.deployments
available since1.1.0

Optional map of MCP deployments by environment name.

mcp.deployments.<environment-name>
available since1.1.0

Optional list of MCP deployments for the environment.

mcp.deployments.<environment-name>[*].domain
available since1.1.0

Full concrete domain for the MCP deployment. Use domain for custom registered domains and custom server environments. Define exactly one of domain or subdomain.

mcp.deployments.<environment-name>[*].subdomain
available since1.1.0

Built-in server subdomain for the MCP deployment. Must be a single DNS label (lowercase letters, digits, and hyphens only). In a local environment it resolves to <subdomain>.localhost:9007 by default, or <subdomain>.localhost:<mcpPort> when localServer.mcpPort is set to a stable nonzero port. In a cloud environment it resolves to <subdomain>.mcps.golem.cloud. Cannot be used with custom server environments — use domain instead. Define exactly one of domain or subdomain.

mcp.deployments.<environment-name>[*].agents
available since1.1.0

Optional map of MCP deployment options by agent type name.

mcp.deployments.<environment-name>[*].agents.<agent-type-name>.securityScheme
available since1.1.0

Optional security scheme for the agent in this MCP deployment.

environments
available since1.1.0

Optional application environments by environment name.

environments.<environment-name>.default
available since1.1.0

Optional boolean which when set to true marks the environment as default. Only one environment can be marked as default. If missing, the first environment is used as default.

environments.<environment-name>.account
available since1.1.0

Optional account that owns the application environment. When not specified then the current user will be used.

environments.<environment-name>.server
available since1.1.0

Optional server configuration for the environment. Accepted values:

  • local
    available since1.1.0
  • cloud
    available since1.1.0

or a custom server object with the fields documented below.

environments.<environment-name>.server.url
available since1.1.0

Required URL for custom servers.

environments.<environment-name>.server.workerUrl
available since1.1.0

Optional custom URL for golem worker service.

environments.<environment-name>.server.allowInsecure
available since1.1.0

Optional boolean which defaults to false, when set to true it allows insecure connections to the server.

environments.<environment-name>.server.auth.oauth2
available since1.1.0

Optional boolean which when set to true selects OAuth2 based authentication.

environments.<environment-name>.server.auth.staticToken
available since1.1.0

Optional string static token for authentication when using static token based authentication.

environments.<environment-name>.componentPresets
available since1.1.0

Optional preset name or list of preset names which will be used for the application in the given environment.

environments.<environment-name>.cli.format
available since1.1.0

Optional default format for the environment, accepted values:

  • text(default value)
    available since1.1.0
  • json
    available since1.1.0
  • pretty-json
    available since1.1.0
  • pretty
    available since1.1.0
    alias for pretty-json
  • yaml
    available since1.1.0
  • pretty-yaml
    available since1.1.0
environments.<environment-name>.cli.autoConfirm
available since1.1.0

Optional boolean which when set enables the auto-confirm (yes) flag by default.

environments.<environment-name>.cli.redeployAgents
available since1.1.0

Optional boolean which when set enables redeploy-agents flag by default.

environments.<environment-name>.cli.reset
available since1.1.0

Optional boolean which when set enables reset flag by default.

environments.<environment-name>.deployment.compatibilityCheck
available since1.1.0

Optional boolean to enable compatibility checks during deployment.

environments.<environment-name>.deployment.toolCompatibilityMode
available since1.1.0

Optional tool middleware compatibility mode. Accepted values are structural-subtype (the default), strict-equality, and nominal. Structural subtype mode warns about inputs discarded by a middleware; strict equality ignores documentation and schema-version metadata; nominal mode checks named command, input, and error structures and dynamically validates runtime shapes.

environments.<environment-name>.deployment.versionCheck
available since1.1.0

Optional boolean to enable strict version checks during deployment. Published tool releases are immutable when enabled. When disabled, publishing changed content at an existing coordinate creates a replacement release, marks the previous release as superseded, and moves active coordinate-following grants to the replacement. Strict environments cannot use mutable releases.

environments.<environment-name>.deployment.securityOverrides
available since1.1.0

Optional boolean to allow security overrides during deployment.

toolReleases.<environment-name>
available since1.1.0

Optional additive map of local tool names to publish as grantable releases when this environment is deployed. Each value is an empty object. Publication records the exact source and metadata of the deployed local tool and follows the environment’s deployment.versionCheck policy. Removing a name does not de-publish an existing release; use golem tool release de-publish <release-id> for that explicit lifecycle action.

toolMiddlewareReleases.<environment-name>
available since1.1.0

Optional additive map of local tool middleware names to publish as grantable releases when this environment is deployed. Each value is an empty object. Publication and lifecycle follow tool releases and the environment’s deployment.versionCheck policy.

components
available since1.1.0

Optional map of Golem components indexed by component-name-s used for defining components.

The components field can be defined in multiple manifest documents, but the used component-name-s must be unique across all the used manifest documents. Using the same component-name more then once results in validation error.

Example usage:
components:
  pack-ns:component-name:
    componentWasm: # ...
    # ...
  pack:comp-b:
    componentWasm: # ...
    # ...
components.<component-name>.templates
available since1.1.0

Optional template name or list of template names which will be used for creating the component fields.

The template name must be one of that are defined in componentTemplates.

Templates can also inherit other templates, but every template may be inherited only through a single path: e.g. using two templates that both inherit the same template is rejected.

See componentTemplates and Template variable and functions for defining templates.

Related fields:

components.<component-name>.presets
available since1.1.0

Optional map of presets used to define preset variations for a component.

A preset contains the same fields as a component. Presets can also specify a components.<component-name>.presets.<preset-name>.default flag to mark it as the default preset for selection.

Related fields:

components.<component-name>.presets.<preset-name>.default
available since1.1.0

Preset specific components.<component-name>.default.

Optional boolean which when set to true marks the preset as the default for selection.

Related fields:

components.<component-name>.dir
available since1.1.0

Optional base directory for resolving component paths. The path is relative to the manifest document.

Related fields:

components.<component-name>.buildMergeMode
available since1.1.0

Optional merge mode for components.<component-name>.build. Accepted values:

  • append(default value)
    available since1.1.0
  • prepend
    available since1.1.0
  • replace
    available since1.1.0

Related fields:

components.<component-name>.files
available since1.1.0

Optional list of files entries, which can be used for defining the Initial File System for the component.

Example usage:
components:
  pack-ns:component-name:
    # ...
    files:
    - sourcePath: ./files/foo.txt
      targetPath: /files/foo.txt
      permissions: read-only
    - sourcePath: ./files/bar.txt
      targetPath: /files/bar.txt
      permissions: read-write

Related fields:

components.<component-name>.filesMergeMode
available since1.1.0

Optional merge mode for components.<component-name>.files. Accepted values:

  • append(default value)
    available since1.1.0
  • prepend
    available since1.1.0
  • replace
    available since1.1.0

Related fields:

components.<component-name>.files[*].sourcePath
available since1.1.0

Required source path of the file to be added to the Initial File System. The path can be a file path relative to the manifest document or an URL.

Related fields:

components.<component-name>.files[*].targetPath
available since1.1.0

Required target path of the file in the Initial File System. The path must be an absolute path.

Related fields:

components.<component-name>.files[*].permissions
available since1.1.0

Optional string enum which controls file permissions. Accepted values:

  • read-only(default value)
    available since1.1.0
  • read-write
    available since1.1.0

Related fields:

components.<component-name>.plugins
available since1.1.0

Optional list of component plugin installation entries,

Related fields:

components.<component-name>.pluginsMergeMode
available since1.1.0

Optional merge mode for components.<component-name>.plugins. Accepted values:

  • append(default value)
    available since1.1.0
  • prepend
    available since1.1.0
  • replace
    available since1.1.0

Related fields:

components.<component-name>.plugins[*].name
available since1.1.0

Required name of the plugin.

Related fields:

components.<component-name>.plugins[*].version
available since1.1.0

Required version of the plugin.

Related fields:

components.<component-name>.plugins[*].account
available since1.1.0

Optional account used for installing the plugin.

Related fields:

components.<component-name>.plugins[*].parameters
available since1.1.0

Optional string map of plugin parameters.

Related fields:

components.<component-name>.config
available since1.1.0

Optional configuration for the component.

Related fields:

components.<component-name>.env
available since1.1.0

Optional string map of environment variables for the component.

Related fields:

components.<component-name>.tools
available since1.1.0

Optional map of tool bindings inherited by agents exported by the component and used as the authorization baseline for fresh component owners, including tools-only MCP calls.

Related fields:

components.<component-name>.toolsMergeMode
available since1.1.0

Optional merge mode for components.<component-name>.tools. Accepted values:

  • upsert(default value)
    available since1.1.0
  • replace
    available since1.1.0
  • remove
    available since1.1.0

Related fields:

components.<component-name>.dependencies.tools
available since1.1.0

Optional canonical tool names whose guest clients the component consumes. A declared local tool creates a component build dependency; a declared registry-backed tool uses its selected release. A name with no declaration is resolved from the selected environment’s ambient native tools first and MCP imports second, without requiring a local implementation component or release grant.

Related fields:

components.<component-name>.envMergeMode
available since1.1.0

Optional merge mode for components.<component-name>.env. Accepted values:

  • upsert(default value)
    available since1.1.0
  • replace
    available since1.1.0
  • remove
    available since1.1.0

Related fields:

components.<component-name>.wasiConfig
available since1.1.0

Optional string map of WASI configuration variables for the component.

Related fields:

components.<component-name>.wasiConfigMergeMode
available since1.1.0

Optional merge mode for components.<component-name>.wasiConfig. Accepted values:

  • upsert(default value)
    available since1.1.0
  • replace
    available since1.1.0
  • remove
    available since1.1.0

Related fields:

components.<component-name>.componentWasm
available since1.1.0

Optional file path for the built WASM component.

The path is relative to the manifest document in which the field is defined.

Example usage:
components:
  pack-ns:component-name:
    # ...
    componentWasm: build/component.wasm

Related fields:

components.<component-name>.outputWasm
available since1.1.0

Optional file path for the output WASM component which is ready to be uploaded to Golem.

The path is relative to the manifest document in which the field is defined.

Example usage:
components:
  pack-ns:component-name:
    # ...
    outputWasm: build/output.wasm

Related fields:

components.<component-name>.build
available since1.1.0

Optional list of build steps that creates components.<component-name>.componentWasm.

Each build step can be one of:

  • an external command (with command field)
  • a QuickJS crate generation step (with generateQuickjsCrate field)
  • a QuickJS d.ts generation step (with generateQuickjsDts field)
  • an inject to prebuilt QuickJS step (with injectToPrebuiltQuickjs field)
  • a JS preinitialization step (with preinitializeJs field)
Example usage:
components:
  pack-ns:component-name:
    build:
    - command: bindgen-tool src component.wasm
    - command: build-tool src component.wasm

Related fields:

components.<component-name>.build[*].command
available since1.1.0

Required external command that will be used as a build step for creating components.<component-name>.componentWasm.

Related fields:

components.<component-name>.build[*].dir
available since1.1.0

Optional directory path which will be used as working directory when executing components.<component-name>.build[*].command.

The path is relative to the manifest document, and defaults to ..

Related fields:

components.<component-name>.build[*].env
available since1.1.0

Optional string map of environment variables for the build command.

Related fields:

components.<component-name>.build[*].rmdirs
available since1.1.0

Optional list of directory paths which will be deleted before executing the command.

The path is relative to components.<component-name>.build[*].dir.

The rmdirs field is useful when a binding generator does not automatically clean stale bindings.

Directories are not removed if the command is skipped because of up-to-date checks, see components.<component-name>.build[*].sources and components.<component-name>.build[*].targets.

Directories are removed before executing components.<component-name>.build[*].mkdirs.

Related fields:

components.<component-name>.build[*].mkdirs
available since1.1.0

Optional list of directory paths which will be created before executing the command if they do not exists.

The path is relative to components.<component-name>.build[*].dir.

The mkdirs field is useful when a build of binding generator tool does not automatically create required nested folders.

Directories are not created if the command is skipped because of up-to-date checks, see components.<component-name>.build[*].sources and components.<component-name>.build[*].targets.

Directories are created after executing components.<component-name>.build[*].rmdirs.

Related fields:

components.<component-name>.build[*].sources
available since1.1.0

Optional list of paths and globs which are used as sources for performing up-to-date checks.

If defined then components.<component-name>.build[*].targets also have to be used.

The up-to-date check

Example usage:
components:
  pack-ns:component-name:
    # ...
    build:
    - command: build-tool src-dir out.wasm
      sources:
      - src-dir/*
      targets:
      - out.wasm

Related fields:

components.<component-name>.build[*].targets
available since1.1.0

Optional list of paths and globs which are used as targets for performing up-to-date checks.

If defined then components.<component-name>.build[*].sources also have to be used.

See components.<component-name>.build[*].sources for up-to-date check details.

Related fields:

components.<component-name>.customCommands
available since1.1.0

Optional map of component specific external commands, which are useful for defining e.g. one time installation or update related commands for the component.

The commands can be executed using:

golem exec command-name

Multiple components can use the same command-name, the above command will execute all matching commands in this case, both component specific and project ones.

For defining project level custom commands see customCommands.

Example usage:
components:
  pack-ns:component-name:
    # ...
    customCommands:
      npm-install:
      - command: npm install

Related fields:

components.<component-name>.customCommands.<command-name>[*].dir
available since1.1.0

Component specific customCommands.<command-name>[*].dir.

Related fields:

components.<component-name>.customCommands.<command-name>[*].env
available since1.1.0

Component specific customCommands.<command-name>[*].env.

Related fields:

components.<component-name>.customCommands.<command-name>[*].rmdirs
available since1.1.0

Component specific customCommands.<command-name>[*].rmdirs.

Related fields:

components.<component-name>.customCommands.<command-name>[*].mkdirs
available since1.1.0

Component specific customCommands.<command-name>[*].mkdirs.

Related fields:

components.<component-name>.customCommands.<command-name>[*].mkdirs
available since1.1.0

Component specific customCommands.<command-name>[*].mkdirs.

Related fields:

components.<component-name>.customCommands.<command-name>[*].sources
available since1.1.0

Component specific customCommands.<command-name>[*].sources.

Related fields:

components.<component-name>.customCommands.<command-name>[*].targets
available since1.1.0

Component specific customCommands.<command-name>[*].targets.

Related fields:

components.<component-name>.clean
available since1.1.0

Component specific clean.

Related fields:

clean
available since1.1.0

Optional list of paths which are added as targets to the golem clean command.

The paths are relative to the manifest document.

The clean command deletes the following paths:

  • build and custom command targets
  • the paths defined in common and component specific clean fields.

Related fields:

customCommands
available since1.1.0

Optional map of custom external commands, which are useful for defining e.g. one time installation or update related project commands.

The commands can be executed using:

golem exec command-name

Components specific custom commands can use the same command-name, the above command will execute all matching commands in this case, both component specific and project ones.

For defining component specific custom commands see components.<component-name>.customCommands.

Example usage:
customCommands:
  npm-install:
  - command: npm install
customCommands.<command-name>[*].dir
available since1.1.0

Optional directory path which will be used as working directory when executing customCommands.<command-name>[*].command.

The path is relative to the manifest document, and defaults to ..

Related fields:

customCommands.<command-name>[*].env
available since1.1.0

Optional string map of environment variables for the command.

Related fields:

customCommands.<command-name>[*].rmdirs
available since1.1.0

Optional list of directory paths which will be deleted before executing the command.

The path is relative to customCommands.<command-name>[*].dir.

The rmdirs field is useful when a binding generator does not automatically clean stale bindings.

Directories are not removed if the command is skipped because of up-to-date checks, see customCommands.<command-name>[*].sources and customCommands.<command-name>[*].targets.

Directories are removed before executing customCommands.<command-name>[*].mkdirs.

Related fields:

customCommands.<command-name>[*].mkdirs
available since1.1.0

Optional list of directory paths which will be created before executing the command if they do not exists.

The path is relative to customCommands.<command-name>[*].dir.

The mkdirs field is useful when a build of binding generator tool does not automatically create required nested folders.

Directories are not created if the command is skipped because of up-to-date checks, see customCommands.<command-name>[*].sources and customCommands.<command-name>[*].targets.

Directories are created after executing customCommands.<command-name>[*].rmdirs.

Related fields:

customCommands.<command-name>[*].sources
available since1.1.0

Optional list of paths and globs which are used as sources for performing up-to-date checks.

If defined then customCommands.<command-name>[*].targets also have to be used.

The up-to-date check

Related fields:

customCommands.<command-name>[*].targets
available since1.1.0

Optional list of paths and globs which are used as targets for performing up-to-date checks.

If defined then customCommands.<command-name>[*].sources also have to be used.

See customCommands.<command-name>[*].sources for up-to-date check details.

Related fields:

componentTemplates
available since1.1.0

Optional map of named templates, which can be used in components.<component-name>.templates.

Templates help in extracting common build patterns and reuse them for multiple components.

The templates field can be defined in multiple application manifest documents, but the template names must be unique.

See Template variable and functions for more information about templating.

componentTemplates.<template-name>.guestLanguage
available since1.1.0

Optional guest language of the components built with the template: ts, effect, rust, scala or moonbit.

A component’s guest language comes from the templates applied to it, directly or through template inheritance. The CLI uses it for language specific features, such as dependency checks, bridge generation and the REPL. The built-in templates (e.g. ts, rust, scala) declare their language, so custom templates inheriting them don’t need to declare it; custom templates that don’t inherit a built-in template can declare it to enable these features. The templates applied to a component must not declare different languages.

componentTemplates.<template-name>.componentWasm
available since1.1.0

Templated components.<component-name>.componentWasm.

componentTemplates.<template-name>.outputWasm
available since1.1.0

Templated components.<component-name>.outputWasm.

componentTemplates.<template-name>.buildMergeMode
available since1.1.0

Templated components.<component-name>.buildMergeMode.

componentTemplates.<template-name>.build
available since1.1.0

Templated components.<component-name>.build.

componentTemplates.<template-name>.build[*].command
available since1.1.0

Templated components.<component-name>.build[*].command.

componentTemplates.<template-name>.build[*].dir
available since1.1.0

Templated components.<component-name>.build[*].dir.

componentTemplates.<template-name>.build[*].env
available since1.1.0

Templated components.<component-name>.build[*].env.

componentTemplates.<template-name>.build[*].rmdirs
available since1.1.0

Templated components.<component-name>.build[*].rmdirs.

componentTemplates.<template-name>.build[*].mkdirs
available since1.1.0

Templated components.<component-name>.build[*].mkdirs.

componentTemplates.<template-name>.build[*].sources
available since1.1.0

Templated components.<component-name>.build[*].sources.

componentTemplates.<template-name>.build[*].targets
available since1.1.0

Templated components.<component-name>.build[*].targets.

componentTemplates.<template-name>.customCommands
available since1.1.0

Templated components.<component-name>.customCommands.

componentTemplates.<template-name>.customCommands.<command-name>[*].dir
available since1.1.0

Templated components.<component-name>.customCommands.<command-name>[*].dir.

componentTemplates.<template-name>.customCommands.<command-name>[*].env
available since1.1.0

Templated components.<component-name>.customCommands.<command-name>[*].env.

componentTemplates.<template-name>.customCommands.<command-name>[*].rmdirs
available since1.1.0

Templated components.<component-name>.customCommands.<command-name>[*].rmdirs.

componentTemplates.<template-name>.customCommands.<command-name>[*].mkdirs
available since1.1.0

Templated components.<component-name>.customCommands.<command-name>[*].mkdirs.

componentTemplates.<template-name>.customCommands.<command-name>[*].sources
available since1.1.0

Templated components.<component-name>.customCommands.<command-name>[*].sources.

componentTemplates.<template-name>.customCommands.<command-name>[*].targets
available since1.1.0

Templated components.<component-name>.customCommands.<command-name>[*].targets.

componentTemplates.<template-name>.clean
available since1.1.0

Templated components.<component-name>.clean.

componentTemplates.<template-name>.config
available since1.1.0

Templated components.<component-name>.config.

componentTemplates.<template-name>.env
available since1.1.0

Templated components.<component-name>.env.

componentTemplates.<template-name>.envMergeMode
available since1.1.0

Templated components.<component-name>.envMergeMode.

componentTemplates.<template-name>.wasiConfig
available since1.1.0

Templated components.<component-name>.wasiConfig.

componentTemplates.<template-name>.wasiConfigMergeMode
available since1.1.0

Templated components.<component-name>.wasiConfigMergeMode.

componentTemplates.<template-name>.plugins
available since1.1.0

Templated components.<component-name>.plugins.

componentTemplates.<template-name>.pluginsMergeMode
available since1.1.0

Templated components.<component-name>.pluginsMergeMode.

componentTemplates.<template-name>.files
available since1.1.0

Templated components.<component-name>.files.

componentTemplates.<template-name>.filesMergeMode
available since1.1.0

Templated components.<component-name>.filesMergeMode.

componentTemplates.<template-name>.files[*].sourcePath
available since1.1.0

Templated components.<component-name>.files[*].sourcePath.

componentTemplates.<template-name>.files[*].targetPath
available since1.1.0

Templated components.<component-name>.files[*].targetPath.

componentTemplates.<template-name>.files[*].permissions
available since1.1.0

Templated components.<component-name>.files[*].permissions.

componentTemplates.<template-name>.presets
available since1.1.0

Templated components.<component-name>.presets.

componentTemplates.<template-name>.presets.<preset-name>.default
available since1.1.0

Templated and preset specific components.<component-name>.default.

agents
available since1.1.0

Optional map of agents by agent type name.

agents.<agent-type-name>.templates
available since1.1.0

Optional template name or list of template names which will be used for creating the agent fields.

As for components, every template may be inherited only through a single path: e.g. listing a template together with another template that inherits it is rejected.

Related fields:

agents.<agent-type-name>.config
available since1.1.0

Optional configuration for the agent.

Related fields:

agents.<agent-type-name>.env
available since1.1.0

Optional string map of environment variables for the agent.

Related fields:

agents.<agent-type-name>.tools
available since1.1.0

Optional map of tool bindings merged over bindings inherited from the implementing component. Agent bindings affect real agents only and cannot authorize fresh component owners.

Related fields:

agents.<agent-type-name>.toolsMergeMode
available since1.1.0

Optional merge mode for agents.<agent-type-name>.tools: upsert (the default), replace, or remove.

Related fields:

agents.<agent-type-name>.envMergeMode
available since1.1.0

Optional merge mode for agents.<agent-type-name>.env. Accepted values:

  • upsert(default value)
    available since1.1.0
  • replace
    available since1.1.0
  • remove
    available since1.1.0

Related fields:

agents.<agent-type-name>.wasiConfig
available since1.1.0

Optional string map of WASI configuration variables for the agent.

Related fields:

agents.<agent-type-name>.wasiConfigMergeMode
available since1.1.0

Optional merge mode for agents.<agent-type-name>.wasiConfig. Accepted values:

  • upsert(default value)
    available since1.1.0
  • replace
    available since1.1.0
  • remove
    available since1.1.0

Related fields:

agents.<agent-type-name>.plugins
available since1.1.0

Optional list of plugin installations for the agent.

Related fields:

agents.<agent-type-name>.pluginsMergeMode
available since1.1.0

Optional merge mode for agents.<agent-type-name>.plugins. Accepted values:

  • append(default value)
    available since1.1.0
  • prepend
    available since1.1.0
  • replace
    available since1.1.0

Related fields:

agents.<agent-type-name>.plugins[*].name
available since1.1.0

Required name of the plugin.

Related fields:

agents.<agent-type-name>.plugins[*].version
available since1.1.0

Required version of the plugin.

Related fields:

agents.<agent-type-name>.plugins[*].account
available since1.1.0

Optional account used for installing the plugin.

Related fields:

agents.<agent-type-name>.plugins[*].parameters
available since1.1.0

Optional string map of plugin parameters.

Related fields:

agents.<agent-type-name>.files
available since1.1.0

Optional list of files entries for defining the Initial File System for the agent.

Related fields:

agents.<agent-type-name>.filesMergeMode
available since1.1.0

Optional merge mode for agents.<agent-type-name>.files. Accepted values:

  • append(default value)
    available since1.1.0
  • prepend
    available since1.1.0
  • replace
    available since1.1.0

Related fields:

agents.<agent-type-name>.files[*].sourcePath
available since1.1.0

Required source path of the file. The path can be a file path relative to the manifest document or an URL.

Related fields:

agents.<agent-type-name>.files[*].targetPath
available since1.1.0

Required target path of the file. The path must be an absolute path.

Related fields:

agents.<agent-type-name>.files[*].permissions
available since1.1.0

Optional string enum which controls file permissions. Accepted values:

  • read-only(default value)
    available since1.1.0
  • read-write
    available since1.1.0

Related fields:

agents.<agent-type-name>.presets
available since1.1.0

Optional map of presets for the agent.

Related fields:

agents.<agent-type-name>.presets.<preset-name>.default
available since1.1.0

Preset specific agents.<agent-type-name>.default.

Optional boolean which when set to true marks the preset as the default for selection.

Related fields:

tools
available since1.1.0

Optional map of canonical tool declarations indexed by the tool’s lower-kebab-case logical name. A declaration either matches a locally discovered implementation, selects one with component, or selects an exact published release with release. Release coordinates are specified only here; agents, component dependencies, bridge generation, and other consumers refer to the logical name. Provision fields such as config, env, plugins, and files belong to the consuming deployment.

tools.<tool-name>.release
available since1.1.0

Optional exact published release reference. Specify either releaseId or all of account, name, and version. Golem derives and reconciles an automatically managed environment grant from this declaration; planned changes remain visible during deployment. Omit release for a locally implemented tool.

tools.<tool-name>.component
available since1.1.0

Optional local implementing component name. Use it to disambiguate components that export the same tool name and to let a name-only dependencies.tools entry resolve to its local build dependency.

tools.middleware.<middleware-name>
available since1.1.0

Optional canonical tool middleware declaration. Select a local implementation with component or an exact published release with release; these source forms are mutually exclusive. Consumer-owned provision fields include config, env, plugins, and files.

environments.<environment-name>.tools.middleware
available since1.1.0

Optional ordered environment-wide middleware list applied before every per-tool middleware chain. Only universal (schema-agnostic) middleware is accepted here. Duplicate middleware occurrences are preserved.

agents.<agent-type-name>.tools.<tool-name>.middleware
available since1.1.0

Optional ordered per-tool middleware list accepting universal or monomorphic middleware. Entries may be compact name@version strings or records with name, optional version, account, parameters, and filesystemAccess.

Related fields:

agents.<agent-type-name>.tools.<tool-name>.middlewareMergeMode
available since1.1.0

Optional agent per-tool middleware list merge mode: prepend (the default), append, or replace. It is not valid on environment tool bindings and never changes the environment-wide middleware list.

Related fields:

agents.<agent-type-name>.tools.<tool-name>.filesystemAccess
available since1.1.0

Optional filesystem policy for a tool binding. Accepted values are unset, allowed, and denied. Middleware installation records support the same field per occurrence.

Related fields:

bridge
available since1.1.0

Optional object for configuring Bridge SDK generation.

bridge.ts
available since1.1.0

Optional TypeScript SDK configuration.

bridge.ts.agents
available since1.1.0

Optional list of agent type names, component names, or "*" for including all agents.

bridge.ts.outputDir
available since1.1.0

Optional custom output directory for the generated TypeScript SDK.

bridge.rust
available since1.1.0

Optional Rust SDK configuration.

bridge.rust.agents
available since1.1.0

Optional list of agent type names, component names, or "*" for including all agents.

bridge.rust.outputDir
available since1.1.0

Optional custom output directory for the generated Rust SDK.

bridge.<language>.internal.tools
available since1.1.0

Optional canonical tool names, local component matchers, or "*" for generated guest bridge clients. Names declared under tools resolve to their local or registry-backed implementations; undeclared names resolve from the selected environment’s ambient native tools and MCP imports. "*" includes every visible tool. Release coordinates and native host identities cannot be specified here.

secretDefaults
available since1.1.0

Optional map of secret defaults by environment name.

secretDefaults.<environment-name>
available since1.1.0

Optional object of secret default values for the environment, nested by secret path (e.g. db: { password: ... } for the db.password secret). Defaults are only applied to secrets that do not exist yet in the environment. String values can reference environment variables with {{ VAR }}; these are only required for secrets that get created.

retryPolicyDefaults
available since1.1.0

Optional map of retry policy defaults by environment name. Policies defined here are created in the environment during deployment if they don’t already exist.

retryPolicyDefaults.<environment-name>
available since1.1.0

Optional list of retry policy default entries for the environment.

retryPolicyDefaults.<environment-name>[*].name
available since1.1.0

Required unique name for this retry policy.

retryPolicyDefaults.<environment-name>[*].priority
available since1.1.0

Required integer defining selection priority — higher values are evaluated first.

retryPolicyDefaults.<environment-name>[*].predicate
available since1.1.0

Required predicate tree defining when this policy applies. Supports composable predicates including property comparisons (propEq, propNeq, propGt, propGte, propLt, propLte), property checks (propExists, propIn, propMatches, propStartsWith, propContains), and logical combinators (and, or, not).

retryPolicyDefaults.<environment-name>[*].policy
available since1.1.0

Required retry policy tree defining the retry strategy. Supports base strategies ("immediate", "never", periodic, exponential, fibonacci) and composable modifiers (countBox, timeBox, clamp, addDelay, jitter, filteredOn, andThen, union, intersect).

resourceDefaults
available since1.1.0

Optional map of quota resource defaults by environment name.

resourceDefaults.<environment-name>
available since1.1.0

Optional list of resource definition entries for the environment.

resourceDefaults.<environment-name>[*].name
available since1.1.0

Required name of the resource.

resourceDefaults.<environment-name>[*].limit
available since1.1.0

Required resource limit definition. Can be one of:

  • Rate limit: {"type": "Rate", "value": <int>, "period": <timePeriod>, "max": <int>}
  • Capacity limit: {"type": "Capacity", "value": <int>}
  • Concurrency limit: {"type": "Concurrency", "value": <int>}

Where timePeriod is one of: second, minute, hour, day, month, year.

resourceDefaults.<environment-name>[*].enforcementAction
available since1.1.0

Required enforcement action for the resource, accepted values:

  • reject
    available since1.1.0
  • throttle
    available since1.1.0
  • terminate
    available since1.1.0
resourceDefaults.<environment-name>[*].unit
available since1.1.0

Required string for the single unit of measurement (e.g., token, request).

resourceDefaults.<environment-name>[*].units
available since1.1.0

Required string for the plural units of measurement (e.g., tokens, requests).

Fields and changes by releases

available since1.1.0
available since1.1.1
available since1.2.2
added enum values wasm and wasm-rpc-static todependencies.<component-name>.type
component and template schema property cleanups
available since1.2.2.1
external command schema property cleanups
available since1.2.4
available since1.3.0
added enum values pretty-json, pretty and pretty-yaml toprofiles.<profile-name>.format
renamed resetWorkers to resetAgents
deprecated wasm-rpc dependencies
available since1.4.0
available since1.5.0
removed tempDir, witDeps, components.<component-name>.sourceWit, components.<component-name>.generatedWit, components.<component-name>.linkedWasm, components.<component-name>.componentType, components.<component-name>.dependencies, components.<component-name>.dependenciesMergeMode
removed httpApi.definitions subtree
renamed linkedWasm to outputWasm
restructured httpApi to deployment-only model
Waiting for External Input with Golem Promises (MoonBit)Name Mapping