Resource metering

The worker executor can meter three resource usage dimensions independently:

Wasmtime fuel for compute usage
Allocated linear-memory byte-time
Filesystem allocated-byte-time

All three dimensions are disabled by default. This is the expected configuration for Golem OSS and self-hosted enterprise deployments that run on customer hardware.


[resource_usage_metering]
compute = false
memory = false
filesystem = false

Set only the dimensions that the deployment exports for billing. For example, a deployment that meters compute and memory but not filesystem storage uses:


[resource_usage_metering]
compute = true
memory = true
filesystem = false

For the local single-binary server, the equivalent environment variables also require a monthly amount for each enabled dimension:


GOLEM__WORKER_EXECUTOR__RESOURCE_USAGE_METERING__COMPUTE=true
GOLEM__WORKER_EXECUTOR__RESOURCE_USAGE_METERING__MEMORY=true
GOLEM__WORKER_EXECUTOR__RESOURCE_USAGE_METERING__FILESYSTEM=false
GOLEM__REGISTRY_SERVICE__INITIAL_PLANS__DEFAULT__MONTHLY_COMPUTE_GCU=1000
GOLEM__REGISTRY_SERVICE__INITIAL_PLANS__DEFAULT__MONTHLY_MEMORY_GB_SECONDS=100000

The local server preserves whether each amount was supplied. If an enabled dimension has no amount, startup fails instead of treating the omission as a zero hard cap. An explicit 0 is valid and creates an exhausted hard cap. Amounts supplied for disabled dimensions are preserved in the local Plan, and each dimension remains independent.

Filesystem metering requires a managed XFS root and separate durable and ephemeral amounts:


GOLEM__WORKER_EXECUTOR__RESOURCE_USAGE_METERING__FILESYSTEM=true
GOLEM__REGISTRY_SERVICE__INITIAL_PLANS__DEFAULT__MONTHLY_DURABLE_STORAGE_GB_MONTH=100
GOLEM__REGISTRY_SERVICE__INITIAL_PLANS__DEFAULT__MONTHLY_EPHEMERAL_STORAGE_GB_MONTH=25
GOLEM__WORKER_EXECUTOR__FILESYSTEM_STORAGE__MODE__TYPE=ManagedXfs
GOLEM__WORKER_EXECUTOR__FILESYSTEM_STORAGE__MODE__CONFIG__ROOT=/var/lib/golem/managed-xfs

The managed XFS root cannot be combined with the deterministic agent filesystem root. Durable and ephemeral storage are separate limits; configuring one does not provide or change the other. When filesystem metering is disabled, managed XFS may still be configured for project quotas without enabling storage billing.

Metering and enforcement

These switches control monthly usage accounting, caps, overage, and billing for their corresponding dimensions. Disabling a meter disables all of that monthly policy, not just export. Missing measurements are not measured zero. Per-agent safety limits and other independent non-billing controls remain active.

Metering switch	Behavior when disabled	Controls that remain active
`compute`	No compute usage accounting, monthly compute cap, overage, or billing.	Epoch-based interruption and executor scheduling
`memory`	No linear-memory byte-time accounting, monthly memory cap, overage, or billing.	Per-agent memory limits, measured admission, and memory-pressure eviction
`filesystem`	No allocated-byte-time accounting, monthly durable or ephemeral storage caps, overage, or billing.	Project quotas of `ManagedXfs` storage, filesystem-object limits, physical-pressure recovery, lifecycle, replay, and cleanup

With every meter disabled, monthly usage mode has no runtime effect. Maximum memory per agent remains enforced. Finite maximum storage per agent remains available only on managed quota-capable storage, currently managed XFS; unmanaged storage reports it disabled.

The ManagedXfs storage mode does not enable storage billing. A self-hosted deployment may use ManagedXfs and its project quotas while leaving filesystem = false.

Filesystem metering reads the project quota of each agent, so it needs the ManagedXfs storage mode. An executor with the ReflinkXfs storage mode and filesystem = true does not start: filesystem metering requires XFS storage with project quotas. The development modes Temporary and Directory meter no filesystem usage.

Current filesystem exceptions

Disabling filesystem metering stops byte-time accumulation and export, but two synchronous allocation observations remain in the current filesystem lifecycle:

Filesystem operation completion may still read allocated usage.
A failure while making that observation may fail the guest I/O operation.

These observations belong to the sealed GOL-416 filesystem protocol. Removing them requires an approved GOL-490 protocol amendment. The filesystem switch does not bypass them.

Deployment modes

Deployment	Compute	Memory	Filesystem
OSS or self-hosted default	Disabled	Disabled	Disabled
Enterprise or on-premises default	Disabled	Disabled	Disabled
Hosted	Explicit deployment choice	Explicit deployment choice	Explicit deployment choice

Hosted manifests are maintained outside this repository. Their operators must explicitly enable each billed dimension during deployment. The worker executor does not infer metering from a registry connection, account, plan, quota, storage backend, or usage fields in registry messages.