fix config loader

[chaptersix]

What changed?

This PR modifies the config loading behavior to make environment variable-based configuration the default, and adds a new --config-from-env flag for explicit control.

Key Changes:

1. New Default Behavior: temporal start (without flags) now loads configuration from the embedded template using environment variables, rather than attempting to load from ./config/development.yaml

2. File-Based Loading: Config files are only loaded when --config, --env, or --zone flags are explicitly set. If these flags are set but files don't exist, the loader returns an error instead of falling back to the embedded template

3. New Flag: Added --config-from-env flag to explicitly signal environment-based configuration (equivalent to the new default behavior)

4. Improved Error Handling: The config loader no longer silently falls back to embedded template when config files are missing - it returns a clear error message

5. Structured Logging: Bootstrap logging now uses zap with console encoding to match Temporal's standard log format, providing structured output during config loading

Why?

Primary Motivation

This change enables removing dockerize as a dependency in the Docker image. The previous template syntax was incompatible with the template parser, and the parser didn't accept environment variables as input. By making environment-based configuration the default, containerized deployments can configure Temporal entirely through environment variables without additional tooling.

Breaking Change Note

⚠️ BREAKING CHANGE: The default behavior has changed:

Before:

• temporal start → Loads from ./config/development.yaml (or falls back to embedded template if not found)

After:

• temporal start → Loads from embedded template using environment variables
• temporal --env=prod start → Loads from ./config/prod.yaml (fails if not found, no fallback)
• temporal start --config-from-env → Explicitly loads from embedded template using environment variables

Users who rely on the previous default behavior of loading ./config/development.yaml must now explicitly use --env=development to maintain that behavior.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

Testing Details:

Unit Tests:

• All existing config loader tests pass
• Updated TestInvalidPath to expect error when config files don't exist (no fallback)
• Updated TestLoadWithEmbeddedTemplate to use explicit useEmbeddedOnly flag
• Verified template rendering with environment variable substitution

Manual CLI Testing:

1. Default behavior (no flags): Confirmed loads from embedded template with env vars

   DB=postgres12 POSTGRES_SEEDS=localhost temporal start
   # Output: "Loading configuration from environment variables only"

2. Explicit file loading: Confirmed attempts to load files and fails when missing

   temporal --env=prod start
   # Output: "Unable to load configuration: failed to get config files: no config files found"

3. Flag validation: Confirmed conflicting flag detection works

   temporal --env=prod start --config-from-env
   # Output: "ERROR: --config-from-env cannot be used with --env flag"

4. Explicit env flag: Confirmed --config-from-env works as expected

   temporal start --config-from-env
   # Output: "Loading configuration from environment variables only"

Potential risks

Breaking Change Impact

The default behavior change may break existing deployments that rely on implicit config file loading. Specifically:

1. Local Development: Developers who run temporal start expecting it to load ./config/development.yaml will need to update their workflow to use temporal --env=development start

2. Deployment Scripts: Any automation that doesn't explicitly set --env, --config, or --zone flags will now use environment-based configuration instead of file-based

3. Migration Path: Users need to either:

   • Set appropriate environment variables for the embedded template, OR
   • Update their startup commands to explicitly specify --env flag

Mitigation

• Clear error messages when config files are expected but not found
• The --config-from-env flag provides explicit documentation of the configuration source
• Bootstrap logging clearly indicates which configuration method is being used

Questions for Reviewers

• Documentation: What documentation needs to be updated to reflect the new default behavior? (deployment guides, getting started docs, Docker image README, etc.)
• Backward Compatibility: Should we consider a deprecation period or feature flag to ease migration?
• Communication: How should we communicate this breaking change to users? (release notes, migration guide, etc.)

[chaptersix]

tabled until we start work