golemcloud 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 valuesSerialize/Deserialize— for TOML and env-var serializationSafeDisplay— 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
- Add the field to the config struct with a
serdeattribute if needed - Set its default value in the
Defaultimpl - Run
cargo make generate-configsto update reference files - If the field requires a new environment variable, the env-var mapping is derived automatically from the field path
Removing a Config Field
- Remove the field from the struct and
Defaultimpl - Run
cargo make generate-configs - 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
- Config struct modified with appropriate
serdeattributes Defaultimplementation updatedcargo make generate-configsrun- Generated TOML and env-var files committed
- Affected service behavior checks/builds and relevant tests pass
- Generated config diffs reviewed;
cargo make check-configsrun locally only when warranted - Formatting and linting follow the scope-based
pre-pr-checklist