feat: Conditional backend selection based on environment

[abtreece]

Summary

Enable dynamic backend selection based on environment, allowing the same configuration to work across development, staging, and production.

Motivation

Currently, switching backends between environments requires:

• Different config files per environment
• Environment-specific deployment scripts
• Wrapper scripts that modify confd configuration

This adds complexity and increases the chance of configuration drift.

Proposed Implementation

Environment-Based Backend Selection

# confd.toml
[backends]
default = "env"  # Fallback backend

[backends.production]
type = "vault"
address = "https://vault.prod.example.com"
token = "${VAULT_TOKEN}"

[backends.staging]
type = "consul"
address = "consul.staging.example.com:8500"

[backends.development]
type = "env"
# Use environment variables in development

Selection via:

# Environment variable
CONFD_ENV=production confd

# Command line flag
confd --env production

# Auto-detect from common env vars
# Checks: ENV, ENVIRONMENT, APP_ENV, RAILS_ENV, NODE_ENV

Per-Template Backend Override

[template]
src = "app.conf.tmpl"
dest = "/etc/app/app.conf"

# Use different backends for different keys
[[template.keys]]
prefix = "/app/config"
backend = "consul"

[[template.keys]]
prefix = "/app/secrets"
backend = "vault"

Backend Fallback Chain

[template]
src = "config.tmpl"
dest = "/etc/app/config"
keys = ["/app/*"]

# Try backends in order until one succeeds
backends = ["vault", "consul", "env"]

Conditional Keys

[template]
src = "database.conf.tmpl"
dest = "/etc/app/database.conf"

[template.keys.production]
prefix = "/prod/database"

[template.keys.staging]
prefix = "/staging/database"

[template.keys.development]
prefix = "/dev/database"
fallback_to_env = true

Environment Detection

Auto-detect environment from:

1. --env flag (highest priority)
2. CONFD_ENV environment variable
3. Common environment variables (ENV, ENVIRONMENT, etc.)
4. Kubernetes namespace detection
5. AWS tags or instance metadata
6. Default fallback

Configuration Inheritance

[backends._base]
# Shared settings
timeout = "10s"
retry_count = 3

[backends.production]
_inherit = "_base"
type = "vault"
address = "https://vault.prod.example.com"

[backends.staging]
_inherit = "_base"
type = "vault"
address = "https://vault.staging.example.com"

Benefits

• Single configuration file for all environments
• Reduced deployment complexity
• Easier local development (use env backend)
• Gradual backend migration support
• Multi-backend architectures (secrets in Vault, config in Consul)

[abtreece]

@claude research an implementation plan for this feature. Comment on this issue with the proposed plan

[abtreece]

Closing as won't-do. After review, the core use case (different backends for different templates — e.g., secrets from Vault, config from Consul) is already supported via per-resource backend override. Any template resource can include a [backend] section with full backend config that overrides the global backend. Client caching deduplicates connections automatically.

The environment-based selection proposed here adds significant complexity (environment detection, TOML inheritance, fallback chains) that is better handled by the deployment layer (Helm values, Ansible templates, entrypoint scripts) which already manages per-environment config.

Action item: Improve documentation for per-resource backends — the feature exists but is under-documented.