MooseStack settings live in two places: a project config file and runtime environment variables. The config file is tracked in git and defines the shape of your app; env vars are per-environment values (often secrets) that override the file at runtime. Moose Runtime loads both at startup, with env vars winning when they overlap.
Two layers you configure:
moose.config.toml) — Project structure, languages, feature flags, and dev infrastructure. Tracked in git..env.prod, .env.dev, .env.local) or your platform’s secrets manager.MooseStack resolves configuration values in the following order (highest priority first):
MOOSE_* variables set in the shell or platform. Overrides everything..env.local - Local overrides for development secrets. Gitignored..env.{env} - Environment profiles (e.g., .env.prod or .env.dev)..env - Global shared defaults.moose.config.toml - Base project configuration file.Environment variables are the primary mechanism for managing secrets and differentiating between environments.
Pattern: moose.config.toml → MOOSE_{SECTION}__{KEY}
MOOSE_.SECTION is UPPER_CASE, underscore-separated name of the section in moose.config.toml (e.g., clickhouse_config, features, etc.)KEY is the key in the section (e.g., host, workflows, etc.)__) separate the section and key.Moose Runtime automatically loads .env files in order of precedence. Files loaded later override values from earlier files.
| File | Purpose | Committed? | When Loaded |
|---|---|---|---|
.env | Shared defaults (e.g., port numbers, feature flags) | ✅ Yes | Always |
.env.dev | Development-specific overrides | ✅ Yes | moose dev only |
.env.prod | Production-specific overrides | ✅ Yes | moose prod, moose build |
.env.local | Local secrets (passwords, API keys) and personal overrides | ❌ NO | moose dev only (gitignored) |
Never commit .env.local to version control. For production deployments, use platform-specific secret management (Kubernetes Secrets, AWS Secrets Manager) instead of .env files for sensitive data.