Overview

Starting with v26.09, Kilonova no longer reads config.toml or grader.toml. Configuration is split in two:

The process never writes a config file other than flags.json. Environment variables are documented by the binary itself: kn --help lists the platform variables, kn grader-serve --help the grader ones, and .env.example in the repository has all of them with comments.

Migrating an existing deployment

The new binary refuses to start without KN_DATA_DIR (and, in remote mode, the grader endpoint and token). Convert your files first:

# platform host
./kn config-migrate -c config.toml --grader-config grader.toml -f flags.json > .env

# grader host (no config.toml there)
./kn config-migrate --grader-config grader.toml > .env

The command:

• prints one KEY=value line per non-empty legacy value to stdout, quoted where needed, so redirecting to .env is enough;
• writes default_language, test_max_mem_kb and banned_hot_problems into the flags file given by -f instead of emitting them;
• reads the same flags file for keys that stopped being flags (listen address, migrations, DB debugging, MaxMind path, OpenTelemetry, Prometheus, sandbox policy, Discord and OpenAI credentials) and emits their KN_* lines; the platform drops those keys from flags.json on its next start;
• reports on stderr which flags it wrote, any file it could not find, and any legacy key that has no equivalent (the never-used priority field on grader clients is dropped);
• never modifies or deletes the TOML files, and gives identical output when run twice.

Then start kn main / kn grader-serve as before, check the boot log, and delete the TOML files. If both files are present on one host and both set sandbox capacity, the grader's value wins and a warning is printed.

Rollback

The migration tool leaves config.toml and grader.toml untouched, so the previous binary starts exactly as before. flags.json gains three keys the old binary logs as unknown and ignores.

Variable reference

Platform (kn main)

| KN_SMTP_HOST | (empty) | email.enabled + email.host | host:port; empty disables mail | | KN_SMTP_USERNAME | | email.username | | | KN_SMTP_PASSWORD | | email.password | | | KN_SMTP_FROM | username | email.sendAs | | | KN_EVAL_MODE | local | eval.mode | local or remote | | KN_EVAL_REMOTE_ENDPOINT | | eval.remote.endpoint | required in remote mode, e.g. https://grader:9000 | | KN_EVAL_REMOTE_TOKEN | | eval.remote.token | required in remote mode |

Sandbox capacity (kn main in local mode, and kn grader-serve)

These were editable from the admin page before v26.09 but only took effect after a restart, so they are now environment-only.

Remote grader (kn grader-serve)

grader-serve ignores the platform variables other than KN_DATA_DIR and KN_SANDBOX_*. The migration tool derives its KN_DATA_DIR from the parent of the legacy scratch_dir, so /var/lib/kilonova/scratch keeps working unchanged.

Moved to flags.json

All three remain editable from the config form on the admin page. An invalid default language now falls back to English with a warning instead of refusing to start.

Removed

The flags listed in the tables above with a flag ... origin no longer exist in flags.json; they were read once at startup, so editing them from the admin page never took effect anyway. feature.grader.isolate_config_path was never read and is dropped without replacement.

common.log_dir and grader.scratch_dir have no replacement: both processes use $KN_DATA_DIR/logs, and the grader uses $KN_DATA_DIR/scratch. Move or symlink your old log directory if you want the history in one place.

KN_CONF_PATH, KN_GRADER_CONF_PATH, -c/--config on kn main and --grader-config on kn grader-serve. KN_FLAG_OVERRIDES (key=value,key=value for one-off flag overrides) keeps working.