Modifying Service Configs

Golem services use a configuration system built on Figment via a custom ConfigLoader. Configuration defaults are serialized to TOML and env-var reference files that are checked into the repository and validated in CI.

How Configuration Works

Each service has a configuration struct that implements:

• Default — provides default values
• Serialize / Deserialize — for TOML and env-var serialization
• SafeDisplay — for logging without exposing secrets

Services load config by merging (in order): defaults → TOML file → environment variables.

Service Config Locations

Service	Config struct	File
Worker Executor	GolemConfig	golem-worker-executor/src/services/golem_config.rs
Worker Service	WorkerServiceConfig	golem-worker-service/src/config.rs
Registry Service	RegistryServiceConfig	golem-registry-service/src/config.rs
Shard Manager	ShardManagerConfig	golem-shard-manager/src/config.rs
Compilation Service	ServerConfig	golem-component-compilation-service/src/config.rs
Debugging Service	DebugConfig	golem-debugging-service/src/config.rs

The golem launcher configures the services it starts; it does not define a separate merged service config schema to update in place of the owning service structs above.

Modifying a Config

Step 1: Edit the config struct

Add, remove, or modify fields in the appropriate config struct. Update the Default implementation if default values change.

Step 2: Regenerate config files

cargo make generate-configs

This builds the service binaries and runs them with --dump-config-default-toml and --dump-config-default-env-var flags, producing reference files that reflect the current Default implementation.

Step 3: Verify affected behavior

cargo check -p <affected-service> --all-targets
cargo test -p <affected-service> -- <affected-test> --report-time

cargo make generate-configs already builds the service binaries used to dump every reference config. Do not add a redundant full workspace build unless the config type is part of a broad shared API whose consumers cannot be isolated.

Step 4: Review generated configs

Review the generated TOML and env-var diffs and ensure they match the intended defaults. cargo make check-configs repeats generation before diffing; use it locally when validating generator determinism or broad shared-config changes, but do not rerun it routinely immediately after a successful cargo make generate-configs. CI runs the drift check on every PR.

Adding a New Config Field

1. Add the field to the config struct with a serde attribute if needed
2. Set its default value in the Default impl
3. Run cargo make generate-configs to update reference files
4. If the field requires a new environment variable, the env-var mapping is derived automatically from the field path

Removing a Config Field

1. Remove the field from the struct and Default impl
2. Run cargo make generate-configs
3. Check for any code that references the removed field

Nested Config Types

Many config structs compose sub-configs (e.g., GolemConfig contains WorkersServiceConfig, BlobStoreServiceConfig, etc.). When modifying a sub-config type that's shared across services, regenerate configs for all affected services — cargo make generate-configs handles this automatically.

Checklist

1. Config struct modified with appropriate serde attributes
2. Default implementation updated
3. cargo make generate-configs run
4. Generated TOML and env-var files committed
5. Affected service behavior checks/builds and relevant tests pass
6. Generated config diffs reviewed; cargo make check-configs run locally only when warranted
7. Formatting and linting follow the scope-based pre-pr-checklist