oxidite-config
Configuration and environment variable management for Oxidite applications.
Installation
[]
= "2.3.3"
Usage
use Config;
let config = load?;
let host: String = config.get.unwrap;
let port: u16 = config.get_u16?;
let debug: bool = config.get_bool?;
println!;
# Ok::
Environment Variables
Oxidite supports three strategies for defining environment variables in oxidite.toml. All strategies produce the same std::env::var() results at runtime.
1. Flat [env] table
Keys map directly to environment variables:
[]
= "postgres://..."
= "change-me"
= "my-app"
2. Namespaced tables
Any root-level TOML table that is not a known config section (app, server, database, cache, queue, security) becomes an env namespace. The table name is uppercased and prepended to each key:
[]
= "abc" # → GOOGLE_CLIENT_ID
= "xyz" # → GOOGLE_CLIENT_SECRET
[]
= "my-app" # → PLATFORM_NAME
3. Nested tables
Tables can nest to any depth. Each level adds another _SEGMENT:
[]
= "abc" # → GOOGLE_OAUTH_CLIENT_ID
Non-string TOML values (integers, booleans) are converted automatically:
[]
= 8080 # → MYAPP_PORT = "8080"
= true # → MYAPP_DEBUG = "true"
Resolution order
| Priority | Source |
|---|---|
| 1 (highest) | OS environment variables |
| 2 | .env file (dotenv) |
| 3 | [env] flat table |
| 4 | Namespaced tables |
Reading config directly
Namespaced tables are also accessible without going through std::env:
let config = load?;
let client_id: String = config.get.unwrap;
let redirect: String = config.get.unwrap;
if config.has_key
Environment Overrides
The loader also applies these environment variable overrides to known config fields:
OXIDITE_ENV/ENVIRONMENT→app.environmentAPP_NAME→app.nameSERVER_HOST→server.hostSERVER_PORT→server.portDATABASE_URL→database.urlREDIS_URL→cache.redis_urlandqueue.redis_urlJWT_SECRET→security.jwt_secret
Invalid values (for example a non-numeric SERVER_PORT) return a typed ConfigError.