Radiator Server Documentation — v10.34.1

Environment Variables

Use environment variables to parameterize Radiator configuration

Table of Contents

Environment Variables in Configuration

Radiator configuration files can reference process environment variables. This allows you to keep sensitive values, deployment-specific settings, and environment-dependent parameters outside the configuration files.

Environment variables are particularly useful in containerized and systemd-managed deployments where multiple Radiator instances share an identical base configuration. Each instance can be customized at startup by setting different environment variables -- for example, different listen ports, shared secrets, or backend addresses -- without duplicating or modifying the configuration files themselves.

Syntax

Reference an environment variable with the env. prefix:

env.VARIABLE_NAME

Inside quoted strings, use the %{...} placeholder syntax:

"%{env.VARIABLE_NAME}"

Default values

Use the default() filter to provide a fallback when an environment variable is not set:

env.VARIABLE_NAME | default("fallback_value")

Inside quoted strings:

"%{env.VARIABLE_NAME | default("fallback_value")}"

If the variable is not set and no default is provided, Radiator reports a configuration error at startup.

Filters

Environment variable expressions support the default() filter. The full set of filters is available only inside execution pipelines where expressions are evaluated at runtime per-request:

@execute {
    modify radius.reply."Reply-Message" "%{env.WELCOME_PREFIX | uppercase} %{aaa.identity}";
    modify radius.reply."Filter-Id" "%{env.FILTER_TEMPLATE | default("default") | lowercase}";
    accept;
}

Supported value types

Environment variables can be used wherever Radiator accepts a value. The table below lists each value type with an example.

Value type	Example
String	`secret env.RADIUS_SECRET;`
Number	`port env.RADIUS_PORT;`
Duration	`timeout env.TIMEOUT \| default("5s");`
Boolean	`require_message_authenticator env.REQUIRE_MA;`
IP address	`ip env.LISTEN_IP;`
IP prefix	`ip env.CLIENT_NETWORK;`
File path	`filename env.CERT_PATH;`

The resolved string is parsed and validated the same way as a literal value. For example, a duration variable must contain a valid duration string such as 5s or 1m30s (see Duration Units), and a boolean variable must be true, false, on, or off.

Examples

Secrets and credentials

Keep shared secrets and passwords out of configuration files:

clients {
    radius "CLIENTS" {
        client "UPSTREAM" {
            source {
                ip 10.0.0.0/8;
            }
            secret env.RADIUS_SECRET;
        }
    }
}

Listen address and port

Parameterize network binding for different environments:

servers {
    radius "AUTH" {
        listen {
            protocol udp;
            ip env.LISTEN_IP | default("0.0.0.0");
            port env.LISTEN_PORT | default(1812);
        }
        clients "CLIENTS";
    }
}

Timeouts and intervals

Set timeouts from the environment:

servers {
    radius "AUTH" {
        listen {
            protocol tcp;
            ip 0.0.0.0;
            port 1812;
            timeout env.TCP_TIMEOUT | default("30s");
        }
        clients "CLIENTS";
    }
}

Database backend

Parameterize database connection details, credentials, and pool settings:

backends {
    postgres "USERS_DB" {
        server "PRIMARY" {
            host env.DB_HOST;
            port env.DB_PORT | default(5432);
            database env.DB_NAME;
            username env.DB_USER;
            password env.DB_PASSWORD;
            connections env.DB_POOL_SIZE | default(20);
            idle-timeout env.DB_IDLE_TIMEOUT | default("60s");
        }

        query "FIND_USER" {
            statement "SELECT username, password FROM users WHERE username = $1";
            bindings {
                aaa.identity;
            }
            mapping {
                user.username = username;
                user.password = password;
            }
        }
    }
}

Boolean settings

Toggle features with environment variables:

clients {
    radius "CLIENTS" {
        client "NAS" {
            source {
                ip 10.0.0.0/8;
            }
            secret env.RADIUS_SECRET;
            require_message_authenticator env.REQUIRE_MA | default("false");
        }
    }
}

Certificate paths

Point to TLS certificates deployed in environment-specific locations:

certificates {
    x509 "SERVER_CERT" {
        filename env.TLS_CERT_PATH;
    }

    key "SERVER_KEY" {
        filename env.TLS_KEY_PATH;
        password env.TLS_KEY_PASSWORD;
    }
}

Format strings with environment variables

Combine environment variables with other text using format strings:

include "%{env.CONFIG_DIR}/backends.radconf";

logging {
    application {
        file {
            filename "%{env.LOG_DIR | default("/var/log/radiator")}/radiator-server.log";
        }
    }
}

Setting environment variables

systemd

Add environment variables to the Radiator systemd service using an override file:

sudo systemctl edit radiator-server.service

Add the variables under [Service]:

[Service]
Environment="RADIUS_SECRET=mysecret"
Environment="LISTEN_PORT=1812"
Environment="TLS_CERT_PATH=/var/lib/radiator/tls/certs/server.pem"

For sensitive values, use EnvironmentFile to load from a protected file:

[Service]
EnvironmentFile=/etc/radiator/env

The environment file uses KEY=value format, one variable per line:

RADIUS_SECRET=mysecret
TLS_KEY_PASSWORD=keypassword

Restrict access to the environment file:

sudo chmod 600 /etc/radiator/env
sudo chown root:root /etc/radiator/env

Container deployments

Pass environment variables with -e flags or an env file:

docker run -e RADIUS_SECRET=mysecret -e LISTEN_PORT=1812 radiator-server

Or with an environment file:

docker run --env-file /path/to/env radiator-server

Shell

Export variables before starting Radiator:

export RADIUS_SECRET=mysecret
export LISTEN_PORT=1812
radiator -c /var/lib/radiator