Configuration

Configuration files

File	Covers
`config.yml`	Operating mode (observe-only/enforcement/version-override) and server identity.
`checks.yml`	Per-check enablement, response ceiling, and tuning parameters (thresholds, safety margins, buffers).
`actions.yml`	Declarative policy rules, correlation rules, and the command-placeholder allowlist.
`alerts.yml`	In-game/Discord alert routing, aggregation, and role-mention configuration.
`messages.yml`	In-game alert message templates.
`storage.yml`	Database dialect/connection, retention windows, persistence queue sizing.

All five supplemental files use checks.yml's literal-dotted-key convention for check/policy IDs (e.g. movement.speed.a:), not Bukkit's default .-as-nesting behavior — this is deliberate and regression-tested (SupplementalConfigFilesTest), so keep check/rule IDs as one flat key when hand-editing.

Storage

storage.yml controls the dialect (SQLITE, POSTGRESQL, or MYSQL/MariaDB), connection pool sizing, retention windows, and the async persistence queue's capacity/batching.

SQLite — the verified default, needs no setup.
PostgreSQL / MariaDB — set sql.host/port/database/username/password (the password may reference an environment variable, e.g. "${FLAGFORGE_DB_PASSWORD}"). The migration paths are implemented but not yet exercised against a live server in this environment.

If the database is unreachable or migration fails, FlagForge disables persistence for that session (logging why) rather than blocking plugin startup or gameplay — a database outage degrades to silent-observation-only, it never freezes or punishes:

Detection still runs, but findings are never stored.
Alerts and Discord delivery are disabled.
No preventable action ever executes (ActionDispatcher no-ops entirely without storage).

See also: Privacy & Retention for retention windows and manual purge commands.