# Modifying Service Configs

> Modifying service configuration types or defaults. Use when changing config structs, adding config fields, or updating default values for any Golem service.

- Skill: `golemcloud/modifying-service-configs` (Agent Skill)
- Install (CLI): `npx skillmds@latest add golemcloud/modifying-service-configs`
- Raw SKILL.md: https://api.skillmd.com/api/skills/golemcloud/modifying-service-configs/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: golemcloud (https://skillmd.com/u/golemcloud)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/golemcloud/modifying-service-configs

---


# Modifying Service Configs

Golem services use a configuration system built on [Figment](https://github.com/SergioBenitez/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

```shell
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

```shell
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`