Data & Enterprise

Configuration

Settings in Zornux are typed and declared, not scattered through the code. A configuration block defines a schema with defaults; values arrive from data-only files, environment variables, and overrides — and secrets are redacted everywhere by default.

A typed schema

Each setting declares a type after as and a default after is. Instantiate the configuration with create … from and read settings as fields:

configuration AppConfig
    has host as text is "localhost"
    has listen_port as whole is 8080
    has debug as truth is false
    has api_key as secret is "dev-only-secret"
end

create settings from AppConfig
show settings.host          # localhost
show settings.listen_port   # 8080

Types are text, whole, number, truth, list, map, and secret. They're contextual words — text is still the built-in function everywhere else.

Secrets are redacted

A secret setting never prints in the clear — not with show, not in JSON. Reading its value is a single, explicit, auditable act: reveal.

show settings.api_key           # ******** (redacted)
show reveal(settings.api_key)   # the actual value — the one way in

External secret providers

A secret's value can be a secret://<reference> pointer instead of a literal. At startup the host resolves it through the configured secrets_provider — vault, aws-secrets-manager, azure-key-vault, gcp-secret-manager, or http — so real secrets live in your secret store, never in a file. A secret:// reference with no provider configured stops startup rather than running unresolved.

Files, profiles & overrides

Configuration values are layered, from lowest to highest precedence:

The four profiles are Development, Testing, Staging, and Production, selected with --profile or ZORNUX_PROFILE. A .zxcfg file is data only — no code runs in it:

host is "0.0.0.0"
listen_port is 443
debug is false

Injecting configuration

A service reads settings through dependency injection — use AppConfig makes the loaded configuration available like any other dependency:

service Greeter
    use AppConfig
    function greet
        give back AppConfig.greeting
    end
end

A service can even take its port from configuration: publish Api on port AppConfig.listen_port.

Where a host listens, and which hosts it serves

Two settings, because they answer two different questions. The listening port is neither of them — that comes from publish <Service> on port <N> in the program.

bind_address is "127.0.0.1"
accepted_hosts is "store.example.com, 127.0.0.1"
trusted_proxy_hops is 1

Behind a proxy, the Host on the wire is not the caller's: a same-host proxy sends the replica's bind address as Host and the caller's real host in X-Forwarded-Host. With trusted_proxy_hops set, Zornux reads the forwarded one, checks it against accepted_hosts, and presents it as request.host. A forwarded host that is present but unusable is a refusal — never a fall back to the address on the wire.

Inspecting configuration

Two CLI commands make configuration visible without running the program: zornux config show prints the resolved settings (secrets redacted), and zornux config validate checks the files against every declared schema.

Diagnostics are ZX2600–ZX2699. Next: shaping requests before they reach a route — Middleware.